Что может вызвать ошибку ядра out_of_memory?
я бегу Debian GNU / Linux 5.0 и у меня периодически возникают ошибки out_of_memory, исходящие от ядра. Сервер перестает отвечать на все запросы, кроме ping, и мне приходится перезагружать сервер.
# uname -a
Linux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64
GNU/Linux
Кажется, это важный бит из / var / log / messages
Dec 28 20:16:25 slarti kernel: Call Trace:
Dec 28 20:16:25 slarti kernel: [<ffffffff802bedff>] out_of_memory+0x8b/0x203
Dec 28 20:16:25 slarti kernel: [<ffffffff8020f825>] __alloc_pages+0x245/0x2ce
Dec 28 20:16:25 slarti kernel: [<ffffffff8021377f>] __do_page_cache_readahead+0xc6/0x1ab
Dec 28 20:16:25 slarti kernel: [<ffffffff80214015>] filemap_nopage+0x14c/0x360
Dec 28 20:16:25 slarti kernel: [<ffffffff80208ebc>] __handle_mm_fault+0x443/0x1337
Dec 28 20:16:25 slarti kernel: [<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
Dec 28 20:16:25 slarti kernel: [<ffffffff8026ef17>] monotonic_clock+0x35/0x7b
Dec 28 20:16:25 slarti kernel: [<ffffffff80262da3>] thread_return+0x6c/0x113
Dec 28 20:16:25 slarti kernel: [<ffffffff8021afef>] remove_vma+0x4c/0x53
Dec 28 20:16:25 slarti kernel: [<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
Dec 28 20:16:25 slarti kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e
Полный фрагмент здесь: http://pastebin.com/a7eWf7VZ
Я подумал, что, возможно, серверу действительно не хватает памяти (у него 1 ГБ физической памяти), но мой график памяти Cacti мне кажется нормальным ...
Друг поправил меня здесь; он отметил, что график на самом деле перевернут, поскольку фиолетовый указывает память свободна (не используется память, как следует из названия).
Но, как ни странно, график нагрузки зашкаливает незадолго до сбоя ядра:
В каких журналах можно найти дополнительную информацию?
Обновить:
Может быть, примечательно - процентное соотношение ЦП и графики сетевого трафика были нормальными во время сбоя. Единственным отклонением от нормы был график средней нагрузки.
Обновление 2:
Думаю, это началось, когда я развернул Passenger / Ruby и использовал top Я вижу, что Ruby использует большую часть памяти и изрядное количество ЦП:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5189 www-data 18 0 255m 124m 3388 S 0 12.1 12:46.59 ruby1.8
14087 www-data 16 0 241m 117m 2328 S 21 11.4 3:41.04 ruby1.8
15883 www-data 16 0 239m 115m 2328 S 0 11.3 1:35.61 ruby1.8
Проверьте сообщения журнала на наличие признаков убийцы нехватки памяти ядра или OOM killed на выходе dmesg. Это может дать некоторое представление о том, какие процессы были целью убийцы OOM. Также обратите внимание на следующее:
http://lwn.net/Articles/317814/
и
http://linux-mm.org/OOM_Killer
Что делает эта система? Вы одновременно изматываете своп? Судя по вашей внешней ссылке, в которой подробно описывается сбой, похоже, что проблема в rsyslogd. Это может быть ситуация, когда удобен периодический перезапуск приложения.
2.6.18 - очень старое ядро. Я столкнулся с проблемами, когда определенные условия могут запускать бесконечные циклы в ядре, в результате чего все, от исчерпания памяти до полной пропускной способности ввода-вывода, сбрасывает одни и те же данные на диск в бесконечном цикле (что вызывает скачки нагрузки, но нормальный процессор использовать.)
Эти ошибки, как правило, исправляются вскоре после сообщения о них, поэтому обновление ядра - простое решение для этого - плюс обновление ядра означает, что вы получите некоторые исправления безопасности, добавленные бесплатно :-)
С другой стороны, не забывайте, что график Cacti и тому подобное при определенном разрешении (collectd по умолчанию 5 секунд, кактусов, я считаю, 30 секунд по умолчанию), поэтому у вас есть период 30-60 секунд, который не обязательно отображается на вашем графики ... если система полностью зависнет, это также повлияет на демон сбора данных.
Вы можете найти дополнительную полезную информацию в своих файлах журнала, будь то общая / var / log / messages или специфическая для службы /var/log/apache2/error.log.
Если вы не можете этого сделать, я бы порекомендовал вам просмотреть свои службы (я заметил apache2 в извлечении вашего журнала выше) и проверить, способны ли они вызвать ситуацию нехватки памяти на вашем сервере. (например: конфигурация apache по умолчанию, с mod_prefork и php должна быть способна остановить вашу систему).