Назад | Перейти на главную страницу

Высокая загрузка процессора из-за процесса MySQL

У нас есть веб-сайт Magento на выделенном сервере (Xeon E5-1620, 64 ГБ ОЗУ, SSD), мы не генерируем большого трафика, это довольно небольшой сайт, около 30000 просмотров страниц в месяц, в среднем 100 заказов в день. . Наш магазин работает уже много лет, у нас никогда не было проблем. Несколько недель назад я начал получать жалобы от отдела подготовки заказов на складе о том, насколько медленным был Magento, я заметил высокую загрузку процессора со стороны mysqld.

Я проверил конфигурацию MySQL, и кажется, что это все еще более или менее конфигурация по умолчанию. Я не администратор баз данных и не эксперт в настройке / оптимизации MySQL, поэтому я попытался получить информацию здесь и там и внес некоторые корректировки, начиная с установки innodb_buffer_pool_size и key_buffer_size в my.cnf наряду с некоторыми другими настройками, как показано ниже:

[mysqld]
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
bind-address=127.0.0.1

# What I added below
key_buffer_size=512M
#sort_buffer_size=4M <-- I commented this, it seems better now
#read_buffer_size=4M <-- I commented this, it seems better now
innodb_thread_concurrency=0
innodb_buffer_pool_size=9G
tmp_table_size=128M
max_heap_table_size=128M
skip-name-resolve
query_cache_size=64M

В пятницу все выглядело более-менее нормально, но, придя на работу сегодня утром, нагрузка была выше 8 (8 ядер), Magento почти не отвечал. Я прокомментировал sort_buffer_size=4M и read_buffer_size=4M как видно выше, я взял эти числа немного случайным образом, и теперь через 30 минут после перезапуска это выглядит намного лучше, нагрузка (1, 5 и 15 минут) ниже 2,5.

О стоимости innodb_buffer_pool_size, Я установил расчет рекомендуемого размера пула буферов InnoDB (как объяснено здесь) с помощью этого запроса:

SELECT CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS FROM
    (SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
    FROM information_schema.tables WHERE engine='InnoDB') A;
+-------+
| RIBPS |
+-------+
|     9 |
+-------+

Это уже помогло.

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

ОБНОВЛЕНИЕ - РЕШЕНО: Проблема решена и почти не имеет отношения к оптимизации MySQL (я все равно оптимизировал ее в конце, так как она все еще была с конфигурацией по умолчанию). Для заинтересованных: мы используем модуль Solrbridge для поисковой системы, и в последней версии была ошибка, которая постоянно заполняла таблицу. Я заметил эту новую таблицу на прошлой неделе, самую большую из базы данных 4,9 ГБ, затем в понедельник она выросла до 7,9 ГБ. Я спросил об этом разработчика Solrbridge, и он сказал мне, что я могу обрезать эту таблицу и отключить определенные настройки в Solrbridge. С тех пор все вернулось в норму, средняя загрузка процессора: 0,09 0,12 0,13 на данный момент.

Перед изменением настроек сервера MySQL, особенно если вы не являетесь администратором баз данных, я предлагаю подтвердить, что на сервере нет неисправного диска или неисправного RAID. Это не применяется, если ваше хранилище виртуализировано, но убедитесь, что dmesg вывод не имеет подозрительных сообщений и smartmontools не сообщайте о проблемах с жесткими дисками.

Если проблем с диском нет, дайте MySQL поработать хотя бы несколько часов после последнего перезапуска и используйте такой инструмент, как MySQLTuner-perl для быстрого анализа и индивидуальных предложений. Я могу указать вам на другие инструменты, но, не обладая практическим опытом, я предлагаю не изменять более одного параметра за раз.

Я лично предпочитаю Percona

Этот сайт предлагает бесплатный сервис, основанный на конфигурации вашего сервера, он дает вам оптимальные параметры конфигурации, и я испытал очень хорошие улучшения. Попробуйте