VestaCP, нехватка памяти и падения MySQL

Довольно продолжительное время на своём VDS я использовал панель ISPmanager, лицензия на которую входила в месячную плату и не требовала дополнительных расходов. Всё устраивало, но недавно условия изменились и за лицензию попросили дополнительную ежемесячную плату. Поэтому у меня встал вопрос о смене панели на бесплатную и выбор пал на VestaCP. Установка панели весьма проста (особенно на чистый сервер), особых нареканий ничто не вызывает, хоть в Vesta и нет всех функций, доступных в ISPmanager.

В общем, на первый взгляд всё хорошо, но по прошествии времени оказалось, что не совсем. А если точнее, то начались регулярные падения сервера MySQL, в результате чего все сайты стали часто и подолгу «лежать». Сразу стало понятно, что что-то неистово пожирает скромный 1 Гб памяти на моём сервере, в результате чего и перестаёт работать MySQL. Будь я профессиональным Linux-администратором, наверняка бы быстро решил вопрос и не счёл бы его большой проблемой. Но будь я таким специалистом, то и VestaCP скорее всего мне была бы ни к чему, а все настройки делал бы исключительно руками. А так вот пришлось потратить энное количество дней на поиски вариантов решения. Забегая вперёд скажу, что мне удалось добиться стабильного освобождения около 200 Мб памяти, что позволило решить проблему.

Несколько команд для проверки использования памяти

top — монитор процессов.

htop — улучшенный монитор.

free -m — информация о памяти.

ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' — информация об использовании памяти конкретными процессами.

Обращаю внимание на один момент при использовании утилит top и htop. Дело в том, что показатели в них могут сильно разниться, из-за того, что память они считают по-разному. Вопрос сейчас не в этом, поэтому я предоставлю интересующимся загуглить и узнать об этом самостоятельно или же посмотреть на выдачу free -m, что также может объяснить некоторые вещи. В общем, не верьте htop 🙂

Отключаем (удаляем) ClamAV и SpamAssassin

Не думаю, что большинству рядовых пользователей нужны эти сервисы на их «домашних» VDS. А если ещё и ресурсы сервера сильно ограничены, то тем более. ClamAV весьма прожорлив и если у вас 1 Гб памяти (а меньше тем более), то он вам противопоказан. Отключить данные сервисы можно из самой панели в разделе Server, нажав Stop. В этом случае они будут остановлены, но при перезапуске сервера запустятся снова. Можно убрать из автозапуска, это делается по-разному в зависимости от дистрибутива. Инструкций масса, поэтому прошу воспользоваться поиском. Я же подошёл кардинально — удалил их. Вряд ли они когда-то пригодятся на сервере со столь малыми ресурсами. Тем более поставить обратно особых трудностей не составляет. Для удаления:

apt-get remove --purge spamassassin

apt-get remove --purge clamav-daemon

Теперь можно посмотреть на состояние памяти вышеназванными утилитами. Вероятно, что даже этого будет достаточно и проблема дефицита ОЗУ отпадёт. Но всё может оказаться не так просто и вы будете продолжать наблюдать нездоровый аппетит самого MySQL-сервера, а это значит, что нужно копать дальше в сторону его конфигурации, которую в варианте по умолчанию, сложно назвать оптимальной.

Оптимизация настроек MySQL-сервера

Нас будет интересовать файл my.cnf. В Debian его можно найти в /etc/mysql/. Далее можно пойти разными путями. Первый — покурить форум VestaCP на тему готовых конфигов для похожей конфигурации сервера и попробовать их. Второй — углубиться в суть дела, использовать специальные утилиты для тестирования MySQL-сервера и запилить оптимальную конфигурацию для себя.

Курить форум — дело нехитрое, поэтому приведу лишь ссылку https://forum.vestacp.com. Для совсем ленивых приведу свою конфигурацию my.cnf, которая меня пока устраивает и позволила добиться адекватных показателей:

[client]
port=3306
socket=/var/run/mysqld/mysqld.sock

[mysqld_safe]
socket=/var/run/mysqld/mysqld.sock

[mysqld]
user=mysql
pid-file=/var/run/mysqld/mysqld.pid
socket=/var/run/mysqld/mysqld.sock
port=3306
basedir=/usr
datadir=/var/lib/mysql
tmpdir=/tmp
lc-messages-dir=/usr/share/mysql
log_error=/var/log/mysql/error.log

symbolic-links=0

skip-external-locking
key_buffer_size = 24M
max_allowed_packet = 1M
table_open_cache = 24M
table_cache = 4096
table_definition_cache = 4096
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 240K
thread_cache_size = 4M
query_cache_limit = 256K
query_cache_size = 256K
query_cache_type = 1

#innodb_use_native_aio = 0
innodb_file_per_table

max_connections=30
max_user_connections=20
wait_timeout=10
interactive_timeout=50
long_query_time=5

!includedir /etc/mysql/conf.d/

Конечно, всё это не претендует на идеальность и использовать эту конфигурацию можете только на свой страх и риск. Но для меня она работает хорошо.

Второй вариант — более сложный, но кому-то может быть интереснее, да и позволит более тонко настроить сервер. К тому же лишним опыт никогда не бывает. Я предлаю использовать две утилиты:

MySQLTuner

Скачать: wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl --no-check-certificate

Запустить: perl mysqltuner.pl или perl mysqltuner.pl --user root --pass rootpassword

В Debian можно установить так: apt-get install mysqltuner и запустить соответствующей командой.

MySQL performance tuning prime

Скачать: wget https://launchpadlibrarian.net/78745738/tuning-primer.sh

Сделать исполняемым: chmod +x tuning-primer.sh

Запустить: ./tuning-primer.sh

Далее внимательно читайте рекомендации, экспериментируйте и да поможет вам Гугл. Надеюсь, что кому-то моя писанина окажется полезна и сэкономит пару-тройку часов времени 😉

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *