SystemdDoctor
служба не работает mysql память частое

MySQL убит из-за памяти: буферный пул больше доступной памяти

Буферный пул InnoDB выделяется при запуске, и его размер задаётся настройкой. Если он больше доступной памяти, сервер либо не стартует, либо его убивает ядро. На небольших виртуальных машинах это самая частая причина внезапных падений после правки настроек.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Размер буферного пула больше доступной памяти

    Настройку часто копируют с более крупного сервера. Память выделяется при старте, поэтому падение происходит сразу или почти сразу.

  2. Много соединений с большими буферами на соединение

    Кроме пула есть буферы на каждое соединение: сортировки, объединения, чтения. При большом числе соединений они складываются и добивают память.

  3. Ограничение памяти у службы ниже потребности

    Если в unit-файле задан предел памяти, сервер убивают при его достижении, даже когда на машине память есть.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Подтверждение, что процесс убило ядро из-за памяти.

journalctl -k -b --no-pager | grep -i "killed process"

Память машины, предел службы и её пиковое потребление.

free -h && systemctl show mysql -p MemoryMax -p MemoryPeak

Сообщения сервера: при нехватке памяти он часто пишет о неудачном выделении.

sudo tail -40 /var/log/mysql/error.log

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Размер буферного пула больше доступной памяти
Почему происходит
Настройку часто копируют с более крупного сервера. Память выделяется при старте, поэтому падение происходит сразу или почти сразу.
Как проверить
Сравните настройку с памятью машины. 
sudo grep -iE "innodb_buffer_pool_size|key_buffer" /etc/mysql/mysql.conf.d/*.cnf /etc/mysql/my.cnf 2>/dev/null
free -h
Как исправить
Установите размер пула в 50–70% памяти машины, оставив запас на остальные процессы и на соединения. 
sudo systemctl restart mysql
2. Много соединений с большими буферами на соединение
Почему происходит
Кроме пула есть буферы на каждое соединение: сортировки, объединения, чтения. При большом числе соединений они складываются и добивают память.
Как проверить
Посмотрите предел соединений и буферы. 
mysql -e "SHOW VARIABLES LIKE 'max_connections'; SHOW VARIABLES LIKE '%buffer_size';" 2>/dev/null | head -20
Как исправить
Снизьте предел соединений или размеры буферов на соединение. Формула проста: память пула плюс предел соединений, умноженный на буферы, должны укладываться в машину с запасом.
3. Ограничение памяти у службы ниже потребности
Почему происходит
Если в unit-файле задан предел памяти, сервер убивают при его достижении, даже когда на машине память есть.
Как проверить
Посмотрите предел и пиковое потребление. 
systemctl show mysql -p MemoryMax -p MemoryPeak
Как исправить
Приведите предел в соответствие с настройками MySQL или уберите его: у базы уже есть свои механизмы ограничения.

Пример вывода

Буферный пул на 4 ГБ на машине с 2 ГБ памяти. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

kernel: Out of memory: Killed process 5200 (mysqld) total-vm:4812480kB, anon-rss:1889024kB
systemd[1]: mysql.service: A process of this unit has been killed by the OOM killer.
systemd[1]: mysql.service: Failed with result 'oom-kill'.

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация MySQL: буферный пул InnoDB документация программы
    сверено 15 сентября 2026
  • systemd.resource-control(5)
    MemoryMax= и поведение при достижении предела.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено на машине с 2 ГБ памяти и пулом 4 ГБ.     собственная проверка, systemd 255
    сверено 15 сентября 2026