Судебно-медицинский анализ OOM-Killer

Ubuntu's Out-Of-Memory Killer навлек хаос на моем сервере, спокойно убивая мои приложения, 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 .

7 голосов | спросил Oddthinking 22 AMpThu, 22 Apr 2010 06:45:24 +040045Thursday 2010, 06:45:24

1 ответ


1

Я новичок в ServerFault и просто видел этот пост. Кажется, он снова появился возле передней части очереди, хотя и старый. Давайте поставим этот страшный спать, может быть?

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

Я считаю, что сообщения об ошибках в этом журнале относятся к контейнерам OpenVZ Linux.

«ve» - виртуальная среда, также известная как контейнер в OpenVZ. Каждому контейнеру присваивается идентификатор, а номер, который вы видите, - это идентификатор. Подробнее об этом здесь:

https://openvz.org/Container

Термин «свободный» относится к свободной памяти в байтах в этот момент времени. Вы можете видеть, что свободная память постепенно увеличивается, когда процессы уничтожаются.

Термин «ген», о котором я немного не уверен. Я считаю, что это относится к поколению. То есть, он начинается с 1 и увеличивается на единицу для каждого поколения процесса в контейнере. Итак, для вашей системы, похоже, были запущены процессы 24K + с момента загрузки. Пожалуйста, поправьте меня, если я ошибаюсь. Это должно быть легко проверить.

Что касается того, почему он убил процессы, это из-за вашей конфигурации убийцы OOM. Он пытается вернуть бесплатную память к ожидаемой сумме (которая составляет 128 Кб). У Oracle есть хорошая рекомендация о том, как настроить это, чтобы вам было лучше:

http://www.oracle .com /technetwork /статьи /сервера-хранения-DEV /ОЫЙ-убийцы-1911807.html

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

https://openvz.org/Setting_UBC_parameters

ответил Zahnon 24 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 24 Sep 2013 10:26:50 +0400 2013, 10:26:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132