* [Comm] alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
@ 2006-10-25 16:32 Сергей Афанасьевич
0 siblings, 1 reply; 2+ messages in thread
From: Сергей Афанасьевич @ 2006-10-25 16:32 UTC (permalink / raw)
To: community
Здравствуйте!
Буду искренне признателен, если сможете помочь с ниже изложенной
проблемой:
После штатной работы 4.5 месяцев сервера под управлением master 2.2
(штатное ядро - 2.4.20) произошла выгрузка активных процессов ос и система встала в "частично
рабочее состояние". Т.е. работа по сети Ethernet происходит без
проблем, но попытки запустить какие-либо пользовательские программы -
невозможно (не могут локально присоединиться к нужному сокету).
После перезагрузки - никаких проблем нет - программы
пользователей запустились штатно и все работает.
В логах остались вот такие чудные записи:
Sep 22 16:44:13 vkufs_22 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Sep 22 16:44:13 vkufs_22 kernel: VM: killing process sh
Sep 22 16:44:16 vkufs_22 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Sep 22 16:46:40 vkufs_22 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Sep 22 16:46:40 vkufs_22 kernel: VM: killing process GateCom
Sep 22 16:48:07 vkufs_22 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Sep 22 16:48:26 vkufs_22 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
и т.д. более 20 процессов были убиты.
Прошерстил поисковики - судя по сообщениям - это ошибка свидетельсвует
о том, что какой-либо процесс желает получить определенный объем
памяти, НО по каким-то причинам памяти больше нет (стоит сказать, что
память сервера - 1 гиг, swap - тоже 1 гиг). И как следствие
данный факт порождает убийство уже созданных процессов.
Но вопрос в другом. Почему памяти не стало? Получается что какой-то
процесс все эти 4 месяца эту память потихоньку съедал и не освобождал.
Если бы памяти было бы больше, то данный зловредный процесс выбрал ее
всю не за 4 месяца а за больший срок.
Написал примитивную утилиту где функция malloc в цикле забирает
память. После того как колличество забранный памяти достигло
критической величины произошло убийство этого процесса и некоторых
других (в зависимости от имени какого пользователя происходил запуск
программы).
Если я прав - то подскажите пожалуйста как поступать дальше (а если я
не прав - намекните пожалуйста где):
1. Моя цель определить что за процесс съел всю память. Каким образом
это сделать? Ничего умнее как по cron запускать "ps -aux" и смотреть
результаты через недельку - месяц?
2. Прочитал про ulimit и про /etc/security/. Как вариант можно
выставить лимиты на память и тот процесс, который первый их нарушит -
тот и виновник?
Извините что много так и немного сумбурно...
Заранее благодарю за любую помощь...
--
Искренне с уважением,
Сергей mailto:demiurg888@mail.ru
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-10-25 16:43 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-25 16:32 [Comm] alloc_pages: 0-order allocation failed (gfp=0x1d2/0) Сергей Афанасьевич
2006-10-25 16:43 ` Michael Shigorin
ALT Linux Community general discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 community community/ http://lore.altlinux.org/community \
mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com
public-inbox-index community
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.community
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git