Оптимизация MySQL под 1 ГБ RAM

MAATRIX

MySQL на маленьком VPS ведёт себя капризно: то падает с ошибкой памяти, то тормозит, то его убивает OOM-killer в самый неподходящий момент. Причина почти всегда в конфиге по умолчанию, который рассчитан на сервер помощнее. Оптимизация MySQL под 1 ГБ RAM — это грамотный тюнинг буферов и отключение лишнего, чтобы база стабильно работала в тесной памяти. Ниже разберём по шагам, что именно настроить, с готовым конфигом и командами.

Почему MySQL не влезает в 1 ГБ

Конфигурация MySQL и MariaDB по умолчанию довольно прожорлива к памяти, а некоторые сборки и вовсе рассчитаны на серверы с несколькими гигабайтами. На VPS с одним гигабайтом это приводит к тому, что база пытается занять больше памяти, чем есть, система уходит в своп, а при пике MySQL завершается с ошибкой или его убивает ядро из-за нехватки RAM. Отдельная беда — соседи по серверу: если рядом с базой на том же гигабайте живут веб-сервер и PHP, памяти не остаётся совсем.

Ключ к пониманию — из чего складывается потребление. MySQL тратит память на глобальные буферы, которые выделяются один раз (главный из них — буферный пул InnoDB), и на буферы под каждое соединение, которые умножаются на число одновременных подключений. На маленьком сервере важно и то, и другое: слишком большой глобальный буфер не влезет, а слишком большие пер-коннект буферы при десятках соединений съедят память суммарно. Задача тюнинга — уместить всё это в доступный гигабайт с запасом на систему.

Полезно прикинуть простую арифметику памяти, чтобы настройка не была гаданием. Возьмите весь объём сервера, вычтите то, что нужно операционной системе и другим процессам — на гигабайтной машине это обычно 150–250 МБ на систему и ещё столько же, если рядом крутится веб-сервер с PHP. Остаток делится между глобальными буферами базы и суммой пер-коннект буферов. Отсюда видно, почему на одном гигабайте нельзя одновременно держать большой буферный пул и полторы сотни разрешённых соединений: либо одно, либо другое, на оба сразу памяти не хватит. Именно поэтому на тесном сервере разумнее держать умеренный буферный пул и жёстко ограниченное число соединений, а не пытаться разогнать оба параметра. Если приложению действительно нужно много одновременных подключений, лучше поставить перед базой пул соединений, который переиспользует небольшое число реальных коннектов, чем открывать сотню прямых.

Оценка текущего потребления

Прежде чем крутить настройки, посмотрите, сколько памяти есть и сколько занимает база сейчас:

free -h
systemctl status mysql
ps aux --sort=-%mem | head -n 5

free -h покажет, ушла ли система в своп — если своп активно занят, памяти не хватает. Затем посмотрите, какие значения выставлены в самой базе. Подключитесь к MySQL и проверьте текущий размер буферного пула и лимит соединений:

mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; SHOW VARIABLES LIKE 'max_connections';"

Если буферный пул выставлен в сотни мегабайт при гигабайте всей памяти, а max_connections держится на дефолтных 150, это прямые кандидаты на урезание. Дальше приведём конфиг к реалиям маленького сервера.

Готовый конфиг для 1 ГБ RAM

Создайте файл /etc/mysql/mysql.conf.d/tuning.cnf (или добавьте в основной my.cnf) следующие параметры под тесную память:

[mysqld]
innodb_buffer_pool_size = 256M
innodb_log_file_size = 64M
max_connections = 40
performance_schema = OFF
tmp_table_size = 16M
max_heap_table_size = 16M
key_buffer_size = 16M

Разберём главное. innodb_buffer_pool_size — самый важный параметр, кеш данных и индексов InnoDB; на гигабайте разумно отдать под него около четверти памяти, оставив место системе и соединениям. max_connections = 40 ограничивает число одновременных подключений: держать дефолтные 150 на маленьком сервере опасно, потому что каждое соединение тоже ест память. performance_schema = OFF отключает подсистему сбора статистики, которая сама по себе занимает десятки мегабайт и на маленьком сервере не нужна. Буферы временных таблиц урезаны, чтобы тяжёлые запросы не раздували память. После правки перезапустите базу:

systemctl restart mysql

Настройте swap как страховку

На сервере с тесной памятью swap — не роскошь, а страховка от внезапного убийства процессов. Он не заменяет оперативную память и не делает базу быстрее, но не даёт системе рухнуть при кратковременном всплеске потребления. Если swap ещё не настроен, создайте файл подкачки на пару гигабайт:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Заодно понизьте параметр vm.swappiness до 10, чтобы система прибегала к свопу только при реальной нехватке, а не гоняла в него данные раньше времени. Помните: если база постоянно живёт в свопе, это не решение, а сигнал, что памяти реально мало — swap лишь смягчает пики, а не заменяет RAM.

Оптимизация самих запросов

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

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

Отдельно проверьте движок таблиц. Если в базе остались старые таблицы на устаревшем MyISAM, они используют собственный механизм кеширования и плохо уживаются с InnoDB на тесной памяти, потому что вы фактически содержите два разных кеша вместо одного. Перевод таблиц на InnoDB позволяет отдать всю память под единый буферный пул и убрать дублирование. Также имеет смысл периодически запускать оптимизацию таблиц, чтобы база не таскала за собой разросшиеся от многочисленных удалений и вставок файлы: на маленьком сервере лишние гигабайты на диске и раздутые индексы бьют по производительности заметнее, чем на большом.

Когда гигабайта уже мало

Честно о пределах. Оптимизация творит чудеса, но не отменяет физику: если база выросла, данных стало много и активных пользователей десятки, один гигабайт становится узким местом, сколько его ни тюнингуй. Признаки очевидны — база постоянно в свопе даже после тюнинга, запросы тормозят несмотря на индексы, OOM-killer срабатывает регулярно. Это нормальная часть эксплуатации сервера: проект перерос стартовый тариф. В этот момент разумнее добавить памяти, чем героически ужимать базу дальше. Апгрейд VPS у MAATRIX делается без переезда — вы повышаете тариф до 2–4 ГБ RAM и продолжаете работу на том же сервере, с оплатой из России картой или криптой.

Частые вопросы