Убийца нехватки памяти Ubuntu нанесла серьезный ущерб моему серверу, незаметно убивая мои приложения, sendmail, apache и другие.
Мне удалось узнать, что такое OOM Killer, и о его правилах «плохих». Хотя моя машина мала, мои приложения еще меньше, и обычно используется только половина моей физической памяти, не говоря уже о пространстве подкачки, поэтому я был удивлен. Я пытаюсь выяснить виновника, но не знаю, как читать логи OOM-Killer.
Может ли кто-нибудь указать мне на учебник о том, как читать данные в журналах (какие ve, free и gen?) или помочь мне разобрать эти логи?
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 1, exc 2326 0 goal 2326 0...
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 1
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 1, exc 2326 0 red 61795 745
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 2, exc 122 0 goal 383 0...
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 1
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 2, exc 383 0 red 61795 745
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 2
Apr 20 20:03:27 EL135 kernel: OOM killed process watchdog (pid=14490, ve=13516) exited, free=43104 gen=24501.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=4457, ve=13516) exited, free=43104 gen=24502.
Apr 20 20:03:27 EL135 kernel: OOM killed process ntpd (pid=10816, ve=13516) exited, free=43104 gen=24503.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=27401, ve=13516) exited, free=43104 gen=24504.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=29009, ve=13516) exited, free=43104 gen=24505.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=10557, ve=13516) exited, free=49552 gen=24506.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=24983, ve=13516) exited, free=53117 gen=24507.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=29129, ve=13516) exited, free=68493 gen=24508.
Apr 20 20:03:27 EL135 kernel: OOM killed process sendmail-mta (pid=941, ve=13516) exited, free=68803 gen=24509.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=12418, ve=13516) exited, free=69330 gen=24510.
Apr 20 20:03:27 EL135 kernel: OOM killed process python (pid=22953, ve=13516) exited, free=72275 gen=24511.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=6624, ve=13516) exited, free=76398 gen=24512.
Apr 20 20:03:27 EL135 kernel: OOM killed process python (pid=23317, ve=13516) exited, free=94285 gen=24513.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=29030, ve=13516) exited, free=95339 gen=24514.
Apr 20 20:03:28 EL135 kernel: OOM killed process apache2 (pid=20583, ve=13516) exited, free=101663 gen=24515.
Apr 20 20:03:28 EL135 kernel: OOM killed process logger (pid=12894, ve=13516) exited, free=101694 gen=24516.
Apr 20 20:03:28 EL135 kernel: OOM killed process bash (pid=21119, ve=13516) exited, free=101849 gen=24517.
Apr 20 20:03:28 EL135 kernel: OOM killed process atd (pid=991, ve=13516) exited, free=101880 gen=24518.
Apr 20 20:03:28 EL135 kernel: OOM killed process apache2 (pid=14649, ve=13516) exited, free=102748 gen=24519.
Apr 20 20:03:28 EL135 kernel: OOM killed process grep (pid=21375, ve=13516) exited, free=132167 gen=24520.
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 4, exc 4215 0 goal 4826 0...
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): task ede29370, thg df98b880, sig 1
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 4, exc 4826 0 red 189481 331
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): task ede29370, thg df98b880, sig 2
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 5, exc 3564 0 goal 3564 0...
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): task c6c90110, thg cdb1a100, sig 1
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 5, exc 3564 0 red 189481 331
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): task c6c90110, thg cdb1a100, sig 2
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 6, exc 8071 0 goal 8071 0...
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): task d7294050, thg c03f42c0, sig 1
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 6, exc 8071 0 red 189481 331
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): task d7294050, thg c03f42c0, sig 2
Watchdog - это задача сторожевого пса, которая не выполнялась; ничего в журналах, чтобы предположить, что он что-то делал в течение нескольких дней. Его задача - перезапустить одно из приложений, если оно умирает, что немного иронично, что оно убивается первым.
Tail отслеживал несколько файлов журналов. Вряд ли будет безумно расходовать память.
Веб-сервер apache обслуживает страницы только для маленькая старушка, которая пользуется им только по воскресеньям в церковь пара разработчиков, которые спали в постели и не заходили на сайт в течение нескольких недель. Единственный трафик, который он мог иметь, - это от сканеров портов; весь контент защищен паролем и не связан ни с чем, так что никакие пауки не интересуются.
Python запускает два отдельных пользовательских приложения. В журналах нет ничего, что указывало бы на то, что они не жужжали как обычно. Одна из них была относительно недавней реализацией, что вызывает подозрение №1. Он не имеет каких-либо значимых структур данных и обычно использует только около 8% от общего физического объема RAW. С тех пор он не вел себя плохо.
Grep - это подозреваемый номер 2, и я хочу быть виновным, потому что это была разовая команда. Команда (которая передавала вывод grep -r другому grep) была запущена как минимум 30 минут назад, и тот факт, что она все еще выполнялась, вызывает подозрение. Однако я бы не подумал, что grep когда-либо будет использовать значительный объем памяти. Убийце OOM потребовалось время, чтобы добраться до него, что говорит о том, что он не сходил с ума, но убийца OOM остановился, как только он был убит, предполагая, что это, возможно, был боров памяти, который наконец удовлетворил кровожадность убийцы OOM. .
Я новичок в ServerFault и только что видел этот пост. Кажется, что он снова появился в начале очереди, хотя и старый. Может, уложим этого страшного в постель?
Прежде всего, меня интересует эта тема, поскольку я оптимизирую системы с ограниченным объемом оперативной памяти для безопасного запуска многих пользовательских процессов.
Я считаю, что сообщения об ошибках в этом журнале относятся к контейнерам OpenVZ Linux.
«Ve» - это виртуальная среда, также известная как контейнер в OpenVZ. Каждому контейнеру дается идентификатор, и номер, который вы видите, является этим идентификатором. Подробнее об этом здесь:
Термин «свободная» относится к свободной памяти в байтах на данный момент времени. Вы можете видеть, как объем свободной памяти постепенно увеличивается по мере завершения процессов.
Я немного не уверен в термине «ген». Я считаю, что это относится к поколению. То есть он начинается с 1 и увеличивается на единицу для каждого поколения процесса в контейнере. Итак, для вашей системы, похоже, с момента загрузки было выполнено 24K + процессов. Пожалуйста, поправьте меня, если я ошибаюсь. Это должно быть легко проверить.
Что касается того, почему он убил процессы, это из-за вашей конфигурации убийцы OOM. Он пытается вернуть свободную память к ожидаемому объему (который составляет 128 КБ). У Oracle есть хорошее описание того, как настроить это на то, что вам может понравиться больше:
http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html
Кроме того, если вы хотите увидеть конфигурацию памяти для каждого из ваших контейнеров, проверьте это: