Чем отследить потребление памяти процессами

Разово посмотри dmesg на сервере, там OOM killer довольно подробно расписывает. Очень сомневаюсь, что каждый раз будут разные программы.

Вот такое:

[9874602.377524] Out of memory in UB 224569: OOM killed process 9980 (apache2) score 0 vm:439996kB, rss:121868kB, swap:3348kB
[9874605.714385] Out of memory in UB 224569: OOM killed process 9926 (apache2) score 0 vm:435200kB, rss:117384kB, swap:3264kB
[9874609.104870] Out of memory in UB 224569: OOM killed process 9927 (apache2) score 0 vm:435208kB, rss:117384kB, swap:3264kB
[9874612.609106] Out of memory in UB 224569: OOM killed process 9928 (apache2) score 0 vm:435968kB, rss:118052kB, swap:3264kB
[9874616.887980] Out of memory in UB 224569: OOM killed process 9933 (apache2) score 0 vm:438056kB, rss:118808kB, swap:2856kB
[9874620.736181] Out of memory in UB 224569: OOM killed process 9940 (apache2) score 0 vm:435208kB, rss:117408kB, swap:3264kB
[9874624.660697] Out of memory in UB 224569: OOM killed process 9943 (apache2) score 0 vm:434944kB, rss:117028kB, swap:3264kB
[9874628.252029] Out of memory in UB 224569: OOM killed process 9944 (apache2) score 0 vm:435200kB, rss:117464kB, swap:3264kB
[9874636.462527] Out of memory in UB 224569: OOM killed process 9951 (apache2) score 0 vm:435976kB, rss:118080kB, swap:3264kB
[9874641.815226] Out of memory in UB 224569: OOM killed process 9958 (apache2) score 0 vm:435712kB, rss:117808kB, swap:3264kB
[9874673.746138] Out of memory in UB 224569: OOM killed process 9982 (apache2) score 0 vm:435216kB, rss:117916kB, swap:3116kB

SAR

А теперь ищи причину, по которой апач выжирает всю память. Может кто запрос левый посылает с payload на много мегабайт или тупо эксплуатация какой уязвимости.

Подскажите пожалуйста, чем можно отследить потребление памяти.

Любой системой мониторинга, хоть прометеем, хоть «htop время от времени».

А теперь ищи причину, по которой апач выжирает всю память

Так OOM Killer убил апач, потому что он самый не нужный. Но не потому, что он потребляет всю память

OOM Killer представляет собой компонент ядра Linux, защитный механизм, призванный решать проблемы с нехваткой физической памяти (OOM — Out of memory). При обнаружении недостатка памяти OOM Killer «убивает» наименее важный по его мнению процесс, посылая ему сигнал KILL (исключения составляют лишь init и ядерные нити (kernel threads)). Сообщение о об этом появляется в журнале /var/log/syslog

Почитай как он считает рейтинг ненужности. Им можно управлять конечно. Настрой лимиты в апаче при которых он будет сам себя прибивать или ограничь его так чтобы он не падал (видимо у тебя 640 килобайт памяти на хосте, да?).

Не потому, что самый ненужный, а из-за соотношения прожорливости/ненужности. Ставь какой-нибудь мониторинг, который может отображать процессы и потребление ими ресурсов на какой-то момент, а потом изучай.

У тебя http-сервер грохается из-за утечек памяти, а ты ведешь себя как тот пёс в горящей комнате.

Или твоей машине не хватает памяти для работы, или там говнокод.

не нашёл у SAR мониторинг процессов. Есть такое?

оперативы 2гб.

Решил переустановить ОС на более свежую. Т.к. сейчас 12.04.

всем спасибо за подсказки, взял на заметку.

atop

есть nmon.
он может записать все в файл и красиво отобразить.

Решил переустановить ОС на более свежую. Т.к. сейчас 12.04.

А без переустановки эта ОС не обновляется?

Посмотреть можно collectd, там есть плагин соответствующий, в настройках которого можно интересующие процессы перечислить.

А смысл их перечислять? Нужно боротся с причиной распухания апача, для этого нужно смотреть логи или память увеличить.

Нужно боротся с причиной распухания апача

Ещё никто не показал, что распухает именно он, а не, к примеру, mysql какой-нибудь. Или, вовсе, slab...

У mysql скор обычно подкручен.

Ну кто видно в логах системы, оом киллер мочит, в коллекте можно только графики смотреть, и примерно время вычислять когда рости начал и смотреть логи именно в этом время)

Ну кто видно в логах системы, оом киллер мочит

Даже тут уже писали, что oom killer может мочить не того. И так, на самом деле, бывает часто.

в коллекте можно только графики смотреть

Эти графики могут о многом рассказать. Причём данные могут лежать на общем коллекторе статистики.

atop заинтересовал, спасибо. Поставил на запись впс.

После переустановки ВПС проблема осталась. Буду дальше искать причину. Кто сжирает всю память точно неизвестно пока. Предположительно apache.

проблема локализовалась. Apache сжирал всю память, т.к. работал на prefork + itk, который двоил процесс на каждый запрос.

Решение: Apache (mpm_event) + php-fpm, под каждый сайт свой pool в php-fpm.