MySQL (6TB Data) Сервер Hick Ups
У нас есть MySQL Setup под управлением Percona 5.7 (5.7.12-5-1.trusty) (36 ядер, 768 ГБ памяти, 3.5 ТБ Raid-10 из 8 SSD). Размер БД составляет около 6 ТБ, некоторые таблицы больше 1 ТБ с миллиардом записей. В среднем у нас около 12-18,0000 запросов в секунду (около 70% из них - SELECT).
Также мы используем ZFS со сжатием lz4 и размером записи 16k.
Mysql Master иногда перестает отвечать на запросы вовремя и собирает множество соединений и больше не отвечает клиентам больше минуты.
В медленных журналах запросов мы видим, что все медленные запросы группируются с одинаковыми 0,1 секунды. Например:
SELECT time, COUNT(*) FROM slow_query_log WHERE time BETWEEN '2016-08-26 13:16:00' AND '2016-08-26 13:19:00'
...
'2016-08-26 13:16:46', '1'
'2016-08-26 13:16:55', '1'
'2016-08-26 13:17:00', '1'
'2016-08-26 13:17:09', '1'
'2016-08-26 13:17:21', '1'
'2016-08-26 13:18:08', '340'
'2016-08-26 13:18:10', '1'
'2016-08-26 13:18:29', '1'
'2016-08-26 13:18:50', '1'
...
Мы видим одну и ту же картинку 2 раза в час. Что еще более интересно, все медленные запросы в этот момент имеют примерно одинаковое время запроса 15-25 секунд, даже такие запросы, как select @@session.tx_read_only; #17 sec или же SHOW GLOBAL STATUS; #21 sec, Сначала мы подумали, что у нас может быть несколько сложных запросов, но потом мы нашли select @@session.tx_read_only; медленные запросы, которые должны выполняться мгновенно, и становятся полностью запутанными.
Мы не видим никаких блокировок, зависших запросов, долго выполняющихся запросов, системной блокировки или чего-либо еще, когда это происходит, ничего в лог-файле тоже нет.
Другие части конфигурации:
innodb_adaptive_hash_index = OFF
innodb_doublewrite = OFF
skip-innodb_doublewrite
innodb-log-files-in-group = 2
innodb-log-file-size = 512M
innodb-flush-log-at-trx-commit = 2
innodb-file-per-table = 1
innodb-buffer-pool-size = 400G
innodb_buffer_pool_instances = 32
innodb_write_io_threads = 64
innodb_read_io_threads = 64
innodb_flush_neighbors = 0
innodb_adaptive_hash_index = OFF
innodb_use_native_aio = 0
performance_schema=off
размер пула буферов по причине составляет 400 ГБ. Каждый раз, когда мы поднимаем это в качестве примера до 450, или даже до 650, мы получаем "полные" зависания БД в течение нескольких минут с произвольными интервалами. Также, если мы соответственно установим правильные значения экземпляра пула для более высокого пула буферов. adaptive_hash_index выключен, потому что в противном случае усеченная таблица полностью сломает базу данных, а также замерзнет, но это хорошо известная ошибка с адаптивным хеш-индексом и большими буферными пулами. native_aio отключен из-за ZFS. Схема производительности также отключена по причинам производительности.
все в порядке, никаких проблем с дугами ZFS или что-то еще Загрузка ЦП почти никогда не превышает 40% доступных ресурсов. Достаточно свободной памяти и т. Д.
Кто-нибудь получил представление о том, как отладить эту проблему? И да, мы знаем, что не стоит хранить столько данных в mysql;)