Что может вызвать ядро out_of_memory ошибка?
Для в большой степени многопоточных приложений связанные с потоком метрики полезны и для производительности и для контроля доступности. Тем путем можно контролировать для чрезмерной конкуренции и организации очередей, потенциальных мертвых блокировок, такой вещи.
Может также быть полезно видеть, как метрики потока коррелируют с метриками памяти и ЦП. Например, если бы Вы видите частый полный GCs, было бы полезно знать, что один из потоков работал намного дольше, чем, что Вы обычно ожидали бы. Это может застрять в бесконечном цикле и съедающий "кучу".
Вот некоторые идеи:
http://www.informit.com/guides/content.aspx?g=java&seqNum=250
Проверьте сообщения журнала на признаки ядра уничтожитель из памяти, или OOM killed в выводе dmesg. Это может дать некоторый признак, которого процесса (процессов) была цель уничтожителя OOM. Также смотрите на следующее:
http://lwn.net/Articles/317814/
и
http://linux-mm.org/OOM_Killer
Что делает эта система? Вы исчерпываете подкачку одновременно? Похоже, что rsyslogd является проблемой, на основе Вашей внешней ссылки, детализирующей катастрофический отказ. Это могло быть ситуацией, где периодический перезапуск приложения будет удобен.
2.6.18 очень старое ядро. Я столкнулся с проблемами, где определенные условия могут инициировать бесконечные циклы в ядре, приводящем к чему-либо из памяти исчерпание к пропускной способности средств ввода-вывода, полностью израсходованной, сбросив те же данные к диску в бесконечном цикле (который вызывает скачки загрузки, но нормальное использование ЦП.)
Эти ошибки имеют тенденцию быть исправленными, будучи сообщенным, таким образом, обновление ядра является легкой фиксацией для этого - плюс обновление средств ядра Вы получаете некоторые исправления безопасности, добавленные бесплатно :-)
На другой ноте не забывайте, что Кактусы и т.п. изображают в виде графика в определенном разрешении (collectd, 5 с по умолчанию, кактусы, я верю 30-м по умолчанию), таким образом, у Вас есть период 30-60 секунд, которые не обязательно обнаруживаются на Ваших графиках..., если система будет полностью срываться, то это будет также влиять на демона сбора данных.
Можно найти дополнительную полезную информацию в файлах журнала быть ими общий/var/log/messages или сервис определенный /var/log/apache2/error.log.
Если бы Вы не можете, то я рекомендовал бы пробежаться сервисы (я заметил apache2 в рамках извлечения журнала выше), и проверьте, способны ли они к порождению ситуации с исчерпанием памяти на сервере. (напр.: апачская конфигурация по умолчанию, с mod_prefork и php должна быть способна к останавливанию Вашей системы).