Присоединяюсь.
Господа пользуйтесь ulimit-ом .
Пропишите все юзверям через pam-limit (/etc/security/limits.conf).
Ну если лень, то подождите пока пару раз свалиться система.
Несколько раз из-за глюков в прикладном ПО машина уходила в заморозку.
Причина: глюки в mc и php+xml. Проставив ulimit-ы ( по памяти и CPU) в pam и в стартовые скрипты apache, я получил большое удовольствие от уничтожения всего, что мешает спокойно пить чай.
Это не сложно, и если у Вас возникают проблемы, сделайте это. Будет oom-killer или не будет - дело второе, за Вас НИКТО не решит, кто сколько ресурсов может сьесть.
Удачи.

> Пропишите все юзверям через pam-limit (/etc/security/limits.conf).

Перевожу для юзверей slackware (самого правильного дистрибутива):
Создается файл /etc/profile.d/limits.sh c примерно таким содержимым:

#!/bin/sh

#########################################
# Default system limits
maxmem=400000 #(400M)
maxproc=256

# virtual memory
ulimit -SHv $maxmem

# maximum size of a process's data segment
ulimit -SHd $maxmem

# maximum size a process may lock into memory
ulimit -SHl $maxmem

# maximum resident set size
ulimit -SHm $maxmem

# maximum stack size
#ulimit -SHs $maxmem
ulimit -SHs 64000

# maximum number of open file descriptors
# (don't enable it; doesn't work for normal users)
#ulimit -SHn 1024

# maximum number of user processes
ulimit -SHu $maxproc

# no core files
ulimit -SHc 0

# cpu time (60 min) for local privileged users
if [ `id -g` -eq 100 ] ; then
ulimit -SHt 3600
fi

# cpu time (10 min) for other users
# max file size ctreated by the shell (100M) for other users
if [ `id -g` -gt 100 ] ; then
ulimit -SHt 600
fi

# max file size ctreated by the shell (1GiG)
#ulimit -SHf 1024000

#########################################

Люди лучше объясните какие аргументы Линуса по поводу этого oom killer'a ? Что-то как-то после всего этого треда стремно ставить это ядро... Хотя так давно его ждали...

man ulimit

люди, а подскажите, что и где почитать про настройку лимитов? у меня под рукой два сервера: на одном крутится squid, на другом - qmail + vpopmail. проблем никаких нету, пользователей ни на одном из них нету, лимитов никаких не настраивал, но хотелось бы для общего развития почитать и на будущее знать

fvwm2

нефиг про него читать - костыли они и есть костыли, и чем скорее их уберут, тем лучше (на старом добром 2.2.x этой фигни не было). Если malloc без настроенных ulimitoв не возвращает null, если не может выделить память - это полный %pi%здец. И почему администратор должен сообщать компьютеру, сколько у него виртуальной памяти - он что сам не может сосчитать ram+swap?

man malloc
...
Linux follows an optimistic memory allocation strategy.
This means that when malloc() returns non-NULL there is no
guarantee that the memory really is available. In case it
turns out that the system is out of memory, one or more
processes will be killed by the infamous OOM killer.
...

to anonymous (*) (01.12.2003 11:58:48) /etc/security/limits.conf

Объясните плиз если malloc в glibc все равно не выделяет память если ее не хватает тогда зачем ВООБЩЕ нужен этот механизм ?!

поставил 2.4.23; работает также как и 2.4.22, за исключением того, что ядро перестало свопить. раньше редкоиспользуемые демоны типа atd уходили в своп, а сейчас такого не скажешь.

fvwm2

Так разработчик же программы должен знать достаточно ему памяти, чтобы разместить в ней какой нибудь объект или нет. Тут примерчик же показывали. Хочется например выделить памяти под массив 10 Мб, а свободной памяти только на 1Мб. Если malloc нормально работат - разработчик делает проверку на null и программа сообщает юзеру - извините, приходите поппозже, когда память освободится. А так получается, что программа сообщает, что памяти хватат на 10 Мб, начинает распихивать данные, занимает оставшийся 1Мб, и тут-то oom-killer ее и прибивает - и привет - нужно было данные сэйвить. C ulimit такое не происходит, но костыли в том - что вместо реальных (к примеру) 500Мб памяти, которые имеются на компе администратор позволяет юзеру занять 100 Мб (опять же к примеру). А у того данных на 300Мб - и что каждый раз бежать к админу просить ulimit поднимать?
Так что когда наконец-то прибьют infamous oom-killer - все я думаю только свободно вздохнут - проблемы с нехваткой памяти будут решаться покупкой новой памяти, а не шаманством c ulimit-ами

Почему такая надпись > hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest } обозначает, что диск начинает сыпаться?

>>>Враньё. Все обстоит как раз наоборот. Ветка Алана - вечный конвейер для ...

Не неси пурги.

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

ЗЫ (какому-то из анонов) - 2.4.22-ac4 has been out...

Кстати, о птичках ...

Всем, вероятно, известен казус с инициализией I2O ide raid контроллеров.

Стандартное ядро (до 2.4.21) пыталось вначале проинициализировать чипы рэйд контроллеров и не получив прерывания от них (а они завязаны на i960) впадало в панику. В алановских пачах эта проблема решалась, дай бог памяти, с версии 2.4.9. А вот в стандартное ядро пач не включали с подачи выше упомянутого Андрэшки вкупе с Марцелишкой. В 2.4.21 таки сподобились. Самый прикол в том, что установив на нормально работающее 2.4.22 аа пачи ... мы получим ... ну, угадайте с трех раз... правильно! Kernel panic.

Это, к слову, о качестве ас и аа ...

PS: С этими двумя дружками мы еще хлебнем.

2 anonymous (*) (30.11.2003 23:07:54)
Большое спасибо за разъяснения по поводу overcommit.

2 geekkoo (*) (01.12.2003 12:24:47)
> Linux follows an optimistic memory allocation strategy.
В гробу я видал такой оптимизм. Это называется "баг в дизайне подсистемы VM".
У linux, оказывается, такое же неопределенное поведение, как у Windows.
Такой же отстой непредсказуемый.

2 geekkoo (*) (01.12.2003 17:18:14)
> Так что когда наконец-то прибьют infamous oom-killer - все я думаю только
> свободно вздохнут - проблемы с нехваткой памяти будут решаться покупкой
> новой памяти, а не шаманством c ulimit-ами.
Вместо oom-killer, как я понял, теперь будет просто SIGKILL процессу,
попросившему памяти. Это что, хорошо? Это, IMHO, такая же жопа, только еще хуже.
Проблемы с нехваткой памяти -- да, будут решаться покупкой новой памяти. Но
когда? После того, как начнут умирать вполне корректно работающие
пользовательские программы. А если программа умирает не по своей воле, то
вместе с ней убивается и труд пользователя. Это называется "издевательство
операционной системы над человеком". (А ulimitы действительно не вариант.)

Люди, подскажите, пожалуйста, если знаете: есть ли во FreeBSD подобные грабли
с непрозрачностью и неопределенным поведением в штатных ситуациях?
И как у нее с новым железом -- как у linux или совсем плохо?

> Почему такая надпись > hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }

Потому что после нее диск сыпится... ;) Поищи в гугле. Сразу поймешь.
Это верный индикатоор.

> сравни их с аа веткой. Мусора привносимого в чистое ядро там гораздо меньше

Честно говоря не понял. Где меньше мусора? В -aa или в основной ветке?

> установив на нормально работающее 2.4.22 аа пачи ... мы получим ...
[...]
> Это, к слову, о качестве ас и аа ..

Это, к слову, только о качестве твоего мышления ;)))
"Один неработающий драйвер = дерьмовое ядро"
А ответь, зачем ты пытался накладывать -aa патчи на 2.4.22?
Ты специально искал геморрой на свою задницу, или все-таки ты знал,
что -aa работает значительно лучше? ;)))

> 2.4.23; работает также как и 2.4.22, за исключением того, что ядро перестало свопить

А вот это и проявляется работа -aa патчей ;)

А вот для чего имеет смысл обновить ядро:
http://freshmeat.net/articles/view/1039/

>>>Это, к слову, только о качестве твоего мышления ...

Гм, очевидно юноша не совсем точно представляет себе суть проблемы. Разговор идет о порядке инициализации драйверов (и многими любопытными ньюансами связанными с этим) - нерабочими будут любые дэвайсы с каскадной схемой подключения видимых субконтроллеров.

Не знаю кому как - а я предпочитаю работающее ядро абсолютно не пашущему "крутому" ядру. Ежели кто хочет обратное - флаг в ... э-э-э-э руки.

Поискал... (http://www.google.com/search?q=hdc:+irq+timeout:+status=0x58+%7B+DriveReady+See kComplete+DataRequest+%7D&ie=UTF-8&oe=UTF-8) - дают разные советы по оптимизации и проч., но никто не кричит "спасай данные!"... Или я не туда смотрел?

> нерабочими будут любые дэвайсы с каскадной схемой подключения видимых субконтроллеров.

А если еще точнее? В итоге окажется, что одна китайская поделка не
заработала. ;)) Не поверю я в твои сказки. Если девайс был серьезным,
Андреа не мог допустить того, чтобы он не работал. Андреа сам является
сисадмином и поддерживает по контракту очень крупные mission critical
сервера. На этих серверах стоят его ядра. И он постоянно иъх наблюдает.

>>>А если еще точнее ...

Я вижу, ни одного осмысленного аргумента в пользу аа добиться не возможно( кроме Андрэа - это пипец какой-то ) - да и не мудрено - их попросту нету , посему дебаты прекращаю, вижу - бестолку 8)

ЗЫ: ВЕРА - вещь хорошая, если не осталось ничего другого больше.

Самый первый аргумент в пользу -аа хотя бы тот, что даже такой
неграмотный человек, как ты - и тот пытался ставить -aa патч на
такое, казалось бы, хорошее и вылизанное ядро, как 2.4.22 ;)

> Или я не туда смотрел?

А что, диск еще жив??

После установки Linux 2.4.23 возникла следующая проблема с APM: при нажатии на кнопку Power на корпусе компьютера машина стала зависать вместо перехода в ждущий режим. ACPI не используется. 2.4.22 и предыдущие - все ОК.

"машина" - это ноутбук? Включай ACPI. В 2.4.22 такой глюк частично тоже
наблюдается.

"машина" - это десктоп.

Никогда в голову даже не приходило включать ждущий режим на
линукс-десктопе ;) Даже не представляю, как это сделать. Зачем он?
Ты им диски останавливаешь? Если нет, то все, что нужно делает ACPI:
замедляяет вентилятор и снижает энергопотребление процессора автоматом
в моменты бездействия.

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

>>>Самый первый аргумент в пользу ...

Ну скажи еще чего-нибудь, тебе наверное кажется, что твои ответы остроумны. Давай, посмеши еще народ ... 8)