Возможный дубликат:
Как диагностировать причины процессов убийства oom-killer
У меня есть веб-сервер Ubuntu (Apache + MySQL + PHP) на очень маленькой машине на Amazon Web Services (микро-экземпляр EC2). Сайт работает нормально, очень быстро. Таким образом, наш небольшой трафик, похоже, совсем не замедляет работу сервера.
Тем не мение, MySQL очень часто случайно выходит из строя (по крайней мере, раз в неделю), и я не могу понять почему. Вместо этого Apache продолжает работать нормально. Мне нужно войти в систему через SSH и перезапустить его, тогда все работает нормально:
$ sudo service mysql status
mysql stop/waiting
$ sudo service mysql start
mysql start/running, process 25384
Я установил Cacti для мониторинга производительности, и каждый раз, когда MySQL выходит из строя, у меня есть высокий одиночный пик средней нагрузки (до 10, когда обычно меньше 1). Это странно, потому что этого не происходит во время cronjobs или около того.
Я также попытался проверить журналы MySQL: журнал медленных запросов (я уверен, что он включен), /var/log/mysql.log
и /var/log/mysql.err
все пустые. Я подумал, что, возможно, система его автоматически отключила из-за нехватки доступной памяти; это возможно?
Теперь я пытаюсь настроить более крупный экземпляр EC2, но я только что нашел что-то, что выглядит критичным (но я не могу понять) в /var/log/syslog
. Я вставил соответствующую часть Вот (MySQL отключился в 11:47).
Да, похоже, в вашем ящике закончилась свободная оперативная память, и ядро убило его, чтобы защитить стабильность системы. Попробуйте экземпляр с большим количеством баранов!
Да, убийца oom убил ваш mysqld. Для этого ваш сервер плохо настроен или происходит утечка памяти. Глядя на числа, я подозреваю, что вы просто разрешили слишком много памяти для mysql / разрешаете слишком много соединений apache для того количества оперативной памяти, которое у вас есть.
Вам необходимо настроить использование памяти запущенными процессами и ограничить количество одновременных подключений к apache и mysql - или получить больше памяти.