Промывка кпп: Как промыть коробку передач от старого масла?

Как промыть коробку передач от старого масла?

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

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

Рассмотрим, как это сделать, подробнее.

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

Клапан, который обеспечивает приток или отток воздуха (сапун), расположен в верхней части коробки.

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

Трансмиссионная жидкость может стать причиной загрязнения МКПП также в случае ее длительного перегрева. Такое наблюдается при долгой езде на высокой скорости или в условиях бездорожья, буксировке тяжелого груза. Из-за недопустимо высоких температур масло в коробке начинает «свариваться», образуя нечто наподобие мази.

Отложения в поддоне картера МКПП, а также на других частях агрегата, образует окислившееся масло при несоблюдении интервалов его замены.

Для очистки коробки передач перед очередной заменой масла лучше использовать специализированные промывочные средства.

Они позволяют:

• Размягчить и удалить различные отложения и продукты износа деталей КПП
• Очистить масляные каналы и улучшить циркуляцию масляной жидкости
• Полностью удалить старое масло
• Продлить срок службы сальников и резиновых уплотнителей

Перед проведением процедуры промывки коробки и замены масла МКПП должна быть прогрета. Автомобиль следует поставить на ровную поверхность (лучше всего на эстакаду).

После слива старого масла через заливное отверстие в коробку подается промывочная жидкость (ее количество должно соответствовать объему КПП).

Затем двигатель заводится и работает на холостом ходу 10-15 минут. Куда-либо ехать или переключать передачи нет необходимости.

Промывочное средство сливается, заливается свежее масло.

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

Изображение взято с сайта https://market.yandex.ru

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

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

Обычно полную замену масла в коробке проводят через каждые 60-70 тыс. км пробега (как самостоятельно, так и на станции). Промывку МКПП производят по необходимости, то есть каждый раз делать это необязательно.

Вполне достаточно интервала в 120-160 тыс. км. Более точная периодичность зависит от условий эксплуатации, нагруженности и технического состояния трансмиссии конкретного автомобиля.

Была ли полезна статья?

Рейтинг: 5 (5 оценок)

Промывка для коробки автомобиля — для чего мыть коробку передач

Что же новенького с промывками?

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

В принципе, продукт, предназначенный для процедуры мытья, в ассортименте уже был. Это профессиональная промывка масляной системы двигателя 7507 – Pro Line, для сравнения.

Ее можно было использовать, хотя и сейчас можно использовать, никто с нее эту функцию не убирал, для промывки механических коробок. В чем неудобство использования моторной промывки? В том, что нужна достаточно высокая концентрация, то есть объем доливки промывочной жидкости достаточно большой: пол-литра на пять литров трансмиссионного масла. Чаще всего доливать такое количество масла или присадки в механическую коробку передач с объемом заливки 1,5-4 литра – где-то 2,5.

В этом случае это достаточно неудобно, поэтому для МКПП выпустили маленькую фасовку 150 мл, но концентрированного состава, что будет достаточно на 4 литра трансмиссионного масла.

Соответственно, если у нас 2-2,5 литра, то — пол флакона на одну промывку. Опять же никаких проблем с дозировкой, никаких проблем с применением, заливаем в старое трансмиссионное масло, 10 минут машина работает на холостых оборотах, с невыжатым сцеплением.

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

В этот момент нам на помощь и приходит данная присадка для механики, например, после купания автомобиля в воде, когда через сапун или сальники за счет резкого перепада температур затянуло небольшое количество влаги в КПП.

В этом случае начинают появляться коррозия в трансмиссионном масле, во-вторых, снижаются защитные свойства масла, в-третьих, при перегреве масла, оно начинает “гидрироваться” и давать отложения. В отличии от мотора, здесь нет контактов с газами, нет попадания недогоревшего топлива, но все-таки определенные источники загрязнения, как изнашивающиеся детали, и вода туда попадает.

По большому счету, применять можно хоть при каждой замене, как и 7507. Единственный вопрос в том, что данный продукт удобнее добавлять, а также ситуация лишь в том, что попробуйте налить на 4 литра 400 грамм 7507, где идет контрольное отверстие в МКПП.

То есть задача будет: сначала извлечь порядка 300-400 грамм трансмиссионной жидкости, потом уже залить присадку. Это как раз очень неудобная процедура. Здесь 150 мл. промывочной жидкости на 4 литра или 75 на 2 литра, добавляются легко и непринужденно, затем пробка возвращается на место. Так что, в первую очередь, все это сделано для удобства использования.

Самое главное в процедуре – это убрать последствия попадания воды, что особенно характерно для роботов с одним сцеплением.

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

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

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

PostgreSQL: Документация: 15: 30.5. Конфигурация WAL

Существует несколько параметров конфигурации, связанных с WAL, которые влияют на производительность базы данных. В этом разделе объясняется их использование. Обратитесь к Главе 20 за общей информацией о настройке параметров конфигурации сервера.

Контрольные точки — это точки в последовательности транзакций, в которых гарантируется, что файлы данных кучи и индекса были обновлены всей информацией, записанной до этой контрольной точки. Во время контрольной точки все грязные страницы данных сбрасываются на диск, а в файл журнала записывается специальная запись контрольной точки. (Записи изменений ранее были сброшены в файлы WAL.) В случае сбоя процедура восстановления после сбоя просматривает последнюю запись контрольной точки, чтобы определить точку в журнале (известную как запись повтора), с которой она должна начать Операция ПОВТОР. Любые изменения, внесенные в файлы данных до этого момента, гарантированно будут уже на диске. Следовательно, после контрольной точки сегменты журнала, предшествующие сегменту, содержащему повторную запись, больше не нужны и могут быть переработаны или удалены. (При выполнении архивации WAL сегменты журнала должны быть заархивированы перед повторным использованием или удалением.)

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

Серверный процесс контрольной точки периодически автоматически выполняет контрольную точку. Контрольная точка запускается каждые секунды checkpoint_timeout или если max_wal_size вот-вот будет превышен, в зависимости от того, что наступит раньше. Настройки по умолчанию — 5 минут и 1 ГБ соответственно. Если после предыдущей контрольной точки не было записано ни одного WAL, новые контрольные точки будут пропущены, даже если checkpoint_timeout прошло. (Если используется архивация WAL и вы хотите установить более низкий предел частоты архивирования файлов, чтобы ограничить возможную потерю данных, вам следует настроить параметр archive_timeout, а не параметры контрольной точки.) Также можно принудительно установить контрольную точку. с помощью команды SQL CHECKPOINT .

Уменьшение checkpoint_timeout и/или max_wal_size приводит к более частому появлению контрольных точек. Это позволяет быстрее восстановиться после сбоя, поскольку потребуется переделывать меньше работы. Однако необходимо сбалансировать это с увеличением затрат на более частую очистку грязных страниц данных. Если установлено значение full_page_writes (по умолчанию), необходимо учитывать еще один фактор. Чтобы обеспечить согласованность страниц данных, первое изменение страницы данных после каждой контрольной точки приводит к регистрации всего содержимого страницы. В этом случае меньший интервал между контрольными точками увеличивает объем вывода в журнал WAL, что частично сводит на нет цель использования меньшего интервала и в любом случае приводит к большему дисковому вводу-выводу.

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

Чтобы избежать переполнения системы ввода-вывода массой операций записи страниц, запись грязных буферов во время контрольной точки распределяется на определенный период времени. Этот период контролируется параметром checkpoint_completion_target, который задается как часть интервала между контрольными точками (настраивается с помощью checkpoint_timeout ). Скорость ввода-вывода настраивается таким образом, чтобы контрольная точка завершалась, когда истечет заданная доля из checkpoint_timeout секунд или до того, как будет превышено max_wal_size , в зависимости от того, что наступит раньше. При значении по умолчанию 0,9 можно ожидать, что PostgreSQL завершит каждую контрольную точку немного раньше следующей запланированной контрольной точки (приблизительно за 90% продолжительности последней контрольной точки). Это максимально распределяет ввод-вывод, чтобы нагрузка ввода-вывода контрольной точки была постоянной на протяжении всего интервала контрольной точки. Недостаток этого заключается в том, что продление контрольных точек влияет на время восстановления, поскольку необходимо будет хранить больше сегментов WAL для возможного использования при восстановлении. Пользователь, обеспокоенный количеством времени, необходимым для восстановления, может пожелать уменьшить checkpoint_timeout , чтобы контрольные точки возникали чаще, но по-прежнему распределяли ввод-вывод по интервалу контрольных точек. В качестве альтернативы checkpoint_completion_target можно уменьшить, но это приведет к более интенсивному вводу-выводу (во время контрольной точки) и времени меньшего ввода-вывода (после завершения контрольной точки, но до следующей запланированной контрольной точки), и поэтому не рекомендуется . Хотя для checkpoint_completion_target может быть установлено значение 1,0, обычно рекомендуется устанавливать значение не выше 0,9. (по умолчанию), поскольку контрольные точки включают в себя некоторые другие действия, помимо записи грязных буферов. Значение 1.0, скорее всего, приведет к тому, что контрольные точки не будут завершены вовремя, что приведет к потере производительности из-за неожиданного изменения количества необходимых сегментов WAL.

На платформах Linux и POSIX checkpoint_flush_after позволяет заставить ОС сбрасывать страницы, записанные контрольной точкой, на диск после заданного количества байтов. В противном случае эти страницы могут храниться в кэше страниц ОС, вызывая зависание при fsync выдается в конце контрольной точки. Этот параметр часто помогает уменьшить задержку транзакций, но также может негативно сказаться на производительности; особенно для рабочих нагрузок, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС.

Количество файлов сегментов WAL в каталоге pg_wal зависит от min_wal_size , max_wal_size и объема WAL, сгенерированного в предыдущих циклах контрольных точек. Когда старые файлы сегментов журнала больше не нужны, они удаляются или перерабатываются (то есть переименовываются, чтобы стать будущими сегментами в пронумерованной последовательности). Если из-за кратковременного пика скорости вывода бревна max_wal_size превышен, ненужные файлы сегментов будут удалены до тех пор, пока система не вернется к этому пределу. Ниже этого предела система перерабатывает достаточно файлов WAL, чтобы покрыть расчетную потребность до следующей контрольной точки, а остальные удаляет. Оценка основана на скользящем среднем количестве файлов WAL, использованных в предыдущих циклах контрольных точек. Скользящее среднее немедленно увеличивается, если фактическое использование превышает оценку, поэтому оно в некоторой степени учитывает пиковое использование, а не среднее использование. min_wal_size устанавливает минимум количества файлов WAL, перерабатываемых для будущего использования; такое большое количество WAL всегда перерабатывается для использования в будущем, даже если система простаивает, а оценка использования WAL предполагает, что требуется небольшое количество WAL.

Независимо от max_wal_size самые последние wal_keep_size мегабайты файлов WAL плюс один дополнительный файл WAL сохраняются все время. Кроме того, если используется архивация WAL, старые сегменты не могут быть удалены или переработаны до тех пор, пока они не будут заархивированы. Если архивирование WAL не поспевает за темпами создания WAL или если archive_command или archive_library повторяется сбой, старые файлы WAL будут накапливаться в pg_wal , пока ситуация не разрешится. Медленный или неисправный резервный сервер, использующий слот репликации, будет иметь тот же эффект (см. раздел 27.2.6).

В режиме восстановления из архива или в режиме ожидания сервер периодически выполняет точек перезапуска , которые аналогичны контрольным точкам при нормальной работе: сервер принудительно записывает все свое состояние на диск, обновляет pg_control , чтобы указать, что уже обработанные данные WAL не нужно снова сканировать, а затем повторно использует все старые файлы сегментов журнала в каталоге pg_wal . Точки перезапуска не могут выполняться чаще, чем контрольные точки на первичном сервере, поскольку точки перезапуска могут выполняться только в записях контрольных точек. Точка перезапуска запускается при достижении записи контрольной точки, если с момента последней точки перезапуска прошло не менее checkpoint_timeout секунд или если размер WAL вот-вот превысит max_wal_size . Однако из-за ограничений на то, когда может быть выполнена точка перезапуска, max_wal_size часто превышается во время восстановления на величину до одного цикла контрольной точки WAL. ( max_wal_size в любом случае никогда не является жестким ограничением, поэтому вы всегда должны оставлять достаточно места, чтобы избежать нехватки места на диске.)

Существуют две часто используемые внутренние функции WAL: XLogInsertRecord и XLogFlush . XLogInsertRecord используется для помещения новой записи в буферы WAL в разделяемой памяти. Если нет места для новой записи, XLogInsertRecord придется записать (переместить в кеш ядра) несколько заполненных буферов WAL. Это нежелательно, так как XLogInsertRecord используется для каждой модификации нижнего уровня базы данных (например, вставки строки) в то время, когда на затрагиваемых страницах данных удерживается монопольная блокировка, поэтому операция должна выполняться как можно быстрее. Что еще хуже, запись буферов WAL также может привести к созданию нового сегмента журнала, что занимает еще больше времени. Обычно буферы WAL должны быть записаны и очищены Запрос XLogFlush , который выполняется, по большей части, во время фиксации транзакции, чтобы гарантировать, что записи транзакций будут сброшены в постоянное хранилище. В системах с большим количеством выходных данных журнала запросы XLogFlush могут выполняться недостаточно часто, чтобы предотвратить необходимость записи XLogInsertRecord . В таких системах следует увеличить количество буферов WAL, изменив параметр wal_buffers. Когда full_page_writes установлен и система очень занята, установка wal_buffers выше поможет сгладить время отклика в течение периода, непосредственно следующего за каждой контрольной точкой.

Параметр commit_delay определяет, сколько микросекунд процесс-лидер групповой фиксации будет бездействовать после получения блокировки в пределах XLogFlush , в то время как последователи групповой фиксации выстраиваются в очередь позади лидера. Эта задержка позволяет другим серверным процессам добавлять свои записи фиксации в буферы WAL, чтобы все они были очищены возможной операцией синхронизации лидера. Спящий режим не произойдет, если fsync не включен или если в активных транзакциях в настоящее время находится менее чем commit_siblings других сеансов; это позволяет избежать сна, когда маловероятно, что какой-либо другой сеанс будет зафиксирован в ближайшее время. Обратите внимание, что на некоторых платформах разрешение запроса на спящий режим составляет десять миллисекунд, так что любые ненулевые значение commit_delay от 1 до 10000 микросекунд будет иметь тот же эффект. Также обратите внимание, что на некоторых платформах спящие операции могут занимать немного больше времени, чем требуется параметром.

Поскольку цель commit_delay состоит в том, чтобы позволить стоимости каждой операции очистки амортизироваться между одновременно совершаемыми транзакциями (возможно, за счет задержки транзакции), необходимо количественно оценить эту стоимость, прежде чем параметр можно будет выбрать разумно. Чем выше эта стоимость, тем эффективнее 9Ожидается, что 0011 commit_delay увеличит пропускную способность транзакций до определенного момента. Программу pg_test_fsync можно использовать для измерения среднего времени в микросекундах, которое занимает одна операция очистки WAL. Значение, составляющее половину среднего времени, которое, по сообщениям программы, требуется для очистки после одной операции записи 8 КБ, часто является наиболее эффективной настройкой для commit_delay , поэтому это значение рекомендуется использовать в качестве отправной точки при оптимизации для конкретной рабочей нагрузки. При настройке commit_delay особенно полезен, когда журнал WAL хранится на вращающихся дисках с высокой задержкой, преимущества могут быть значительными даже на носителях с очень быстрым временем синхронизации, таких как твердотельные накопители или массивы RAID с кэшем записи с резервным питанием от батареи; но это обязательно должно быть проверено на репрезентативной рабочей нагрузке. В таких случаях следует использовать более высокие значения commit_siblings , тогда как меньшие значения commit_siblings часто полезны на носителях с более высокой задержкой. Обратите внимание, что вполне возможно, что установка 9Слишком большое значение 0011 commit_delay может увеличить задержку транзакций настолько, что пострадает общая пропускная способность транзакций.

Когда commit_delay установлен в ноль (по умолчанию), по-прежнему возможно возникновение формы групповой фиксации, но каждая группа будет состоять только из сеансов, которые достигают точки, в которой им необходимо очистить свои записи фиксации во время окно, в котором происходит предыдущая операция сброса (если она была). При большем количестве клиентов имеет тенденцию возникать «эффект трапа», так что влияние групповой фиксации становится значительным, даже когда commit_delay равно нулю, поэтому явное задание commit_delay помогает меньше. Установка commit_delay может помочь только в том случае, если (1) есть несколько одновременно совершаемых транзакций и (2) пропускная способность в некоторой степени ограничена скоростью фиксации; но с высокой задержкой вращения этот параметр может быть эффективным для увеличения пропускной способности транзакций всего с двумя клиентами (то есть, один фиксирующий клиент с одной родственной транзакцией).

Параметр wal_sync_method определяет, как PostgreSQL будет запрашивать у ядра принудительную запись обновлений WAL на диск. Все варианты должны быть одинаковыми по надежности, за исключением fsync_writethrough , что иногда может привести к принудительной очистке кэша диска, даже если другие параметры этого не делают. Тем не менее, какая из них будет самой быстрой, зависит от конкретной платформы. Вы можете протестировать скорость различных опций с помощью программы pg_test_fsync. Обратите внимание, что этот параметр не имеет значения, если fsync отключен.

Включение параметра конфигурации wal_debug (при условии, что PostgreSQL был скомпилирован с его поддержкой) приведет к тому, что каждый XLogInsertRecord и XLogFlush Вызов WAL регистрируется в журнале сервера. Этот вариант может быть заменен более общим механизмом в будущем.

Существуют две внутренние функции для записи данных WAL на диск: XLogWrite и issue_xlog_fsync . Когда track_wal_io_timing включен, общее количество времени XLogWrite записи и issue_xlog_fsync синхронизации данных WAL с диском считается как wal_write_time и wal_sync_time в pg_stat_wal соответственно. XLogWrite обычно вызывается XLogInsertRecord (когда нет места для новой записи в буферах WAL), XLogFlush и модулем записи WAL для записи буферов WAL на диск и вызова issue_xlog_fsync . issue_xlog_fsync обычно вызывается XLogWrite для синхронизации файлов WAL с диском. Если wal_sync_method равно open_datasync или open_sync , операция записи в XLogWrite гарантирует синхронизацию записанных данных WAL на диск, а issue_xlog_fsync ничего не делает. Если wal_sync_method равно fdatasync , fsync или fsync_writethrough , операция записи перемещает буферы WAL в кэш ядра, а issue_xlog_fsync синхронизирует их с диском. Независимо от настройки track_wal_io_timing количество раз, когда XLogWrite записывает и issue_xlog_fsync синхронизирует данные WAL на диск, также считается равным 9.0011 wal_write и wal_sync в pg_stat_wal соответственно.

Параметр recovery_prefetch можно использовать для сокращения времени ожидания ввода-вывода во время восстановления, указав ядру инициировать чтение блоков диска, которые скоро потребуются, но в настоящее время не находятся в пуле буферов PostgreSQL. Параметры Maintenance_io_concurrency и wal_decode_buffer_size ограничивают параллелизм и расстояние предварительной выборки соответственно. По умолчанию установлено значение try , что включает функцию в системах, где posix_fadvise доступен.

innodb — mysql 5.6 очищает все грязные страницы при ротации ib_logfile, создавая остановку контрольной точки

спросил

3 года, 1 месяц назад

Изменено 3 года назад

Просмотрено 216 раз

Версия сервера: 5.6.23-72.1-log Percona

Я пытался выяснить, почему наш сервер mysql имеет точную контрольную точку, и, похоже, это коррелирует с ротацией файла ib_logfile.

Я унаследовал этот mysql-сервер Percona 5.6, и он приостанавливался для четкой контрольной точки / полной грязной очистки один раз в день с innodb_log_file_size размером 1 ГБ. Я подумал, что, возможно, это был недостаточный размер файла журнала, и увеличил его до 25 ГБ. Теперь мы просто сталкиваемся с тем же поведением реже. Для меня это было своего рода загадкой, пока я не смог убедиться, что это произошло при переключении файла журнала.

Документы Mysql 5.5: https://dev.mysql.com/doc/refman/5.5/en/innodb-checkpoints.html: «… когда InnoDB начинает повторно использовать файл журнала, он должен убедиться, что образы страниц базы данных на диске содержат изменения, зарегистрированные в файле журнала, который InnoDB собирается повторно использовать. Другими словами, InnoDB должна создать контрольную точку, и это часто включает сброс измененных страниц базы данных на диск».

Документы Mysql 5.6 опускают этот бит и говорят, что все, что он должен делать, это нечеткие контрольные точки в обычных обстоятельствах. https://dev.mysql.com/doc/refman/5.6/en/innodb-checkpoints.html: «InnoDB реализует механизм контрольных точек, известный как нечеткие контрольные точки. InnoDB сбрасывает измененные страницы базы данных из пула буферов небольшими партиями. нет необходимости сбрасывать пул буферов одним пакетом, что нарушит обработку пользовательских операторов SQL в процессе создания контрольных точек».

Есть ли способ свести к минимуму или выйти из этого поведения, если оно неожиданно?

 | innodb_adaptive_flushing | НА |
| innodb_adaptive_flushing_lwm | 10 |
| innodb_buffer_pool_size | 46170898432 |
| innodb_change_buffer_max_size | 25 |
| innodb_change_buffering | вставки |
| innodb_checksum_algorithm | innodb |
| innodb_checksums | НА |
| innodb_cleaner_lsn_age_factor | high_checkpoint |
| innodb_doublewrite | НА |
| innodb_empty_free_list_algorithm | отсрочка |
| innodb_file_format | Барракуда |
| innodb_file_per_table | НА |
| innodb_flush_log_at_timeout | 1 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_flush_method | О_ПРЯМОЙ |
| innodb_flush_neighbors | 0 |
| innodb_flushing_avg_loops | 30 |
| innodb_force_load_corrupted | ВЫКЛ |
| innodb_force_recovery | 0 |
| innodb_foreground_preflush | экспоненциальный_откат |
| innodb_io_capacity | 3000 |
| innodb_io_capacity_max | 6000 |
| innodb_log_arch_dir | .
%MINIFYHTML291cd01dd0e746cc618aa8222e19662f23%/ |
| innodb_log_arch_expire_sec | 0 |
| innodb_log_archive | ВЫКЛ |
| innodb_log_block_size | 512 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_checksum_algorithm | innodb |
| innodb_log_compressed_pages | НА |
| innodb_log_file_size | 26843545600 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_lru_scan_depth | 2048 |
| innodb_max_changed_pages | 1000000 |
| innodb_max_dirty_pages_pct | 50 |
| innodb_max_dirty_pages_pct_lwm | 0 |
| innodb_max_purge_lag | 200 |
| innodb_max_purge_lag_delay | 0 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 1000 |
| innodb_online_alter_log_max_size | 134217728 |
| innodb_open_files | 384 |
| innodb_page_size | 16384 |
| innodb_purge_batch_size | 20 |
| innodb_purge_threads | 1 |
| innodb_random_read_ahead | ВЫКЛ |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 4 |
| innodb_read_only | ВЫКЛ |
| innodb_rollback_on_timeout | ВЫКЛ |
| innodb_rollback_segments | 128 |
| innodb_sched_priority_cleaner | 19|
| innodb_sort_buffer_size | 1048576 |
| innodb_spin_wait_delay | 6 |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | НА |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_global_flush_log_at_trx_commit | НА |
| innodb_use_native_aio | НА |
| innodb_use_sys_malloc | НА |
| innodb_версия | 5.%MINIFYHTML291cd01dd0e746cc618aa8222e19662f24% 6.23-72.1 |
| innodb_write_io_threads | 8 |
 

• innodb
• mysql-5.6

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

Я бы попробовал повысить порог innodb_adaptive_flushing_lwm и понизить innodb_max_dirty_pages_pct , чтобы сделать очистку страниц более активной.

В этой статье есть дополнительные советы и ссылки

6

Исправление от Percona MySQL 5.6.23 до 5.6.47 и включение innodb_numa_interleave устранили эту проблему.