как узнать причину линукскапца?

обновления никакие не делали?

за 12 часов до этого делал обновления ядра (aptitude) но ребут после этого не сделал

Ну, падения апача на php это нормально :). А узнать можно только по логам или провести тесты оборудования.

> Случилось страшное, вчера сервер вошел в штупор, судя по всему были ошибки out of memory - сервисы работали но очень слабо отвечали на запросы (ssh вылетал на разных стадиях, apache отвечал 503 на php, статические запросы иногда отдавались.

Симптомы похожи на thrashing и overcommit. Надо искать в логах сообщения об ошибках выделения памяти ядром.

Ну и отключить overcommit, настроить лимиты.

libc может быть неадекватно? попробуй полное обновление сделать.

твою память кто-то схавал. грешу на апач :)

Если память кто-то схавал - то IO должно бв расти за счет свопинга. При чём тут сегфолты?

Сбт, Дек 20 2008 17:20:28 +0300

[ОБНОВЛЕНИЕ] initramfs-tools 0.92j -> 0.92m
[ОБНОВЛЕНИЕ] linux-image-2.6.26-1-amd64 2.6.26-11 -> 2.6.26-12
[ОБНОВЛЕНИЕ] linux-libc-dev 2.6.26-11 -> 2.6.26-12


вот это последнее обновление было перед этим (я ошибся, не за 12 часов, а за 3 дня до подения)




кстати сегодня обратил внимание что вчера было обновление

[ОБНОВЛЕНИЕ] grub 0.97-47 -> 0.97-47lenny1
[ОБНОВЛЕНИЕ] initramfs-tools 0.92m -> 0.92n
[ОБНОВЛЕНИЕ] libgl1-mesa-glx 7.0.3-6 -> 7.0.3-7
[ОБНОВЛЕНИЕ] libglu1-mesa 7.0.3-6 -> 7.0.3-7
[ОБНОВЛЕНИЕ] libncurses5 5.6+20080830-2 -> 5.7+20081213-1
[ОБНОВЛЕНИЕ] libncursesw5 5.6+20080830-2 -> 5.7+20081213-1
[ОБНОВЛЕНИЕ] ncurses-base 5.6+20080830-2 -> 5.7+20081213-1
[ОБНОВЛЕНИЕ] ncurses-bin 5.6+20080830-2 -> 5.7+20081213-1
[ОБНОВЛЕНИЕ] openbsd-inetd 0.20080125-1 -> 0.20080125-2
[ОБНОВЛЕНИЕ] oss-compat 0.0.4+nmu1 -> 0.0.4+nmu2
[ОБНОВЛЕНИЕ] reportbug 3.47 -> 3.48
[ОБНОВЛЕНИЕ] smarty 2.6.19-1 -> 2.6.20-1.1



initramfs-tools  --- видно что второй раз обновился (за 1 неделю), может в нем дело


initramfs-tools (0.92n) unstable; urgency=high 
   [ Eugene Paskevich ]
   * hook-functions: Fix MODULES=dep for lvm LABEL fstab notation.
     (closes: http://bugs.debian.org/508906 )
 
   [ maximilian attems ]
   * all_generic_ide: Also parse boolean bootoption. (closes: http://bugs.debian.org/507805 )
   * initramfs-tools.8: Document where to look up NFSOPTS. (closes: http://bugs.debian.org/502927 )
   * update-initramfs.8: List -d and mark the non-optional as such.
 
   [ S. Sakar ]
   * hook-functions: MODULES=dep fix encrypted loop device.
     (closes: http://bugs.debian.org/499666 )

> Симптомы похожи на thrashing и overcommit. Надо искать в логах сообщения об ошибках выделения памяти ядром.

попробовал в /var/log

grep thrashing *

grep overcommit *

ничего не найдено

что ещё можно поискать? или какие файлы лучше смотреть?

> Если память кто-то схавал - то IO должно бв расти за счет свопинга. При чём тут сегфолты?

Сегфолты при том, что malloc начинает _массово_ возвращать NULL, и в конце концов NULL возвращается из malloc туда, где результат не проверяется :)

> grep thrashing *

> grep overcommit *

> ничего не найдено

ыыыы... ты читай внималтельнее :) а в логах попробуй поискать order и failure.

а еще, это неправильный invocation для grep в твоем случае. надо так:
grep -R thrashing /var/log

это и zgrep я пробовал, по всем предложеным запросам вроде ничего

вобщем проблема случилась, и никаких следов не найти

бывали похожие ситуации
также в логах NULL

нашел два решение
1. резет
2. ждать примерно сутки, сам отвисал...

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