"Про память: OOM Killer (http://catap.ru/blog/2009/05/03/about-memory-oom-killer/)" - в заметке подробно рассказано об алгоритме работы OOM Killer, выбирающем процесс, который следует завершить при нехватке памяти в системе.URL: http://catap.ru/blog/2009/05/03/about-memory-oom-killer/
Новость: http://www.opennet.dev/opennews/art.shtml?num=21580
Отличная система способная убить центральные процессы бд оракл =(
>Отличная система способная убить центральные процессы бд оракл =(добавь их в исключения, чтобы они дохли в последнюю очередь, можешь ещё watchdog написать
>Отличная система способная убить центральные процессы бд оракл =(памяти докупи
>Отличная система способная убить центральные процессы бд оракл =(Предлагаете чтобы вообще ВСЕ подохло?Или что системе предлагается делать если с памятью душняк?Я сначала тоже не прикололся работой OOM, но, черт побери попробуйте предложить более хорошую обработку ситуации?Винды например на это просто кладут болт, ограничившись нытьем в трее.В результате порой придется просто давить ресет.Это лучше?
>Отличная система способная убить центральные процессы бд оракл =(Если работает Oracle, то админ не дундук, и настроил в нём память как надо, чтобы не вылезала за ограничения.
А запрет спекулятивного выделения необеспеченной памяти:
vm.overcommit_memory = 2
приводит к тому что вероятность запуска OOM Killer практически нулевая (только если через ядро память утекает).
Ну как бы приложения вообще надо писать исходя из того, что возможности железа не беспредельны… помнится, под ДОСом мы как-то мирились с тем, что при аллокации можем получить NULL.
Потому что память кончилась от слова «совсем», и что-то надо выгружать, от чего-то отказываться.
И мне эта похоронная оргия кажется набором абсурдных костылей, призванных разрулить неразрулимую ситуацию, вызванную тем, что программисты приучились считать память бесконечной.
Тут не вопрос, кого должен грохнуть оом-киллер, а вопрос, какого фига архитектура и системы, и БД такова, что возникает такая потребность.
Грамотно написанное приложение может по обстоятельствам как укэшироваться до полного оргазма, чтобы мгновенно выполнять любые хотелки, так и урезать осетра до работы чуть ли не прямо с диска/на диск. Но для этого его надо снабжать правдивой инфой о том, сколько оно может получить физической памяти, сколько виртуальной, какие где скорости и т. д. Чтобы можно было принимать взвешенное решение, какой из вариантов использовать.
И не надо рассказывать, как это прям вот безумно сложно. Закон 20/80 там прекрасно работает, 20% усилий сводят проблемы к какому-то исчезающе малой доле, с которой 80% пользователей даже в припадке безалаберности не столкнутся.