Падение производительности MySQL

Установил BitrixEnv 5.0.44, перенес сайт, проверил в мониторе производительности конфигурацию. На чтение из БД она давала 15 000 операций в секунду.
Главная страница сайта (280 запросов) требовала 1,9 с.

Ок, перенес со старого сайта настройки MySQL (все внес в /etc/mysql/conf.d/z_bx_custom.cnf). Получил при той же производительности уже 1,3 с. (там я по совету монитора производительности делал настройки).

Решил улучшить результат и занялся настройкой буферов InnoDB. Я тогда настраивал буферы временных таблиц (tmp_table_size и max_heap_table_size). Перегрузил MySQL, а проверками занялся только через 10 часов.

В итоге получил 12 с на главной! Убрал свои настройки (переименовал z_bx_custom.cnf в z_bx_custom.cnf.bx) - все равно 12 с.
Тогда какие-то внешние причины. Ок, проверил с помощью sysbench производительность диска - она не изменилась!

Монитор производительности сначала казал теже 15 000, а потом 7 000 (тут на 100% не поручусь, работа шла в истерично-нервном режиме, в итоге точно 7000).

Это похоже на колдовство, но мы, все-таки, имеем дело с софтом и железом ...
Я точно вернул все как было в настройках, но при этом что-то изменилось.
MySQL не переустанавливал (осталось таким образом пересоздать системную БД).

Я с большим трудом получил 1,8 с установив innodb_buffer_pool_size в 10ГБ.
Но и здесь была мистика - я видел и 0,5 с. Но эти замечательные данные пропали в результате "дерганья" настроек.

В один прекрасный момент при перегрузке MySQL я видел ошибку с перечислением кучи динамических библиотек. В логе MySQL же было "Error in opening ./ibdata1". Файл же на месте был! Для гарантии после этой ошибки я удалил все файлы INNODB и стартовал сервер заново (чтобы не думать, что есть файлы несоответствующие друг другу), залил заново БД из дампа. Но и это не помогло.

В БД не так много данных (вместе со статистикой 1,5ГБ).

У меня железный сервер и 96 ГБ ОЗУ. Два процессора по 4 ядра, поддержка HT.
Диски дают 260 МБ/c на последовательной записи со случайным чтением.
Диски SSD.

Такого безобразия на этом железе не может быт, но оно есть!

Но что обидно - нет явной зависимости от чего бы то ни было. Что можно еще проверить? У кого было подобное, как решили вопрос?

Добавлено:

Проверил производительность процессора (на одном ядре). Она не изменилась:


Добавлено 2:

Видел похожую тему, но по Debian (у меня CentOS 6.5). Только там сразу были проблемы (или автор не признался, что игрался с настройками и производительность упала после этого). Решил он свою болячку только переустановкой.

Добавлено 3:

Делал также тесты БД в мониторе производительности и в sysbench.

Монитор сейчас дает (запуска с интервалом между ними 5 с):

База данных MySQL (запись)     7 035
База данных MySQL (чтение)     11 888
База данных MySQL (изменение)     6 433

База данных MySQL (запись)     9 015
База данных MySQL (чтение)     11 706
База данных MySQL (изменение)     6 664

По чтению из БД в этом тесте бывало и 7 000.

Этим данным особой веры нет - там тест сам по себе сомнительный. Можете сами посмотреть CPerfomanceMeasure::GetDBMark (\bitrix\modules\perfmon\classes\general\measure.phpl\bitrix\modules\perfmon\classes\general\measure.php). Тест идет на 100 запросов INSERT, SELECT, UPDATE по 4 раза. Считают микросекунды с коррекцией времени на время работы PHP. Идет усреднение четырех измерений. Каждое изменение перед усреднением перводится в скорость (запросы в секунду). Скакать он должен по родовым признакам. Полезен здесь достигнутый максимум и минимум.

Было до странного падения производительности:

База данных MySQL (запись) 7 484
База данных MySQL (чтение)  15 059
База данных MySQL (изменение)  6 681

sysbench гонял только после возникновения проблем.

# sysbench --test=oltp --oltp-table-size=1000000 --db-driver=mysql --mysql-socket=/var/lib/mysqld/mysqld.sock --mysql-db=test --mysql-user=root --max-time=60 --oltp-read-only=on --max-requests=0 --num-threads=8 run

OLTP test statistics:
   queries performed:
 read:    772674
 write:   0
 other:   110382
 total:   883056
   transactions: 55191  (919.75 per sec.)
   deadlocks:   0 (0.00 per sec.)
   read/write requests:     772674 (12876.47 per sec.)
   other operations:  110382 (1839.50 per sec.)