☰

Что может вызвать ошибку ядра out_of_memory?

tag-icon • tag-icon linux kernel memory-usage
Что может вызвать ошибку ядра 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

решение1

Проверьте сообщения журнала на наличие признаков убийцы ядра из-за нехватки памяти или OOM killedв выводе dmesg. Это может дать некоторое представление о том, какой процесс(ы) был целью убийцы OOM. Также взгляните на следующее:

http://lwn.net/Articles/317814/

и

http://linux-mm.org/OOM_Killer

Что делает эта система? Вы одновременно исчерпываете swap? Похоже, проблема в rsyslogd, судя по вашей внешней ссылке, описывающей сбой. Это может быть ситуация, когда периодический перезапуск приложения был бы полезен.

решение2

2.6.18 — очень старое ядро. Я столкнулся с проблемами, когда определенные условия могли вызвать бесконечные циклы в ядре, что приводило к тому, что все, от исчерпания памяти до пропускной способности ввода-вывода, полностью использовалось для сброса одних и тех же данных на диск в бесконечном цикле (что вызывало скачки нагрузки, но при этом нормально использовало ЦП).

Такие ошибки, как правило, исправляются вскоре после сообщения о них, поэтому обновление ядра — это простое решение проблемы. К тому же обновление ядра означает, что вы получите некоторые исправления безопасности бесплатно :-)

решение3

С другой стороны, не забывайте, что Cacti и подобные им программы создают графики с определенным разрешением (collectd по умолчанию составляет 5 с, Cacti, по-моему, 30 с), поэтому у вас есть период в 30-60 секунд, который не обязательно отображается на ваших графиках... если система полностью зависла, это также повлияет на демон сбора данных.

Дополнительную полезную информацию вы можете найти в файлах журналов, будь то общие /var/log/messages или специфичные для службы /var/log/apache2/error.log.

Если вы не можете этого сделать, то я бы рекомендовал вам просмотреть свои службы (я заметил apache2 в приведенном выше отрывке из журнала) и проверить, способны ли они вызвать ситуацию исчерпания памяти на вашем сервере. (например: конфигурация Apache по умолчанию с mod_prefork и php должна быть способна остановить вашу систему).

Связанный контент