| 1.1, Аноним (-), 12:16, 04/05/2009 [ответить]
| +/– |
Отличная система способная убить центральные процессы бд оракл =(
| | |
| |
| 2.2, аноним (?), 12:23, 04/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Отличная система способная убить центральные процессы бд оракл =(
добавь их в исключения, чтобы они дохли в последнюю очередь, можешь ещё watchdog написать
| | |
| 2.3, Анонима (?), 14:43, 04/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Отличная система способная убить центральные процессы бд оракл =(
памяти докупи
| | |
| 2.4, User294 (??), 15:51, 04/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Отличная система способная убить центральные процессы бд оракл =(
Предлагаете чтобы вообще ВСЕ подохло?Или что системе предлагается делать если с памятью душняк?Я сначала тоже не прикололся работой OOM, но, черт побери попробуйте предложить более хорошую обработку ситуации?Винды например на это просто кладут болт, ограничившись нытьем в трее.В результате порой придется просто давить ресет.Это лучше?
| | |
| 2.5, svn (??), 16:48, 04/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Отличная система способная убить центральные процессы бд оракл =(
Если работает Oracle, то админ не дундук, и настроил в нём память как надо, чтобы не вылезала за ограничения.
А запрет спекулятивного выделения необеспеченной памяти:
vm.overcommit_memory = 2
приводит к тому что вероятность запуска OOM Killer практически нулевая (только если через ядро память утекает).
| | |
|
| 1.6, Аноним (6), 02:39, 19/11/2018 [ответить]
| +/– |
Ну как бы приложения вообще надо писать исходя из того, что возможности железа не беспредельны… помнится, под ДОСом мы как-то мирились с тем, что при аллокации можем получить NULL.
Потому что память кончилась от слова «совсем», и что-то надо выгружать, от чего-то отказываться.
И мне эта похоронная оргия кажется набором абсурдных костылей, призванных разрулить неразрулимую ситуацию, вызванную тем, что программисты приучились считать память бесконечной.
Тут не вопрос, кого должен грохнуть оом-киллер, а вопрос, какого фига архитектура и системы, и БД такова, что возникает такая потребность.
Грамотно написанное приложение может по обстоятельствам как укэшироваться до полного оргазма, чтобы мгновенно выполнять любые хотелки, так и урезать осетра до работы чуть ли не прямо с диска/на диск. Но для этого его надо снабжать правдивой инфой о том, сколько оно может получить физической памяти, сколько виртуальной, какие где скорости и т. д. Чтобы можно было принимать взвешенное решение, какой из вариантов использовать.
И не надо рассказывать, как это прям вот безумно сложно. Закон 20/80 там прекрасно работает, 20% усилий сводят проблемы к какому-то исчезающе малой доле, с которой 80% пользователей даже в припадке безалаберности не столкнутся.
| | |
|
