Месяц исследований и экспериментов. Миллионы убитых нервных клеток. Сотни злых пользователей сайта. Итак.

Дано:
10.0.38-MariaDB-0+deb8u1 (также тестировалось на percona)
Linux server 4.9.0-0.bpo.6-amd64
Пустой mysql конфиг (для чистоты эксперимента)
ДБ размером 40ГБ на InnoDB
2 SSD raid1

Запустим тестовый сервис с максимально ограниченными ресурсами на использование диска.



atop, iotop, iostat показывают минимальную нагрузку на диск (10mb/s). И в где-то в середине выполнения dd, в 9 случаев из 10, ВСЕ(!) таблицы на innodb намертво зависают (селект не выполняется) на пару минут, в то время как ВСЕ таблицы на myisam доступны (селект выполняется).

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

Проблема не в производительности дисков и не в аппаратуре. В ДЦ заменяли диски и другие комплектующие по 2 раза. Проблема таится где-то в самом процессе работы InnoDB с диском. Мне сложно интерпретировать свои мысли на этот счет, так как не знаю всех технических нюансов.

Вы можете сказать - дружище, возьми второй диск, поставь на него отдельно mysql и не парься! На что я вам скажу, что это не выход. Даже при бекапе через xtrabackup всё виснет.

Так что же мне делать? Прошу помощи.

Спасибо за ответы.

"А почему такая старая ветка?"
- Обновлюсь до последней и перепроверю.

"Какой объем дисков?"
- 2 диска по 240

"Пустой конфиг - тоже не здорово"
- да, надо было сразу рабочий выставить. Вот действующий конфиг, на котором зависает: https://anotepad.com/notes/2xf43nww


innodb_flush_log_at_trx_commit стоит 2. Попробую поставить 1.
Также попытаюсь выключить innodb_use_native_aio

На сервере всего 32гб оперативки и мне удалось поставить только innodb_buffer_pool_size = 25гб для тестов, когда объем иннодб таблиц 29ГБ (не 40, как писал в 1 посте). Результаты были точно такими же. Неужели это значение должно быть обязательно больше объема иннодб таблиц? Я где-то читал, что не критично, но в моем случае, если это является истинной причиной зависания диска, то критично. Наверное, мне стоит запустить мускл с текущим конфигом на проекте с 5-8гб innodb и проверить.

"Для чистоты эксперимента возьми за 1тыщ материнку под старый Core2Duo..."
- У меня дедик в ДЦ.

"так как диск фрагментируется"
- у меня SSD

"Вообще такие зависоны могут быть элементарно даже из за перегрева дисков, не 37-38 градусов, а 40 - и все..."
- Нет

"Ну и ты классно придумал -- врубить все параметры по дефолту, ничего не выделять под кэш, который -- главное достоинство INNO,"
- Я тестил как на рабочем, так и на дефолтном - проблема идентична. Выше уже предоставил свой рабочий.

"да ещё и IO как-то искусственно ограничить..."
- Читайте внимательнее, пожалуйста. Использование диска в примере было ограничено для выполнения определенной команды для демонстрации абсурдности проблемы: диск не загружен практически совсем, а mysql зависает.

Спасибо, попробую.

innodb_thread_concurrency=0 решило все проблемы :)

miksoft,

4 ядра 8 потоков.

"Короче у тебя стояло потоков=4, это было очень периодически мало, при всплесках количества пользователей."
- Не уверен как оно работает, но мне кажется, что когда я выставил 0 mysql более умным образом использовать потоки при стресс нагрузке, а при 4 просто впадал в лок.