Установил 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.
Такого безобразия на этом железе не может быт, но оно есть!
Но что обидно - нет явной зависимости от чего бы то ни было. Что можно еще проверить? У кого было подобное, как решили вопрос?
Добавлено:
Проверил производительность процессора (на одном ядре). Она не изменилась:
Код
# sysbench --test=cpu --cpu-max-prime=20000 run
...
total time taken by event execution: 28.6357
....
Добавлено 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 гонял только после возникновения проблем.