Я запускаю стек LAMP на сервере Ubuntu. Дважды за сегодня он останавливался и требовал полной перезагрузки. До этого он был стабильным в течение многих месяцев. С момента последнего изменения конфигурации прошло около двух недель, и даже это было незначительным.
Порывшись вокруг, я нашел это в системном журнале за несколько минут до того, как отказавшее электронное письмо cron предупредило меня о сбое:
Sep 22 18:14:33 rfb CRON[4912]: (tom) CMD (/usr/share/rfb-scripts/rrdtool-updater.sh)
Sep 22 18:15:40 rfb CRON[4923]: (tom) CMD (/usr/share/rfb-scripts/rrdtool-updater.sh)
Sep 22 18:16:36 rfb CRON[4952]: (tom) CMD (/usr/share/rfb-scripts/rrdtool-updater.sh)
Sep 22 18:16:48 rfb kernel: [16220.076166] apache2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Sep 22 18:16:48 rfb kernel: [16220.076173] Pid: 4908, comm: apache2 Not tainted 2.6.32.9-rscloud #6
Sep 22 18:16:48 rfb kernel: [16220.076175] Call Trace:
Sep 22 18:16:48 rfb kernel: [16220.076186] [<ffffffff8105ca35>] ? T.383+0x78/0x239
Sep 22 18:16:48 rfb kernel: [16220.076191] [<ffffffff8103dea6>] ? timekeeping_get_ns+0xe/0x2e
Sep 22 18:16:48 rfb kernel: [16220.076195] [<ffffffff8105cd2a>] ? __out_of_memory+0x134/0x14b
Sep 22 18:16:48 rfb kernel: [16220.076198] [<ffffffff8105cdab>] ? out_of_memory+0x6a/0x94
Sep 22 18:16:48 rfb kernel: [16220.076202] [<ffffffff8105f96f>] ? __alloc_pages_nodemask+0x47f/0x56b
Sep 22 18:16:48 rfb kernel: [16220.076206] [<ffffffff81061112>] ? __do_page_cache_readahead+0x9e/0x1a1
Sep 22 18:16:48 rfb kernel: [16220.076212] [<ffffffff810384bd>] ? wake_bit_function+0x0/0x2e
Sep 22 18:16:48 rfb kernel: [16220.076214] [<ffffffff81061231>] ? ra_submit+0x1c/0x20
Sep 22 18:16:48 rfb kernel: [16220.076217] [<ffffffff8105af33>] ? filemap_fault+0x17e/0x2ff
Sep 22 18:16:48 rfb kernel: [16220.076221] [<ffffffff8106ea79>] ? __do_fault+0x54/0x335
Sep 22 18:16:48 rfb kernel: [16220.076224] [<ffffffff8106f008>] ? handle_mm_fault+0x2ae/0x636
Sep 22 18:16:48 rfb kernel: [16220.076228] [<ffffffff81014211>] ? do_page_fault+0x299/0x2ae
Sep 22 18:16:48 rfb kernel: [16220.076232] [<ffffffff81226e18>] ? page_fault+0x28/0x30
Sep 22 18:16:48 rfb kernel: [16220.076235] Mem-Info:
Sep 22 18:16:48 rfb kernel: [16220.076237] DMA per-cpu:
Sep 22 18:16:48 rfb kernel: [16220.076238] CPU 0: hi: 0, btch: 1 usd: 0
Sep 22 18:16:48 rfb kernel: [16220.076240] CPU 1: hi: 0, btch: 1 usd: 0
Sep 22 18:16:48 rfb kernel: [16220.076242] CPU 2: hi: 0, btch: 1 usd: 0
Sep 22 18:16:48 rfb kernel: [16220.076244] CPU 3: hi: 0, btch: 1 usd: 0
Sep 22 18:16:48 rfb kernel: [16220.076245] DMA32 per-cpu:
Sep 22 18:16:48 rfb kernel: [16220.076247] CPU 0: hi: 155, btch: 38 usd: 49
Sep 22 18:16:48 rfb kernel: [16220.076249] CPU 1: hi: 155, btch: 38 usd: 37
Sep 22 18:16:48 rfb kernel: [16220.076251] CPU 2: hi: 155, btch: 38 usd: 22
Sep 22 18:16:48 rfb kernel: [16220.076252] CPU 3: hi: 155, btch: 38 usd: 45
Первые 3 строки включены для демонстрации нормальной работы. Журнал продолжается, но я избавлю вас от этого волнения. (Если ты действительно хочу это увидеть, попробуй этот пастебин.)
Тогда мой вопрос: могу ли я использовать этот журнал для диагностики моей проблемы? Если да, то как? И бонусный балл для всех, кто может сказать мне, что мне нужно сделать, чтобы это не повторилось.
что-то пытается выделить больше памяти, чем у вас есть. очевидно, что вы можете добавить больше свопа, но это убьет производительность вашего бокса. возможно, добавить небольшой скрипт, который будет запускаться периодически [даже чаще, чем раз в минуту]
date >> /some/file
ps faux >> /some/file
и зарегистрируйте вывод - вы можете заметить процесс, выделяющий все больше и больше памяти.
Согласен, это был apache2, который был неудачным процессом, но раньше он был для меня виноватым. Обычно, особенно с perl, php или mod_python будут продолжать выделять оперативную память для некоторых веб-приложений. Поскольку разные клиенты задействуют разные процессы apache, они будут продолжать увеличивать использование памяти.
Если ваш трафик достаточно высок, чтобы поддерживать процессы apache в рабочем состоянии, вы можете получить 256 запущенных процессов apache. Но это не должно быть где-то рядом с этим пределом, у меня был oom-killer, который выдал мне плохой день с 30 процессами apache, использующими 250-300 МБ или RAM каждый.
Увеличение свопа даст вам немного времени, чтобы сесть в коробку и посмотреть, что происходит, но вы должны быть предупреждены, чтобы вы могли видеть, какой процесс поглощает память, проверить, действительно ли это apache.
Используйте бесплатно в cron job или cacti и snmp с порогами. С бесплатным вам нужно будет наблюдать за буферами и свободной оперативной памятью, суммировать их и предупреждать о каком-то нижнем пороге.
Еще одна вещь, если это apache, может заключаться в том, чтобы принести ваши MaxClients, у него может быть высокий номер по умолчанию. Или доведите MaxRequestsPerChild до достаточно низкого числа, чтобы время от времени прекращать процессы. Это всего лишь пластырь, но он может помочь вам продержаться достаточно долго, чтобы разобраться в проблеме.
Просто мой удар в воздухе, Скотт М.
Совет от @ user36376 хорош. Похоже, у вас утечка памяти. Пока вы его не отследите, настройка apache для уничтожения процессов после обработки некоторого количества запросов, скорее всего, даст вам некоторое время для выявления утечки. Поскольку это новое явление, следует подозревать недавнее изменение. Вы также можете рассмотреть возможность использования ulimit, чтобы минимизировать размер дочерних элементов apache. Утечка памяти, вероятно, может быть заменена с незначительным воздействием, поэтому может помочь увеличение объема подкачки.
Рассмотрите возможность использования top для контроля размера виртуального изображения. Вы можете изменить порядок, чтобы виртуальный размер был первым полем сортировки. Самые крупные программы переместятся наверх.