У нас есть веб-сайт 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
Этот сайт предлагает бесплатный сервис, основанный на конфигурации вашего сервера, он дает вам оптимальные параметры конфигурации, и я испытал очень хорошие улучшения. Попробуйте