Рейтинг:1

Кэш MariaDB отключается за одну ночь

флаг cn

Мы используем стек LAMP, который включает MariaDB 10.5.15 на Centos 7. Это выделенный сервер с 4 процессорами и 8 ГБ ОЗУ.

Никогда не было проблем до последних нескольких недель, когда я заметил медленные запросы, занимающие 8-9 секунд в журнале медленных запросов.

Эти запросы относятся к нескольким базам данных INNODB, но всегда к большим таблицам (т. е. более 10 000 строк). Они всегда происходят между часами 6am и 8am.

Рассматриваемые таблицы имеют индексы, и одни и те же запросы обычно выполняются менее чем за секунду.

Я обнаружил, что, зайдя на сервер в 8 утра в воскресенье и запросив эти большие таблицы с помощью простых операторов select, они выполнялись за 8-9 секунд. Затем до конца дня, даже после полуночи, любые запросы к этой таблице будут выполняться быстро.

С 6 до 8 утра все «оживает» после периода бездействия в ранние часы.

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

Мы отслеживаем загрузку процессора 24/7 и периодически проверяем количество подключений к Apache и MariaDB, которые остаются умеренно низкими в течение дня. Обычно свободно около 3 ГБ памяти без учета буферов и кеша.

Редактировать

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

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

Рейтинг:0
флаг ua

Вы, кажется, исключили ночной сброс и какой-то медленный процесс?

Дополнительные предложения по отладке:

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

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

Проверять ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК "Время работы" Если это значение меньше 86400, то MariaDB перезапустилась менее 24 часов назад. В этом случае вы сможете зафиксировать время почти с точностью до секунды. (но не определить причину).

Покажите нам запрос, плюс ПОКАЗАТЬ СОЗДАТЬ ТАБЛИЦУ и ОБЪЯСНЯТЬ... Возможно, мы сможем помочь вам ускорить его (например, улучшив индекс или переформулировав запрос), тем самым устранив проблему (хотя и не устранив причину).

MrCarrot avatar
флаг cn
`uptime` несколько дней назад (поскольку мы в последний раз перезапускали вручную). Я не думаю, что просмотр схемы таблицы поможет, потому что это влияет на несколько таблиц в нескольких базах данных (все большие, но все используют соответствующие индексы). Вчера я запустил crobjob, который вызывал один из запросов каждые 15 минут, надеясь точно определить время, когда что-то пойдет не так (я подозреваю, что в 6 утра, но может быть и раньше). Сегодня утром медленных запросов не зарегистрировано. Возможно, задание cron поддерживало базу данных в тепле, или это могло быть совпадением. Я оставлю это на несколько дней, а затем уменьшу параметр `long_query_time`
MrCarrot avatar
флаг cn
К своему стыду, я обнаружил, что рассматриваемые медленные запросы на самом деле не использовали индексы и выполняли полное сканирование таблицы. Первоначальный запрос может занять несколько секунд, а в остальное время даже полное сканирование таблицы занимает меньше секунды. Я предполагаю, что это какой-то дисковый кеш, который остынет за ночь. Хотя проблемы с производительностью при полном сканировании таблицы могут показаться обычными, все же кажется странным, что это внезапно стало проблемой ни с того ни с сего.
флаг ua
@MrCarrot - Кэширование диска ... У вас есть аппаратный RAID-контроллер? Вы работаете в облаке? Если «нет» для обоих, я бы не ожидал, что «дисковый кеш» будет ответом. InnoDB использует свой «buffer_pool» в оперативной памяти.
MrCarrot avatar
флаг cn
Диск представляет собой SSD-накопитель с RAID1 (это выделенный сервер). Я беспокоился, что диск вышел из строя или массив RAID перегружен, но хостинговая компания утверждает, что все в порядке. Я предполагаю, что это может быть холодный буферный пул.

Ответить или комментировать

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