Ремонт резьбовых соединений: Ремонт резьбовых соединений — Ремонт промышленного оборудования — НПФ Техсервис — Техническое оборудование общепромышленного и нефтепромыслового назначения

Содержание

Ремонт резьбовых соединений

Резьбовые соединения — один из самых быстрых и надежных способов соединить две детали с возможностью быстрого отделения. При частом использовании резьба может быстро прийти в негодность. Как правило при помощи такого вида соединения скрепляют довольно ответственные узлы поэтому следует довольно тщательно просматривать все возможные дефекты и осуществлять ремонт в кратчайшие сроки.

Возможные дефекты и способы ремонта резьбовых соединений

Непрямолинейность оси стержня болта, винта или шпильки.	При таком дефекте может сильно возрасти нагрузка на чать резьбы, которая быстро разрушить часть несколько витков. Данный дефект можно довольно быстро устранить при помощи правки в тисках или с помощью винтового пресса.
Забоины, вмятины на резьбе	«Прогонка» резьбы резьбовыми инструментами
Трещины в резьбовой части детали	Заварка трещины с последующим повторным нарезанием резьбы
Смятие граней, шлицев, отверстий для ключей и отверток	1. Запиливаиие. 2. Наплавка с последующей обработкой
Заедание гайки по причине увеличения шага резьбы винта вследствие его растяжения	Замена болта или ремонт вышеуказанными способами
Выход из строя наружной резьбы вследствие износа, среза, смятия и изгиба витков	1. Протачивание резьбы до ближайшего меньшего стандартного диаметра и последующее нарезание резьбы меньшего размера. 2. При невозможности из условий прочности уменьшения размера резьбы ее восстанавливают наплавкой металлизацией и другими способами
Выход из строя внутренней резьбы вследствие износа, среза, смятия и изгиба витков	1. Рассверливание отверстия до ближайшего большего стандартного диаметра и последующее нарезание резьбы большего размера. 2. Рассверливание отверстия для установки в него на резьбе или клее переходной втулки с внутренним диаметром резьбы нужного размера

Герметизация резьбовых соединений своими руками — Ремонт своими руками

Рано или поздно каждый домашний умелец сталкивается с таким вопросом, как герметизация резьбовых соединений. Может старый смеситель выйдет из строя или начнёт прокапывать батарея – так или иначе, чтобы устранить подобные неприятности, нужно правильно научиться герметизировать резьбу. Многим покажется, что этот процесс довольно простой и не требует никаких знаний и умений. Но это не так – как и везде герметизация резьбы имеет массу тонкостей и нюансов. И если не обращать на них внимания, то процесс устранения течей может превратиться в бесконечную историю, которой не видно ни конца, ни края.

Виды резьбовых соединений

Существует четыре типа сантехнических изделий, резьбы которых, как говорится на языке сантехников, пакуются по-разному: это обыкновенные резьбовые переходники, футорные гайки, сгоны и контргайки. Принцип их герметизации немного отличается друг от друга, общее у них только одно – это материал которым упаковывается соединение.

Чем герметизируют резьбу?

Для того чтобы сделать резьбовое соединение, способным выдерживать высокое давление воды, в арсенале сантехников имеются три вещи: пакля, лента фум и специальная нить. В принципе, все они достойно справляются с возложенными на них обязанностями – разница заключается только в материале, из которых их изготавливают и в применении.

К примеру, пакля – её можно назвать универсальным паковочным материалом – высокие температуры и большое давление ей нипочём, главное, правильно соблюсти все условия её использования. Для надёжной и долговечной герметизации резьбы при помощи пакли дополнительно нужна либо краска, либо специальные мази типа «unipack».

В отличие от пакли, лента фум и нить дополнительных материалов не требуют – они изготовлены полностью из синтетических материалов. Работа с ними намного чище и аккуратней. Но их нельзя применять для таких соединений, как футорные гайки и контргайки – они просто не в состоянии качественно герметизировать эти изделия.

Герметизация резьбы

С обычной резьбой дела обстоят довольно просто – пакля или лента фум наматывается против направления хода резьбы так, чтобы получился небольшой конус, начинающийся в начале резьбы и заканчивающийся в её конце. Очень важным моментом является сила, с которой намотан герметизирующий материал – он должен наматываться довольно туго, слабая намотка приведёт к прокручиванию материала и смещению его за пределы резьбы. А наша задача заключается в том, чтобы паковочный материал оказался между витками внутри соединяемых резьбовых изделий.

Другой нюанс, как ни странно, заключается именно в самой резьбе – её острые витки способны порезать накрученную на них паклю или ленту фум, и тогда ни о какой герметичности соединения речи быть не может. Как с этим бороться? Да просто – нужно напильником сточить острые грани витков. Большинство современных резьбовых изделий уже изготавливаются с учётом этих тонкостей. Внимательно рассмотрев, к примеру, американку, на её резьбе можно увидеть специальные насечки, разрывающие резьбу на мелкие части – именно они помогают пакле не соскальзывать с витков резьбы и не разрезать упаковочный материал.

Герметизация футорной гайки

Немного иначе герметизируется футорная гайка. Основное различие паковки обычной резьбы и футорки заключается в том, что в случае с футорной гайкой паковочный материал не должен попасть между витками. Специальный бортик, выточенный в конце резьбы, как бы спрессовывает паклю (лента фум и паковочная нить здесь не уместны) между собой и, к примеру, батареей, создавая таким способом плотный и надёжный барьер на пути жидкости, находящейся под давлением.

Пакля накручивается против направления завинчивания футорной гайки. Её необходимо скрутить в жгутик и намотать небольшим конусом. Чтобы сделать это соединение более долговечным, сама резьба футорки промазывается масляной или нитрокраской, потом поверх неё наматывается пакля и также обильно пропитывается краской. Такой «дедовский» способ герметизации футорной гайки ещё ни разу не подводил на протяжении многих лет.

Контргайка

В некоторых случаях, когда резьбовое соединение требуется сделать подвижным и независимым, как в случае со сгоном, дополнительно используется контргайка. Применяется она для того, чтобы уплотнить подвижное соединение, резьбу которого невозможно подмотать паклей. Принцип уплотнения контргайки остаётся практически таким же, как и принцип уплотнения футорной гайки, с одной лишь разницей – пакля наматывается по ходу затягивания контргайки. Почему по ходу? Потому что гайка как бы тянет паклю за собой и не даёт ей разматываться.

Герметизация сгона

Особое внимание хочется уделить такому соединению как сгон – современным его аналогом является американка. Но полностью заменить сгон американка так и не смогла, к примеру, в газопроводах их использование категорически противопоказано. Как правило, укомплектованный сгон состоит из муфты или футорной гайки, дополнительно укомплектовывающейся контргайкой.

Процесс герметизации сгона, как вы уже поняли исходя из его комплектации, основан на двух разных принципах. В зависимости от того, из чего состоит сгон, он уплотняется по-разному. Если в состав сгона входит футорка и контргайка, то пакуется отдельно футорка, после чего поджимается контргайка – такое соединение часто применяют для подключения батарей отопления. Ежели сгон вместо футорки оснащён муфтой, то муфта пакуется как обычное резьбовое соединение и после чего поджимается контргайкой. Такие сгоны и поныне применяются для создания разъёмных соединений на трубопроводах.

Вот, в принципе, и всё, что нужно знать о герметизации резьбовых соединений. Но теория, не подкреплённая практикой, стоит не так уж и много. Так что тренируйтесь, и ничего нет страшного в том, что первый стык не удастся. Как говорится, не ошибается тот, кто ничего не делает

Ремонт резьбовых отверстий и трещин в корпусных деталях — Студопедия

Восстановление резьбовых отверстий и ремонт трещин фигурными вставками

Дефекты резьбовых отверстий восстанавливают несколькими способами: нарезайием резьбы ремонтного размера, заваркой отверстия с последующей обработкой и нарезанием резьбы прежнего размера, постановкой дополнительной детали (резьбового ввертыша или спиральной вставки). Проще всего отремонтировать отверстие первым способом, который включает в себя следующие операции: рассверливание отверстия до снятия старой резьбы, нарезание в отверстии резьбы ремонтного размера. Но ремонт таким способом приведет к нарушению взаимозаменяемости, поэтому он не всегда может быть применен. Ремонт резьбовых отверстий постановкой ввертыша также не всегда применим, поскольку поставить ввертыш невозможно в тех случаях, когда толщина стенки вокруг отверстий слишком мала.

Более перспективный способ ремонта резьбовых отверстий — спиральными пружинящими вставками. Вставка представляет собой пружинящую спираль, изготовленную из проволоки ромбического сечения. На конце спирали загнут технологический поводок, с помощью которого вставку заворачивают в предварительно подготовленное отверстие. Для ремонта резьбовых отверстий спиральными вставками выпускается специальный комплект, в который кроме вставок входит инструмент: сверла, специальные метчики, ключи для наворачивания вставок, бородки для срубания технологического поводка. Выполнение операций при ремонте отверстий спиральными вставками не представляет особой сложности. Дефектное отверстие рассверливают, нарезают в нем резьбу под спиральную вставку и с помощью специального ключа вворачивают ее в отверстие, пока последний виток вставки не окажется на 0,5 ниже уровня основной поверхности. После этого в отверстие вставляют бородок и срубают технологический поводок.

Так как в свободном состоянии наружный диаметр вставки несколько больше диаметра ремонтируемого отверстия, то после наворачивания в резьбовое соединение вставка находится в напряженном состоянии и удерживается в отверстии достаточно прочно. Практика восстановления деталей показала, что ремонт дефектных резьбовых отверстий с помощью спиральных резьбовых вставок эффективен и целесообразен для резьбовых отверстий в корпусных деталях. Исключением являются сильно изношенные резьбовые отверстия, диаметр которых больше наружного диаметра вставки.

Ремонт резьбовых отверстий в деталях способом постановки спиральных резьбовых вставок по сравнению с ремонтом с помощью резьбовых втулок (ввертышей) при нарезании новой (ремонтной) резьбы повышает износостойкость резьбовых соединений, исключает возможность заедания ввертываемых деталей, значительно повышает производительность труда и снижает стоимость ремонта. Ремонт трещин фигурными вставками состоит из следующих операций: очистки и мойки корпусных деталей; дефектации корпусных деталей; подготовки паза под фигурную вставку; установки фигурной вставки в паз; зачистки отремонтированного участка, контроля качества ремонта. Трещины в корпусных деталях ремонтируют двумя видами фигурных вставок: стягивающими и уплотняющими.

При ремонте трещин уплотняющими фигурными вставками сначала готовят паз. Отступив от конца трещины в сторону ее продолжения на 4…5 мм, просверливают отверстия диаметром 4,6 мм на глубину 3,5 мм, устанавливают в просверленное отверстие фиксатор специального кондуктора и сверлят в сторону расположения трещины следующие отверстия диаметром 4,6 мм на глубину 3,5 мм. Затем переставляют фиксатор кондуктора во вновь просверленное отверстие и сверлят следующие отверстия того же размера.

Через каждые пять отверстий сверлят поперек трещины с обеих сторон по два отверстия. Перед установкой фигурных вставок в паз их торцовые и боковые поверхности смазывают эпоксидным клеем и затем расклепывают. Технологический процесс ремонта головок цилиндров, которые имеют трещины шириной до 0,3 мм и глубиной проникания в стенки клапанных гнезд до 25 мм, расположенные в перемычках между клапанными гнездами, а также между клапанными гнездами и гнездом под камеру сгорания, состоит из следующих операций: дефектации с применением лупы пятикратного увеличения или испытания на гидравлическом стенде при давлении 0,4 МПа в течение 3 мин; сверления по кондуктору перпендикулярно трещине в отверстии диаметром 3,5+008 мм с шагом 4,2+005 мм на глубину 10 мм, удаления перемычки между отверстиями пробойником.

Ремонт радиаторов отопления: резьбовые соединения,

Как в большинстве случаев форс-мажоры случаются, в то время, когда не ожидаешь. Протекания в радиаторах либо откровенная течь – это сигнал функционировать. Многие неприятности решаются самостоятельно, без помощи экспертов. Сейчас и мы сделаем ремонт радиаторов отопления своими руками.

Реагировать нужно срочно

В системе обогрева существует два вида неприятностей:

Протекание теплоносителя из резьбовых соединений;
Течь из тела радиатора – щелей, трещин, других недостатков литых конструкций.

Что бы ни говорили о ремонте разных обогревателей, приемы устранения однообразные для различных радиаторов. Единственной сложностью возможно ремонт ветхих отопительных элементов, но и для этих случаев наша инструкция обрисовывает приемы, решающие подобные неприятности.

Резьбовые соединения

Это самая нередкая патология системы. Резиновые прокладки либо сальники, кольца ниппелей и другие эластичные атрибуты изнашиваются первыми. Не оказывают помощь и рекомендации проведения тщательной ревизии системы перед отопительным сезоном , не сильный звено проявляется в самый неподходящий момент, причем среди зимы.

Тогда совершим несложной ремонт резьбового соединения.

Для наглядности разберем ремонт биметаллических радиаторов отопления своими руками:

Отключаем сам радиатор от системы отопления, это делается легко — перекрытием воды на входе, на обратке;
Под радиатор укладывается поддон для слива лишней воды при раскручивании соединения;
Гаечным ключом откручиваем накидную гайку и контролируем состояние прокладки либо сальника;

Практика! Кроме того при долгой эксплуатации вы редко заметите разрывы сальника, а вот показатели истончения либо деформации кидаются в глаза сходу. Это указывает, что прокладка прохудилась. Она подлежит замене.

Ставим новый сальник либо прокладку соответствующего диа

Восстанавливаем поврежденные таблицы Innodb / Блог компании King Servers / Хабр

Предположим, вы работаете с MySQL таблицами Innodb, и в один ~~прекрасный~~ не самый хороший момент подводит глючное железо, драйвер, бажит ядро, отключается электричество или случается одна из редких ошибок в среде MySQL. На выходе получено повреждение некоторых страниц в табличной области Innodb.

В одной из предыдущих статей, в комментариях, нас спрашивали, что можно сделать в такой ситуации.Мы постараемся максимально лаконично и по делу.

Так вот, сейчас речь о ситуации вроде этой:


   InnoDB: Повреждение страницы базы данных на диске или сбой
InnoDB: чтение файла страницы 7.
InnoDB: возможно, вам придется восстанавливаться из резервной копии.
080703 23:46:16 InnoDB: дамп страницы в ascii и шестнадцатеричном формате (16384 байта):
… МНОГО ШЕСТИГРАННЫХ И ДВОИЧНЫХ ДАННЫХ…
080703 23:46:16 InnoDB: контрольная сумма страницы 587461377, контрольная сумма формы до 4.0.14 772331632
InnoDB: сохраненная контрольная сумма 2287785129, до-4.Сохраненная контрольная сумма в формате 0,14 772331632
InnoDB: страница lsn 24 1487506025, младшие 4 байта lsn в конце страницы 1487506025
InnoDB: номер страницы (если уже сохранен на странице) 7,
InnoDB: идентификатор пространства (если создан с помощью> = MySQL-4.1.1 и уже сохранен) 6353
InnoDB: страница может быть индексной страницей, где идентификатор индекса равен 0 25556
InnoDB: (индекс «PRIMARY» таблицы «test». «Test»)
InnoDB: повреждение страницы базы данных на диске или сбой

Что делать для восстановления таблицы? В принципе, типов повреждений может быть несколько, ниже мы рассмотрим один из наиболее распространенных моментов.А именно — когда повреждена страница в кластеризованном первичном ключе.

В разделе представлен файл test.idb, где заменено несколько байтов, так что повреждение достаточно умеренное.

При этой операции КОНТРОЛЬНЫЙ ТАБЛИЦА в INNODB практически бесполезна. Для данного поврежденного файла мы получаем:

  mysql> проверка таблицы test;
ОШИБКА 2013 (HY000): потеряно соединение с сервером MySQL во время запроса.
mysql> проверка таблицы test;
+ ----------- + ------- + ---------- + ---------- +
| Стол | Op | Msg_type | Msg_text |
+ ----------- + ------- + ---------- + ---------- +
| контрольная работа.тест | проверить | статус | ОК |
+ ----------- + ------- + ---------- + ---------- +
1 ряд в комплекте (0,69 сек)

Первый запуск — проверка таблицы в обычном режиме, в этом случае innodb просто падает, если есть ошибка в контрольной сумме (даже если мы выполняем CHECK). Во втором случае запускаем innodb_force_recovery = 1. И даже здесь мы получаем логах запись о несовпадении контрольной суммы, при этом КОНТРОЛЬНАЯ ТАБЛИЦА говорит нам, что с таблицей все ок. Как видим, ПРОВЕРИТЬ ТАБЛИЦУ доверять можно далеко не всегда.

В примере «повреждение» совсем небольшое, поэтому если запускаем innodb_force_recovery = 1, получаем следующее:

  mysql> CREATE TABLE `test2` (
    -> `c` char (255) ПО УМОЛЧАНИЮ NULL,
    -> ʻid` int (10) unsigned NOT NULL AUTO_INCREMENT,
    -> ПЕРВИЧНЫЙ КЛЮЧ (ʻid`)
    ->) ДВИГАТЕЛЬ = МИИСАМ;
Запрос в порядке, затронуто 0 строк (0,03 сек)
mysql> вставить в test2 выбрать * из теста;
Запрос в порядке, затронуто 229376 строк (0,91 сек)
Записей: 229376 Дубликатов: 0 Предупреждений: 0

Теперь мы получили все данные в таблице MyISAM, так что все, что остается сделать — дропнуть старую таблицу, и конвертировать новую в innodb после рестарта без опции innodb_force_recovery.Если старая таблица будет нужна в дальнейшем, ее можно просто переименовать. Вторая альтернатива — сделать дамп с MySQLDump и загрузить таблицу обратно. В принципе, это почти одно и то же. MyISAM используется по причине, описанной ниже.

Почему бы просто не посмотреть ОПТИМИЗИРОВАТЬ ТАБЛИЦУ? Все потому, что работа в режиме innodb_force_recovery выполняется в режиме чтения для операций с данными, поэтому нельзя вставлять или стирать данные (при этом можно создать или удалить таблицу Innodb):

  mysql> оптимизировать тест таблицы;
+ ----------- + ---------- + ---------- + --------------- ------------------- +
| Стол | Op | Msg_type | Msg_text |
+ ----------- + ---------- + ---------- + --------------- ------------------- +
| контрольная работа.тест | оптимизировать | ошибка | Получена ошибка -1 от механизма хранения |
| test.test | оптимизировать | статус | Операция не удалась |
+ ----------- + ---------- + ---------- + --------------- ------------------- +
2 ряда в наборе, 2 предупреждения (0,09 сек)

Это было просто, правда?

После этого можно пойти еще дальше, и отредактировать наш файл test.ibd , полностью удалив один из заголовков страницы. Теперь CHECK TABLE будет падать даже при использовании innodb_force_recovery = 1

  080704 0:22:53 InnoDB: Ошибка утверждения в потоке 1158060352 в файле btr / btr0btr.c строка 3235
InnoDB: Неудачное утверждение: page_get_n_recs (page)> 0 || (level == 0 && page_get_page_no (page) == dict_index_get_page (индекс))
InnoDB: Мы намеренно создаем ловушку памяти.
InnoDB: отправьте подробный отчет об ошибке на http://bugs.mysql.com.
InnoDB: если вы получаете повторяющиеся сбои или сбои утверждения, даже

Если мы видим нечто подобное, то innodb_force_recovery нам не поможет, поскольку это похоже на повреждение данных в различных системных местах.Но в нашем случае это не помогает.

Получаем такую ошибку:

  mysql> вставить в test2 выбрать * из теста;
ОШИБКА 2013 (HY000): потеряно соединение с сервером MySQL во время запроса.

Попытки использования автоматических процессов восстановления поврежденных данных не приводят к положительному результату. Поэтому стоит использовать серию команд с LIMIT для режима ручного восстановления:

  mysql> вставить ignore в test2 select * from test limit 10;
Запрос в порядке, затронуты 10 строк (0.00 сек)
Записей: 10 Дубликатов: 0 Предупреждений: 0
mysql> вставить игнорирование в test2 select * from test limit 20;
Запрос в порядке, затронуты 10 строк (0,00 сек)
Записей: 20 Дубликатов: 10 Предупреждений: 0
mysql> вставить игнорирование в test2 select * from test limit 100;
Запрос в порядке, затронуто 80 строк (0,00 сек)
Записей: 100 Дубликатов: 20 Предупреждений: 0
mysql> вставить игнорирование в test2 select * from test limit 200;
Запрос в порядке, затронуто 100 строк (1,47 сек)
Записей: 200 Дубликатов: 100 Предупреждений: 0
mysql> вставить игнорирование в test2 select * from test limit 300;
ОШИБКА 2013 (HY000): потеряно соединение с сервером MySQL во время запроса.

Здесь строки из таблицы переводятся в новую таблицу, пока мы не добираемся до строки, которая и падение MySQL.Мы можем ожидать этого в строке между 200 и 300, так что стоит использовать серию схожих действий для решения проблемы.

Теперь мы обнаружили поврежденные данные в таблице, при этом стоит использовать max PK, и проверить другие значения:

  mysql> select max (id) from test2;
+ --------- +
| макс (id) |
+ --------- +
| 220 |
+ --------- +
1 ряд в комплекте (0,00 сек)
mysql> вставить игнорирование в test2 выберите * из теста, где id> 250;
ОШИБКА 2013 (HY000): потеряно соединение с сервером MySQL во время запроса.
mysql> вставить игнорирование в test2 выбрать * из теста, где id> 300;
Запрос в порядке, затронуто 573140 строк (7.79 сек)
Записей: 573140 Дубликатов: 0 Предупреждений: 0

Так, мы пробуем пропустить 30 строк, но это оказывается недостаточным. Пропускаем 80 строк, и теперь все хорошо. Используя «двоичный поиск» мы можем понять, сколько строк нужно пропустить, для восстановления количества поврежденных данных. Размер при этом может помочь. Так, у нас есть 280 байт на строку, поэтому мы получаем около 50 строк на страницу. И здесь 30 строк недостаточно — таблица повреждена, нужно пропустить минимум страницу.Если повреждена страница на более высоком уровне BTREE, нужно пропустить больше страниц, для использования метода восстановления.

В некоторых случаях, например, когда повреждена корневая страница для кластеризованного индекса, этот метод не будет нормально работать. В этом случае стоит использовать Innodb Recovery Toolkit.

П.С. Принимаем заявки на статьи 🙂

Оптимизация и тюнинг производительности MariaDB MySQL сервера внутри Docker

Пожалуй, максимально полное руководство на русском языке по оптимизации сервера MySQL в docker-контейнерах. По сути большая часть советов отлично подойдёт и тем, кто не работает с Docker. Оптимизацию базы данных можно разделить на 3 слоя:

Оптимизация запросов, таблиц и индексов
Тюнинг параметров сервера баз данных
Оптимальная настройка сервера, операционной и файловой систем

В этой замете рассмотрим второй пункт: тюнинг параметров сервера баз данных.И конечно же первым советом будет не использовать Docker для контейнеров MySQL и других хранилищ! Я серьёзно, если вы используете базу данных находся в контейнере и беспокойтесь о тюнинге производительности, то первым же делом выполняет его на отдельный полноценный сервер. Однако есть и преимущество при запуске MySQL в Docker: можно для каждого приложения оптимально сконфигурировать настройку.

Как это не удивительно, но официальный образ от MariaDB для Docker уже сконфигурирован с некоторыми оптимизациями, в том числе и для работы в контейнерах.В файле /etc/mysql/my.cnf уже включено innodb_file_per_table = 1, а в конфиге /etc/mysql/conf.d/docker.cnf присутствуют сроки:

 [mysqld]
пропустить-хост-кеш
пропустить имя-разрешение

Установка и знакомство с MySQLTuner

MySQLTuner достаточно интересный и полезный инструмент для тюнинга и оптимизации серверов баз данных: MySQL 5.7, MySQL 5.6, MySQL 5.5, MariaDB 10.1, MariaDB 10.0, Percona Server 5.6, Percona XtraDB cluster. Также он частично поддерживает MySQL 3.23, 4.0, 4.1, 5.0, 5.1, но они помечены как устарели. Приступим к подготовке к установке:

 apt обновление
apt install wget nano -y

Установка MySQLTuner достаточно тривиальна:

 кд /
wget https://github.com/major/MySQLTuner-perl/tarball/master
tar xf мастер
RM мастер
cd / major-MySQLTuner-perl-9cf48b5 /

Чтобы каждый раз не вводить логин и пароль, можно создать специальный файл ~ / .my.cnf используя данные администратора БД:

 [клиент]
user = someusername
пароль = thatuserspassword

./mysqltuner.pl --defaults-file = ~ / my.cnf

С настройками по-умолчанию отчёт будет выглядеть примерно так:

 >> MySQLTuner 1.7.8 - майор Хайден 
 >> Отчеты об ошибках, запросы функций и загрузки на http://mysqltuner.com/
 >> Запустите с '--help' для дополнительных параметров и фильтрации вывода

[-] Пропущена проверка версии для скрипта MySQLTuner
[OK] В настоящее время работает поддерживаемая версия MySQL 10.2.10-MariaDB-10.2.10 + maria ~ jessie
[OK] Работа на 64-битной архитектуре

-------- Файл журнала Рекомендации --------------------------------------- ---------------------------
[-] Файл журнала: / var / lib / mysql / ec3476d51dbf.ошибка (0B)
[!!] Файл журнала /var/lib/mysql/ec3476d51dbf.err не существует
[!!] Файл журнала /var/lib/mysql/ec3476d51dbf.err не читается.

-------- Статистика механизма хранения --------------------------------------- --------------------------
[-] Статус: + Aria + CSV + InnoDB + MEMORY + MRG_MyISAM + MyISAM + PERFORMANCE_SCHEMA + SEQUENCE + SPHINX
[-] Данных в таблицах Aria: 3M (Таблицы: 1)
[-] Данные в таблицах InnoDB: 45 ГБ (Таблицы: 108)
[!!] Всего фрагментированных таблиц: 1

-------- Рекомендации по безопасности ---------------------------------------- --------------------------
[OK] Нет анонимных аккаунтов для пользователей базы данных
[OK] Всем пользователям базы данных назначены пароли
[!!] Пользователь app @% не имеет определенных ограничений хоста.[-] Всего в списке 612 базовых паролей.

-------- Рекомендации по безопасности CVE --------------------------------------- -----------------------
[OK] ДЛЯ ВАШЕЙ ВЕРСИИ НЕТ БЕЗОПАСНОСТИ CVE

-------- Показатели эффективности ---------------------------------------- -------------------------------
[-] Время работы: 2д 17ч 8мин 9с (252K q [1,075 qps], 7K conn, TX: 88M, RX: 31M)
[-] Чтение / запись: 57% / 43%
[-] Двоичное ведение журнала отключено
[-] Физическая память: 31.0G
[-] Максимальный объем памяти MySQL: 1,3 ГБ
[-] Другая память процесса: 17,7 МБ
[-] Общее количество буферов: 616.0M глобальных + 7.5M на поток (максимум 100 потоков)
[-] P_S Максимальное использование памяти: 0B
[-] Galera GCache Максимальное использование памяти: 0B
[OK] Максимально достигнутое использование памяти: 646,1 МБ (2,04% установленной ОЗУ)
[OK] Максимально возможное использование памяти: 1,3 ГБ (4,32% установленной ОЗУ)
[OK] Общее возможное использование памяти другим процессом совместимо с доступной памятью
[OK] Медленные запросы: 0% (0 / 252K)
[OK] Максимальное использование доступных подключений: 4% (4/100)
[OK] Прерванные соединения: 0.26% (19/7425)
[!!] Кэш запросов может быть отключен по умолчанию из-за конфликта мьютексов.
[OK] Эффективность кеширования запросов: 48,1% (192 КБ кешируется / 399 КБ выбирается)
[OK] Запросить очистку кеша в день: 0
[OK] Сортировки, требующие временных таблиц: 0% (0 временных сортировок / 23 сортировки)
[OK] Никаких объединений без индексов
[!!] Временные таблицы, созданные на диске: 62% (167 на диске / 267 всего)
[OK] Частота попаданий в кеш потоков: 99% (11 создано / 7K соединений)
[OK] Частота попаданий в кеш таблицы: 95% (123 открытых / 129 открытых)
[OK] Используемое ограничение на открытие файла: 0% (29 / 65K)
[OK] Блокировки таблиц установлены немедленно: 100% (24 немедленных / 24 блокировки)

-------- Схема производительности ---------------------------------------- --------------------------------
[-] Схема производительности отключена.[-] Память, используемая P_S: 0B
[-] Sys schema установлена.

-------- Метрики ThreadPool ---------------------------------------- --------------------------------
[-] Включен статус ThreadPool.
[-] Размер пула потоков: 8 потоков.
[-] Для вашей версии достаточно использовать значение по умолчанию (10.2.10-MariaDB-10.2.10 + maria ~ jessie)

-------- Показатели MyISAM ---------------------------------------- ------------------------------------
[!!] Используемый ключевой буфер: 18.2% (используется 24 МБ / 134 МБ кеш-памяти)
[OK] Размер ключевого буфера / общее количество индексов MyISAM: 128.0M / 124.0K
[!!] Коэффициент попадания в буфер ключа чтения: 87,5% (16 кэшированных / 2 чтения)

-------- Метрики InnoDB ---------------------------------------- ------------------------------------
[-] InnoDB включен.
[-] Параллелизм потоков InnoDB: 0
[OK] Файл InnoDB для каждой таблицы активирован
[!!] Пул буферов InnoDB / размер данных: 256.0M / 45.3G
[!!] Отношение размер файла журнала InnoDB / размер пула буферов InnoDB (37.5%): 48.0M * 2 / 256.0M должно быть равно 25%
[OK] Экземпляры пула буферов InnoDB: 1
[-] Количество блоков пула буферов InnoDB: 2 для 1 экземпляра пула буферов
[OK] Innodb_buffer_pool_size выровнен с Innodb_buffer_pool_chunk_size и Innodb_buffer_pool_instances
[OK] InnoDB Эффективность буфера чтения: 92,19% (1313501 попаданий / 1424772 всего)
[!!] Эффективность записи журнала InnoDB: 64,27% (35911 обращений / 55871 всего)
[OK] Ожидания журнала InnoDB: 0,00% (0 ожиданий / 19960 записей)

-------- Метрики AriaDB ---------------------------------------- ------------------------------------
[-] AriaDB включен.[OK] Размер кэша страниц Aria / общее количество индексов Aria: 128,0M / 1,4M
[!!] Показатель попадания в кэш страницы Aria: 91,7% (2 Кэширования / 167 операций чтения)

-------- Метрики TokuDB ---------------------------------------- ------------------------------------
[-] TokuDB отключен.

-------- Показатели XtraDB ---------------------------------------- ------------------------------------
[-] XtraDB отключен.

-------- Показатели RocksDB ---------------------------------------- -----------------------------------
[-] RocksDB отключен.-------- Показатели пауков ---------------------------------------- ------------------------------------
[-] Паук отключен.

-------- Подключите показатели ---------------------------------------- -----------------------------------
[-] Коннект отключен.

-------- Показатели Galera ---------------------------------------- ------------------------------------
[-] Галера отключена.

-------- Метрики репликации ---------------------------------------- -------------------------------
[-] Galera Синхронная репликация: НЕТ
[-] Нет подчиненных устройств репликации для этого сервера.[-] Формат бинлога: MIXED
[-] Поддержка XA включена: ВКЛ.
[-] Мастер полусинхронной репликации: не активирован
[-] Полусинхронная репликация Slave: не активирован
[-] Это автономный сервер

-------- Рекомендации ----------------------------------------- ----------------------------------
Общие рекомендации:
 Запустите OPTIMIZE TABLE, чтобы дефрагментировать таблицы для повышения производительности
 ОПТИМИЗАЦИЯ ТАБЛИЦЫ ʻapp`.`log`; - можно освободить 9493 МБ
 Общий объем свободного места после тезисов ОПТИМИЗАЦИЯ ТАБЛИЦЫ: 9493 Мб
 Ограничить хост для пользователя @% пользователем @ SpecificDNSorIp
 При внесении корректировок сделайте tmp_table_size / max_heap_table_size равным
 Уменьшите количество запросов SELECT DISTINCT, в которых нет предложения LIMIT
 Производительность должна быть активирована для лучшей диагностики
 Прочтите это перед изменением innodb_log_file_size и / или innodb_log_files_in_group: http: // bit.ly / 2wgkDvS
Переменные для настройки:
 query_cache_size (= 0)
 query_cache_type (= 0)
 tmp_table_size (> 32 МБ)
 max_heap_table_size (> 32 МБ)
 performance_schema = ON включить PFS
 innodb_buffer_pool_size (> = 45 ГБ), если возможно.

Установка MySQL Tuning Primer Script

Ещё один скрипт для автоматической проверки конфигурации MySQL-сервера, который так же даёт некоторые советы по оптимизации.

 apt установить bc net-tools -y
wget https: // launchpadlibrarian.сеть / 78745738 / tuning-primer.sh
chmod + x tuning-primer.sh

 ./tuning-primer.sh

Результат работы скрипта примерно такой:

 - ПРАЙМЕР ДЛЯ НАСТРОЙКИ МОЩНОСТИ MYSQL -
 - Автор: Мэтью Монтгомери -

Версия MySQL 10.2.10-MariaDB-10.2.10 + Мария ~ Джесси x86_64

Время работы = 1 день 6 часов 28 минут 15 секунд
Средн. qps = 13
Всего вопросов = 1464526
Подключено потоков = 79

Предупреждение: сервер не работал как минимум 48 часов.
Использование этих рекомендаций может быть небезопасным.

Чтобы узнать больше о том, как каждый из этих
переменные времени выполнения влияют на производительность:
http: // dev.mysql.com/doc/refman/10.2/en/server-system-variables.html
Посетите http://www.mysql.com/products/enterprise/advisors.html.
для информации о MySQL's Enterprise Monitoring and Advisory Service

МЕДЛЕННЫЕ ЗАПРОСЫ
Журнал медленных запросов НЕ включен.
Текущее long_query_time = 10.000000 сек.
У вас 0 из 1464560, которые занимают больше 10,000000 секунд. завершить
Кажется, с вашим long_query_time все в порядке

БИНАРНЫЙ ЖУРНАЛ ОБНОВЛЕНИЯ
Журнал двоичных обновлений НЕ включен.
Вы не сможете выполнить восстановление на определенный момент времени
См. Http: // dev.mysql.com/doc/refman/10.2/en/point-in-time-recovery.html

РАБОЧИЕ НИТИ
Текущий thread_cache_size = 100
Текущие потоки_cached = 23
Текущие потоки_пер_сек = 0
Исторические thread_per_sec = 0
Ваш thread_cache_size в порядке

МАКС. СОЕДИНЕНИЙ
Текущее max_connections = 100
Текущие thread_connected = 79
Исторический max_used_connections = 101
Количество используемых подключений составляет 101% от настроенного максимума.
Вы должны поднять max_connections

Нет поддержки InnoDB!

ИСПОЛЬЗОВАНИЕ ПАМЯТИ
Максимальный объем памяти, когда-либо выделенной: 8.93 G
Сконфигурированное максимальное количество буферов на поток: 753 M
Настроено максимальное количество глобальных буферов: 8,19 ГБ
Настроенный максимальный предел памяти: 8,93 ГБ
Физическая память: 30,96 ГБ
Максимальный предел памяти находится в приемлемых пределах

КЛЮЧЕВОЙ БУФЕР
Текущее пространство индекса MyISAM = 124 КБ
Текущий key_buffer_size = 128 M
Частота промахов по ключевому кешу - 1:42
Коэффициент свободного ключевого буфера = 81%
Ваш key_buffer_size в порядке

КЭШ ЗАПРОСОВ
Кеш запросов включен
Текущий query_cache_size = 64 M
Текущий query_cache_used = 23 M
Текущий query_cache_limit = 128 КБ
Текущий коэффициент заполнения памяти кэша запросов = 36.27%
Текущий query_cache_min_res_unit = 4 КБ
MySQL не кэширует результаты запросов, размер которых превышает query_cache_limit

СОРТИРОВКА ОПЕРАЦИЙ
Текущий sort_buffer_size = 4 M
Текущий read_rnd_buffer_size = 1 M
Буфер сортировки в порядке

Присоединяется
./tuning-primer.sh: 401: local: 2097152: неправильное имя переменной
root @ 2cb99988447a: / # nano +943 tuning-primer.sh
корень @ 2cb99988447a: / #
корень @ 2cb99988447a: / #
корень @ 2cb99988447a: / # ./tuning-primer.sh

- ПРАЙМЕР ДЛЯ НАСТРОЙКИ ПРОИЗВОДИТЕЛЬНОСТИ MYSQL -
 - Автор: Мэтью Монтгомери -

MySQL версии 10.2.10-MariaDB-10.2.10 + Мария ~ Джесси x86_64

Время работы = 1 день 6 часов 29 минут 49 секунд
Средн. qps = 13
Всего вопросов = 1478085
Подключено потоков = 6

Предупреждение: сервер не работал как минимум 48 часов.
Использование этих рекомендаций может быть небезопасным.

Чтобы узнать больше о том, как каждый из этих
переменные времени выполнения влияют на производительность:
http://dev.mysql.com/doc/refman/10.2/en/server-system-variables.html
Посетите http://www.mysql.com/products/enterprise/advisors.html
для информации о MySQL's Enterprise Monitoring and Advisory Service

МЕДЛЕННЫЕ ЗАПРОСЫ
Журнал медленных запросов НЕ включен.
Текущее long_query_time = 10.000000 сек.
У вас 0 из 1478106, которые занимают больше 10,000000 секунд. завершить
Кажется, с вашим long_query_time все в порядке

БИНАРНЫЙ ЖУРНАЛ ОБНОВЛЕНИЯ
Журнал двоичных обновлений НЕ включен.
Вы не сможете выполнить восстановление на определенный момент времени
См. Http://dev.mysql.com/doc/refman/10.2/en/point-in-time-recovery.html

РАБОЧИЕ НИТИ
Текущий thread_cache_size = 100
Текущие потоки_cached = 96
Текущие потоки_пер_сек = 0
Исторические thread_per_sec = 0
Ваш thread_cache_size в порядке

МАКС. СОЕДИНЕНИЙ
Текущее max_connections = 100
Текущие thread_connected = 6
Исторический max_used_connections = 101
Количество используемых подключений составляет 101% от настроенного максимума.
Вы должны поднять max_connections

Нет поддержки InnoDB!

ИСПОЛЬЗОВАНИЕ ПАМЯТИ
Максимальный объем памяти, когда-либо выделенной: 8.93 G
Сконфигурированное максимальное количество буферов на поток: 753 M
Настроено максимальное количество глобальных буферов: 8,19 ГБ
Настроенный максимальный предел памяти: 8,93 ГБ
Физическая память: 30,96 ГБ
Максимальный предел памяти находится в приемлемых пределах

КЛЮЧЕВОЙ БУФЕР
Текущее пространство индекса MyISAM = 124 КБ
Текущий key_buffer_size = 128 M
Частота промахов по кеш-ключу - 1:43.
Коэффициент свободного ключевого буфера = 81%
Ваш key_buffer_size в порядке

КЭШ ЗАПРОСОВ
Кеш запросов включен
Текущий query_cache_size = 64 M
Текущий query_cache_used = 23 M
Текущий query_cache_limit = 128 КБ
Текущий коэффициент заполнения памяти кэша запросов = 36.27%
Текущий query_cache_min_res_unit = 4 КБ
MySQL не кэширует результаты запросов, размер которых превышает query_cache_limit

СОРТИРОВКА ОПЕРАЦИЙ
Текущий sort_buffer_size = 4 M
Текущий read_rnd_buffer_size = 1 M
Буфер сортировки в порядке

Присоединяется
Текущий размер join_buffer_size = 260,00 КБ
У вас было 2 запроса, в которых соединение не могло правильно использовать индекс
Вы должны включить "log-query-not-using-indexes"
Затем поищите в журнале медленных запросов неиндексированные соединения.Если вы не можете оптимизировать свои запросы, возможно, вы захотите увеличить
join_buffer_size для размещения более крупных объединений за один проход.

Запись! Этот скрипт по-прежнему будет предлагать поднять join_buffer_size, когда
Обнаружены ЛЮБЫЕ объединения, не использующие индексы.

ПРЕДЕЛ ОТКРЫТЫХ ФАЙЛОВ
Текущий open_files_limit = 65536 файлов
Open_files_limit обычно должен быть установлен как минимум на 2x-3x
это table_cache, если у вас интенсивное использование MyISAM.
Ваше значение open_files_limit кажется в порядке

НАСТОЛЬНЫЙ КЭШ
Текущая table_open_cache = 400 таблиц
Текущая table_definition_cache = 400 таблиц
Всего у вас 192 стола
У вас 400 открытых столов.Текущая частота попаданий table_cache составляет 35%
, в то время как 100% кеш-памяти вашей таблицы используется
Вероятно, вам следует увеличить свой table_cache

ТАБЛИЦЫ ТЕМП.
Текущий max_heap_table_size = 32 M
Текущий tmp_table_size = 32 M
Из 13212 временных таблиц 2% были созданы на диске.
Соотношение созданных таблиц tmp на диске кажется прекрасным

СКАНИРОВАНИЕ ТАБЛИЦ
Текущий read_buffer_size = 2 M
Коэффициент сканирования текущей таблицы = 31: 1
read_buffer_size вроде в порядке

БЛОКИРОВКА СТОЛА
Текущий коэффициент ожидания блокировки = 0: 1478289
Кажется, у вас все в порядке с блокировкой стола

В конце вывода вы видите что-то на подобии:

./tuning-primer.sh: 401: local: 2097152: неправильное имя переменной

то нужно вручную поправить скрипт, т.к. в нём до сих пор присутствует баг, который зарепортили ещё в 2013 году! Возникает при использовании MariaDB, а не чистого сервера MySQL. Открываем файл uning-primer.sh в 943 строке:

 nano +943 tuning-primer.sh

и заменяем

 mysql_variable \ 'join_buffer% \' join_buffer_size

на:

 mysql_variable \ 'join_  buffer_  size% \' join_buffer_size

После чего можно запустить скрипт повторно.

Первичная оптимизация MySQL сервера

Под первичной оптимизацией данных подразумевается тот тюнинг, который можно произвести по большей части, объёме доступной оперативной памяти, а также об объёме и структуре. Фактически вся оптимизация сводится к двум действиям:

хранить все значимые данные и индексы в оперативной памяти
как можно меньше изменить данные на диске:
- все изменения писать в операциях, которые периодически накатывать на хранилище данных

Некоторые из «оптимизаций» могут быть не рекомендуемыми либо требующими особых условий эксплуатации, например, настроенной репликации.

Смотрим и изучаем отчёт. Какой можно сделать из этого вывода? Сразу же можно смотреть последние секции Общие рекомендации и Переменные для регулировки, а так же все районы с пометкой [!!]. Давайте начнём с конца.

Тюнинг innodb_buffer_pool_size в MySQL

Тюнер предлагает увеличить размер схемы innodb_buffer_pool_size до 45G и более. Давайте посмотрим текущее значение запроса:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_buffer_pool_size';

Скорее всего его значение будет 268435456, т.е. 256 Мб, что очень мало для современных приложений, вот тюнер и предлагает увеличить его до 45 Гб. Но откуда он взял такую цифру? Всё просто, именно такой объём в данный момент занимают данные в InnoDB хранилище, о чём было указано выше:

 [-] Данные в таблицах InnoDB: 45G (Таблицы: 108)

Параметр innodb_buffer_pool_size отвечает за максимальный объём оперативной памяти, которая будет выделена для хранения данных и индексов InnoDB-таблиц. Фактически тюнер рекомендует выделить столько оперативной памяти, сколько занимают все данные.По хорошему к этому значению нужно добавить ещё 15-25%, т.к. размер базы данных со временем увеличивается. Однако MySQLTuner не учитывает, что все данные одинаково полезны, а некоторые и вовсе не нужны.

Узнать размер каждой конкретной таблицы можно с помощью запроса:

 ВЫБЕРИТЕ table_schema, table_name,
round (((длина_данных + длина_индекса) / 1024/1024), 2) `Размер в МБ`
ИЗ information_schema.tables ORDER BY data_length + index_length DESC;

В моём случае объём полезных приложений занимает порядок 3 Гб, всё остальное — логи, несущие только историческую ценность.Если брать с запасом, то 8 Гб должно хватить с хорошим запасом.

Как отредактировать конфиг MariaDB в Docker?

Конечно, ваше право, можно не заморачиваться и редактировать конфигурацию напрямую в файле /etc/mysql/my.cnf, лучше потратить немного времени и вынести конфигурацию приложения в отдельный файл.

Проблема в том, что нельзя просто так взять и отредактировать конфиг внутри docker-контейнера. т.к. при его пересоздании все эти данные потеряются, то нужно прокидывать внутрь контейнера из постоянного хранилища.Создадим файл хранилище / mariadb / etc / mysql / conf.d / app.cnf с содержимым:

 [mysqld]
innodb_buffer_pool_size = 8 ГБ

Затем добавим этот файл как волюм в docker-compose.yml:

 мариадб:
 объемы:
 - ./storage/mariadb/etc/mysql/conf.d/app.cnf:/etc/mysql/conf.d/app.cnf

После чего пересоберём и перезапустить контейнер с MySQL:

 / usr / local / bin / docker-compose up -d --no-deps --build mariadb

И проверим:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_buffer_pool_size';

Значение изменилось и в моём случае стало 8589934592, т.е. 8 Гб.

Настройка innodb_log_file_size в MySQL

Следующая по важности опция для оптимизации. MySQLTuner советует установить размер этого равным 25% от размера буферного пула, в моём случае 25% от 8Гб это 2 Гб. По-умолчанию он имеет размер 50 Мб:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_log_file_size';

Этот параметр устанавливает размер лога операций и влияет на скорость записи данных на диск. Чем больше размер лога, тем быстрее будет происходить запись данных.MySQL имеет сразу 2 файла с логом, а влияет на размер каждого файла, т.е. установив значение 1 Гб выделится 2 Гб по одному на каждый лог. Есть и обратная сторона, чем больше файлов с логом, тем больше времени система будет восстанавливаться во время сбоев т.к. будет много данных нужно применить из лога операций.

Собственно в файле storage / mariadb / etc / mysql / conf.d / app.cnf добавляем команду:

 innodb_log_file_size = 1 ГБ

И перезапускаем сервер MySQL, не нужно перезапускать контейнер на этот раз не нужно:

 / usr / local / bin / docker-compose перезапуск mariadb

Настройка innodb_log_buffer_size

Параметр отвечает за размер буфера ещё незакомиченных транзакций.Значение стоит увеличивать, если вы используете большие поля вроде BLOB или TEXT. По-умолчанию составляет 8 Мб, чего хватает для многих приложений.

Тюнинг innodb_flush_log_at_trx_commit

Параметр innodb_flush_log_at_trx_commit определяет, как именно сервер MySQL будет писать на диске данные о транзакциях и имеет три допустимых значения: 0, 1, 2. Тюнинг этого назначит скорость записи в базу данных в десятки и сотни раз. По-умолчанию это значение установлено в значение 1, что даёт самые надежные гарантии сохранности данных, но является самым надежным режимом сохраненных данных.

Если потерять даже 0.000000000001% записей для вашей БД критично — то оставляйте значение 1. Настройка будет идеальна для работающих с деньгами или имуществом.

Если же небольшая потеря данных в экстремальных условиях не критична, то смело выставляйте innodb_flush_log_at_trx_commit в значение 2. В этом режиме транзакции будут сохраняться в кэш операционной системы, запись лога на остаётся на совести ОС. Данные могут быть утеряны лишь в случае краха ОС и лишь за несколько секунд, что зависит от настроек системы.Такой случай подойдёт для социальных сетей и других приложений, которые пользователи совершают действия. Потеря нескольких лайков не оказывает никакого влияния и скорее всего этого никто не заметит.

При значении равном 0 сбрасывается на диск один раз в секунду, вне зависимости от происходящих транзакций. Скорость записи возрастает до космических масштабов, но так же растёт и риск эти данные потерять. Данные могут быть утеряны как при крахе ОС, так и при крахе сервера MySQL и обычно не более, чем за 1-2 последних секунды.Этот режим идеально подойдёт для тех, когда вы легко сможете восстановить данные, например из реплики. Либо вы работаете с API-сервисами и при потере данных их перезапросить.

Изменяем конфиг хранилища / mariadb / etc / mysql / conf.d / app.cnf:

 innodb_flush_log_at_trx_commit = 2

Рестартим:

 / usr / local / bin / docker-compose перезапуск mariadb

Проверяем:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_flush_log_at_trx_commit';

Оптимизация innodb_doublewrite в MariaDB

Ещё одна интересная опция включенная по-умолчанию:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_doublewrite';

Doublewrite представляет собой буфер двойной записи и используется в InnoDB, чтобы страницы были записаны в файле данных.Позволяет избежать потерь данных при внезапном сбое сервера. В этом режиме InnoDB перед записью страниц в основном файле данных записывает их в непрерывную область — двойная запись. Только после записи в этот буфер создается запись страниц на соответствующие позиции в файле данных. Если произошёл сбой операционной системы в процессе записи страницы, то при восстановлении InnoDB движок возьмёт копию страницы из буфера doublewrite.

Если на сервере используется файловая система ZFS, то буфер двойной записи можно смело отключать, т.к. у этой ФС есть свой механизм обеспечения целостности данных. В целом, хоть параметр и содержит в своём названии слово double, его отключение не ускоряет процесс записи в 2. В среднем отмечают только 5-10% прирост производительности. Рисковать ли данных ради этого — решайте сами.

 skip-innodb_doublewrite

или:

 innodb_doublewrite = 0

В целом не рекомендуется отключать на продакшене при работе с ценными данными, т.к. в результате сбоя сервера повреждается файл с данными без возможности сделать ремонт.В случае повреждения файлы спасёт только бэкап или реплика.

Тюнинг с помощью уровня транзакций

По-умолчанию уровень транзакций выставлен в REPEATABLE-READ. Сильнее только SERIALIZABLE. А что, если понизить его до ПРОЧИТАТЬ ЗАВЕРШЕНО? Для некоторых приложений это позволит ещё немного уменьшить время на выполнение запросов. Однако, нужно быть уверенным, что смена уровня изоляции не нарушит консистентность данных в приложении. В некоторых ситуациях можно вообще перейти на самый низкий уровень изоляции — ПРОЧИТАЙТЕ НЕОБХОДИМО.Например, во время обслуживания базы данных: загрузка дампов и т.п.

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'tx_isolation';

 изоляция транзакции = {НЕЗАВИСИМО ПРОЧИТАННОЕ | ЧИТАЕМЫЕ
                         | ПОВТОРНОЕ ЧТЕНИЕ | SERIALIZABLE}

Изменить уровень изоляции для отдельной взятой сессии или нового соединения таким образом:

 УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ СДЕЛКИ ЧИТАТЬ ЗАВЕРШЕНО;

 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

При использовании ключевого слова SESSION устанавливается по умолчанию для всех будущих транзакций, выполняемых в текущем соединении.

По-умолчанию устанавливается установка для следующей (ещё не транзакции). При использовании ключевого слова GLOBAL устанавливается уровень изоляции по-умолчанию глобально для всех новых соединений. Чтобы изменить изоляцию глобально предоставия SUPER.

Настройка query_cache_size в MySQL

Параметр определяет объём оперативной памяти выделяемого сервера под кэш запросов. На практике этот механизм работает не очень эффективно, т.к. кэш запросов для таблицы очищается каждый раз, когда в таблице проиcходят вставка или изменение строк.Такой подход может оказаться неэффективным для приложений с большим запросом на изменение таблиц. Это приводит к тому, что таблицы блокируются в том режиме Ожидание блокировки кеша запроса .

Изменяем конфиг хранилища / mariadb / etc / mysql / conf.d / app.cnf:

 query_cache_size = 0

Рестартим:

 / usr / local / bin / docker-compose перезапуск mariadb

Проверяем:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ КАК 'query_cache_size';

Если кэш запроса всё же включено, то можно посмотреть его статистику с помощью запроса:

 ПОКАЗАТЬ СТАТУС, КАК "Qcache%";

В более удобном виде эту информацию выдаёт MySQL Tuning Primer Script:

 КЭШ ЗАПРОСОВ
Кеш запросов включен
Текущий query_cache_size = 64 M
Текущий query_cache_used = 11 млн
Текущий query_cache_limit = 128 КБ
Текущий коэффициент заполнения памяти кеша запросов = 17.70%
Текущий query_cache_min_res_unit = 4 КБ
Ваш query_cache_size кажется слишком большим.
Возможно, вы можете использовать эти ресурсы в другом месте
MySQL не кэширует результаты запроса, размер которых превышает query_cache_limit размером

В моём случае под кэш запросов по-умолчанию выделено 64 Мб, однако используется всего 11 Мб.

Тюнинг max_heap_table_size и tmp_table_size

Чаще всего эти два параметра настраиваются вместе и устанавливаются в одно и то же значение.Параметр max_heap_table_size соответствует за максимально допустимый размер таблицы типа MEMORY хранящейся в оперативной памяти. Значение по умолчанию 32 Мб, если ваше приложение не использует MEMORY таблицы, установите это значение равным tmp_table_size.

Параметр tmp_table_size отвечает за максимальный размер оперативной памяти выделяемой для временных служебных таблиц. Это значение также зависит от значений max_heap_table_size, и в итоге будет выбрано минимальное значение между max_heap_table_size и tmp_table_size, а остальные временные таблицы будут создаваться на диске.Значение по-умолчанию так же равняется 32 Мб.

Необходимые значения сильно зависят от ваших данных, от методов их обработки, от количества клиентов и выполнения сложных запросов. Попробуйте экспериментальным способом найти значения, при которых будут созданы временные файлы на диске. Именно создание таблиц на диске сильнее всего тормозит сложный ВЫБОР запросов на сортировках и группировках.

 tmp_table_size = 64M
max_heap_table_size = 64M

А если позволяют ресурсы, то можно и:

 tmp_table_size = 2048M
max_heap_table_size = 2048M

Параметры wait_timeout и interactive_timeout

В параметрах указано Interactive_timeout время в секунду, отвечающих за ожидание активности со стороны интерактивного соединения (использующего флаг CLIENT_INTERACTIVE), прежде чем закрыть его.

Значение wait_timeout содержит количество секунд, в течение которых сервер ожидает запросов, прежде чем прервать соединение. Т.е. если от клиента за один из интервал не поступало запросов, то принудительно закрывает соединение, чтобы освободить его для других клиентов.

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'wait_timeout';
ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'interactive_timeout';

По-умолчанию оба параметра установлены в 28 800 секунд, что составляет 8 часов. Далеко не каждое приложение может похвастаться таким временем жизни запущенного скрипта.Для приложений с запасом хватит и 30 секунд. Для веб-сайтов вряд ли имеет смысл выставлять это значение больше 3-5 секунд.

 wait_timeout = 5
Interactive_timeout = 5

Вторичная оптимизация конфига MySQL

Под вторичной оптимизацией я подразумеваю тот тюнинг, который можно произвести только зная профиль нагрузки на БД: соотношение чтения и записи, долгие запросы и т.п.

Тюнинг performance_schema в MySQL

Опция performance_schema производит мониторинг БД, на что расходуется некоторая часть ресурсов, держать эту опцию постоянно включенной в продакшене крайне не рекомендуется, т.к. может замедлять время выполнения запросов до 25%. Объем потребляемых ресурсов зависит от конфигурации схемы, которую можно посмотреть выполнив запрос:

 ПОКАЗАТЬ ПЕРЕМЕННЫЕ КАК "производительность%";

А если выполнить от имени администратора БД этот запрос:

 SHOW ENGINE performance_schema STATUS;

С помощью этого запроса можно понять все ли данные мониторятся, или что-то пропадает:

 ПОКАЗАТЬ СТАТУС КАК "производительность%";

Если какой-то счетчик оказался выше ноля, то нужно увеличить соответствующий параметр.

Именно на данных из performance_schema и основана вся фишка MySQLTuner! Чем дольше собираются данные, тем точнее будут рекомендации по оптимизации MySQL и MariaDB. Стоит учесть, что данные performance_schema обнуляются после каждой загрузки сервера , поэтому сначала выполнить первичную конфигурацию, после чего оставить сервер под боевой нагрузкой на сутки для следующего анализа.

Работа с данными performance_schema

Переходим в базу данных performance_schema:

 ЕГЭ performance_schema;

И смотрим какие таблицы здесь есть:

 ПОКАЗАТЬ ТАБЛИЦЫ;

Обратим внимание на наблицы с префиксом setup_, например:

 ВЫБРАТЬ * ИЗ setup_consumers;
ВЫБРАТЬ * ИЗ setup_instruments;

В них существуют настройки того, что будет мониториться.С помощью UPDATE можно менять значение колонки ENABLED с NO на YES и наоборот.

Самые горячие таблицы

С помощью этого запроса можно узнать к каким таблицам происходит наибольшее число чтений и записей:

 select substring_index (file_name, '/', -1) file_name, event_name, count_read, count_write from file_summary_by_instance, где COUNT_READ + COUNT_WRITE> 0 заказ по COUNT_READ + COUNT_WRITE desc limit 30;

А этим запросом можно узнать статистику по блокировкам:

 выберите event_name, source, sum (timer_wait) timer_wait из events_waits_history_long, где имя_события не похоже на группу 'wait / io / file%' по имени_события, порядок источника по 3 desc limit 30;

Тюнинг MySQL для самых маленьких

Если вы впервые сталкиваетесь с оптимизацией сервера MySQL, то эти пункты встать на истиный путь:

Переходите на InnoDB
Используйте индексы
Используйте персистентные соединения в приложении
Включите опцию innodb_file_per_table = 1, если она ещё не была включена.
Анализируйте нагрузку в режиме реального времени с помощью утилит mytop или mtop.
Отключение резолвинга доменных имён в ip-адрес поднять производительность до 20%. Просто добавьте в конфиг опцию skip-name-resolve.
Если приложение и сервер базы данных находятся на одном сервере — используйте socket-соединение, а не TCP. Это позволит сократить время ответа до 30%. Добавьте в конфиг socket = / tmp / mysql.sock и skip-network.
Если в вашем приложении преобладает SELECT — 90% и более запросов, то макет включить опцию низкоприоритетных обновлений для повышения приоритета запросов select.
Включите логгирование медленных запросов:
log_error = / var / log / mysql / error.log
#log_slow_queries = /var/log/mysql/slow.log
slow_query_log_file = /var/log/mysql/slow.log
slow_query_log = ON
long_query_time = 5
журнальные запросы-неиспользуемые-индексы

Просмотры сообщений: 10 085

Ремонт резьбовых соединений: Ремонт резьбовых соединений — Ремонт промышленного оборудования