- SCTP -- Stupid Castrated Transport Protocol

ну и где там написано про оомкиллер?

его можно поставить на замену TCP?

> Больше нет oom killer'а.

а чё это за хер?

> Больше нет oom killer'а. а чё это за хер?

Очень-очень маленький киллер : oomk . RTFM .

OOM-killer -- Out-Of-Memory killer - реализация алгоритма выбора процесса для терминирования в ситуации нехватки виртуальной памяти...

А еще они профиксили баги со SpeedTouch :)

то, что SCTP добавили - это хорошо... Long live SCTP :-) А вот с OOM киллером - это они поспешили... Ведь другой алгоритм поведет себя по-другому, и где-нибудь в продакшне может что-то поломаться нехорошо из-за этого :-\ очень надеюсь, что OOM killer сделали все-таки опцией при компиляции ядра.

OOM killer опцией не сделали. Теперь просто убивают того, кто попросил памяти, когда ее не хватает. Говорят, в 99,9% случаев этого достаточно.

OOM killer - зло.

> Теперь просто убивают того, кто попросил памяти, когда ее не хватает. Говорят, в 99,9% случаев этого достаточно.
:( забавно, то есть если у меня запущены процессы apache или postgresql, и какой то товарисч запустил mc в котором memory leak, и этот mc поглотил малех памяти, но не до упора, а так - 100-200Кб оставил, и в этот момент кто то соединяется с моим www, то есть apache/postgresql выделяют память под этого клиента/соединение, то: убьют apache/postgresql, который годами работал, а не глючный mc?
p.s. пример с mc на сервере плохой, но смысл все уловили

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

З.Ы. слака - кака

Вот подождем еще -ac ветки и будем ставить... Куча исправлений в ACPI радует...

ac-ветки - не будет, ждём aa-патчи.

:)))))

По-моему Вы херню порете юноша.

Представьте ситуацию, когда несколько сот процессов сожрали

99% памяти, мне нужно зайти по ssh.

Естественно sshd будет рожать потомка, в этот момент его грохнут.

А кто потом поднимет? Сервер останется без sshd?

Это будет полный пипец.

нужно быть очень умной прогой чтобы сжирать памяти на 1 кб меньше чем ее есть в системе. если это не прога вредитель (а просто утечка) то вероятность такого события практически нулевая... соответственно либо вам будет памяти хватать, либо утекающая прога грохнется.

хотя лично на мой взгляд правильней конечно придавить того кто больше памяти съел

2saper:

Не надо забывать, что это реализовано в ядре. Я уверен, что есть способ узнать количество свободной памяти. Реализация malloc в glibc может сначала проверить сколько памяти и вернуть NULL если ее не хватает.

Правильней писать программы, которые знают о том, что памяти в системе не бесконечно много. Тогда и никакие OOM-киллеры не понадобятся.

//Losiki

> Правильней писать программы, которые знают о том, что памяти в системе не бесконечно много.

Это правильно с точки зрения программы. Хочет жить и умирать не сегфолтом - пусть проверяет каждый malloc. Однако, никто заставить ее это делать не может; поэтому ядро должно к каждому процессу подходить с точки зрения его потенциальной виновности :) Короче, уметь прибивать все, что мешает нормальному функционированию системы.

"- Так вы и думать за меня будете?"
"- А-а-а-а-ага-а-а-ааа!"

Не согласен. Потенциальную опасность той или иной программульки могу оценить только я - тот, кто на этой машине царь и бог. И исходя из этого раздать лимиты(пусть куцые и не гибкие). Вот это вот "мы за вас тут подумали" меня и раздражает.

//Losiki

>ac-ветки - не будет,

как это не будет????

>ждём aa-патчи.

это тормозилово и глюкалово?
лучше ядро не уродовать этими "патчами"

Блин так было же на кернелтрап помоему обсуждение, где Марселло после вливание патчей от -аа был недоволен поведением системы при убирании оом-киллера. И насколько я помню ккой-то кекс написал патч где было еще 2 алгоритма оом-киллера.И при компиляции можновыбрать из 3 вариантов или отсутсвия оом-киллера. Разве это выкинули?

Не понимаю я. Делается системный вызов "дай_памяти" (не знаю, как он называется в современном ядре, раньше был brk). Если памяти нет, он должен возвратить -ENOMEM. Вместо этого он посылает SIGKILL? И как в этом случае программа сможет сохранить пользовательские данные? Если программа -- текстовый редактор, и юзер целый день стучал по клаве, то все его старания накрылись медным тазом, так получается? Даже если редактор вполне может обработать ситуацию нехватки памяти, выведя сообщение об этом в строку состояния.

Это же бред. Многопользовательская система должна гарантировать юзеру, что некорректная работа других юзеров на нем не скажется. А если система даже этого не может, то в помойку такую систему. Тот же DOS/Windows, только в профиль.

И пофиг мне маловероятность такой ситуации. Какова вероятность что питание пропадет в момент между open(O_TRUNC) и write(новые_данные)? Маленькая вероятность. А у меня таким образом дневная работа накрылась. И легче мне не стало от того, что это маловероятно. После этого упсу купил. А с ядром что делать? На 2.4.22 всю жизнь сидеть? Бардак, блин.

у меня в Слаке это уже давно

>Не надо забывать, что это реализовано в ядре. Я уверен, что есть способ узнать количество свободной памяти. Реализация malloc в glibc может сначала проверить сколько памяти и вернуть NULL если ее не хватает.

Попробуйте таки RTFM - помогает

hint: реальное выделение памяти идет при соммите а не при аллоке

> Делается системный вызов "дай_памяти" (не знаю, как он называется в современном ядре, раньше был brk). Если памяти нет, он должен
> возвратить -ENOMEM. Вместо этого он посылает SIGKILL?
Если overcommit запрещён, то нет, будет тебе твой -ENOMEM.
А разрешил overcommit - сам вырыл себе могилу, получай свой SIGKILL
или чего там ещё.

Вот и я думаю, чтобы сделать DoS изнутри системы с полномочиями простого пользователя достаточно "сначала проверить сколько памяти" свободно ... :(

Простому пользователю, нормальные админы, лимиты должны ставить, а ежели простому смертному, позволено забить всю память, то это проблема не ядра!

> Естественно sshd будет рожать потомка, в этот момент его грохнут.
> А кто потом поднимет? Сервер останется без sshd?
> Это будет полный пипец.

Хух! И таких людей кто-то держит в админах??? Я твоей конторе не
завидую. Ссаныч, абсолютно неквалифицированный человек.

сделал DoS, вот что получилось:


% dmesg

hdc: timeout waiting for DMA
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: DMA disabled
ide1: reset: success

Out of memory for httpd.

Out of memory for klogd.

Out of memory for update.

Out of memory for actived.

Out of memory for rclock.

Out of memory for syslogd.

Out of memory for gpm.

Out of memory for init.

> hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }

Знаешь, что сия запись означает? У тебя сыпится диск. Спасай данные,
пока все не накрылось.

Чтобы памяти хватало есть swap. Если вы не расчитали размер swap-а на предпологаемые пиковые нагрузки, то никакой OOM вам не поможет.

> Если вы не расчитали размер swap-а на предпологаемые пиковые > нагрузки, то никакой OOM вам не поможет.

Ну расчитали мы. Теперь это _никогда_ не произойдет?

Речь идет о том кого надо убивать если это случилось. oom killer решает это интеллектуально (мож поэтому его убрали :) Шанс быть убитым увеличивается при большем memory use, меньшем возрасте, отсутсвии рут-привилегий...

Кстати, на голосовании на kerneltrap, все хотят oom killer обратно :) http://kerneltrap.org/node/view/1017 Начиная с 2.4.23-pre4.

> Не согласен. Потенциальную опасность той или иной программульки могу оценить только я - тот, кто на этой машине царь и бог.

Вы на машине - непривилегированный эккаунт, или, в лучшем случае, root. Ни то, ни другое не даёт вам права систему корраптить. То, что ваша "абсолютно безопасная" программа хоть раз в жизни навернется - это факт. А если она еще и за собой систему потянет (которая, по вашим представлением, не должна следить за тем, что программы вытворяют) - сами виноваты.

> И исходя из этого раздать лимиты(пусть куцые и не гибкие).

Мы про oomk говорим, не забыли? При чем здесь ваши лимиты? Имеете права - раздавайте на здоровье.

> Вот это вот "мы за вас тут подумали" меня и раздражает.

Анархизм в ОС неприемлем. Юзайте ДОС, она для вас.

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

> То, что ваша "абсолютно безопасная" программа хоть раз в жизни навернется - это факт.
[...]
> При чем здесь ваши лимиты?

Дык при том, лимиты, что не дают "абсолютно безопасной" программе
навернуть систему... Что не понятно?

> А жаль - его *-ac были лучшими. аа ветка как была сумбурной и богатой глюками - так и осталась.

Враньё. Все обстоит как раз наоборот. Ветка Алана - вечный конвейер для
экперементальных патчей. Туда включалось все, что выходило из нового для
обкатки. После обкатки Алан рекомендовал или не рекомендовал включение
новый патчей в основную ветку.

А если взять ветку -aa, то ситуация с ней совершенно другая. Андреа -
человек, который поддерживает реально работающие крупные сервера, и его
ветка была предназначена для улучшения работы этих серверов, так как
основная ветка Линуса - достаточна консервативна, и медленно
воспринимала работающие патчи, особенно те, что изменяли поведение VM.

ага, особенно вспомним 2.4.21-aa1 на котором оракл и ещё некоторые крупные приложения валились в корку

> особенно вспомним 2.4.21-aa1

А если еще лучше вспомнить, что ядра 2.4.21-aa1 никогда не было...
Было 2.4.21rc8aa1. А если еще получше вспомнить, что между post-2.4.19
и 2.4.22 со всеми ядрами были проблемы в той или иной степени - и в основной ветке, и в -ac... то что такого исключительного в проблеме -aa?
Лично я не обновлял на продакшн серверах ядра до выхода 2.4.22.
Использовал 2.4.19rc5aa1, потому что новые ядра не проходили мои тесты.
А 2.4.19rc5aa1 работал безукоризненно. Если ты действительно тестировал
-aa ядра с ораклом, то ты должен отлично знать, почему тебе вообще
взбрело в это в голову. Ответ прост: ни у каких других ядер нет такой
качественной работы VM. Никакие дугие ядра не позволяли менять
соотношение userspace/kernelspace распределения памяти. На машинах с
1Гиг памяти -aa позволяли полностью использовать весь 1Г, в отличие от
других ядер, где предел был ~900Mb.

а ещё вспомним, что 2.4.21rc8 = 2.4.21, поэтому именно 2.4.21rc8aa1 я имел ввиду, когда говорил о 2.4.21aa1

поставил 2.4.23 конфиг брался make oldconfig с 2.4.22 работало месяцами, через паруминут работы наглухо подвисал сервак с матюками на консоль .., реземю..., в жопу такие ядра.!

да, ждём когда Кокс выпустит свой патч до этих пор все сидим на 2.4.22-ac3

> Если overcommit запрещён, то нет, будет тебе твой -ENOMEM. А разрешил overcommit - сам вырыл себе могилу, получай свой SIGKILL или чего там ещё.

Что такое overcommit? Им из юзерской программы можно управлять, или это root должен делать sysctl'ом? Где можно почитать подробности про overcommit и про то как запретить его?

> именно 2.4.21rc8aa1 я имел ввиду

Что имеешь, то и говори. А если не было ядра 2.4.21aa1, то признайся
спокойно, без гнилых оправданий. И это не просто придирка к номеру
версии. Я точно знаю, что человек, реально работающий с некоторым ядром
никогда не перепутает версию. Так что твои комментарии в любом случае
неинтересны.

Вкратце ситуация с overcommit такая: в отличие от *bsd систем в линуксе
память условно говоря никогда не кончалась. На любой запрос malloc
система отчвечала "память выделена успешно", даже если реальной памяти
для данного запроса уже не было. Проблема возникала только когда в
условиях нехватки памяти приложение начинало _реально_ обращаться к
якобы успешно выделенной памяти. Плох такой подход или хорош?

Сторонники объясняют так: есть достаточное количество приложений
(пример - netscape), которые выделяют память про запас, долгое время ее
не используя. Пока они хватятся, эту память можно сто раз переиспользовать под текущие нужды. Противники говорят, что при таких
правилах трудно прогнозировать поведение системы. Короче, договорились
до того, что поступило предложение сделать поведение системы
опциональным, на выбор админа. Впервые такой патч опробовал Кокс (Alan
Cox) в своей -ac ветке. Управлять поведением overcommit стало возможным
через /proc интерфейс динамически.

> Вкратце ситуация с overcommit такая: в отличие от *bsd систем в линуксе
> память условно говоря никогда не кончалась.
Не верно. На 32-разрядных архитектурах больше 4Гб не получить. Только
меньше. Реально даже меньше 3, т.к. последний гиг линейного адресного
пр-ва отведён для ядра.
С PAE на ia32 можно выжать по-больше, но один процесс всё равно
больше 4Гб не получит.
На 64-разрядных, конечно, предел не такой хилый, но насчёт
"никогда не кончается" - это ты загнул. Линейное адресное пр-во не
бесконечно.

Объясните мне слудующию штуку.
overcommit установлен в ноль. Ядро - 2.4.21 без патчей. Имеет следующее:

bash-2.05b$ cat memeat.c
#include <errno.h>
#include <stdlib.h>

#define ONEM    1024*1024*MB

int main()
{
    void *m;
    int i;
    for(i=0; i<256; i++) {
	m = malloc(ONEM);
	if ( m == NULL ) {
	    printf("Can't malloc: %s\n",strerror(errno));
	    exit(1);
	}
	memset(m,'\0',ONEM);
	printf("Used memory: %d Mb\n", (i+1)*MB);
    }
    return(0);
}
bash-2.05b$ tcc -D MB=10 memeat.c
Used memory: 10 Mb
Used memory: 20 Mb
Used memory: 30 Mb
Used memory: 40 Mb
Used memory: 50 Mb
Used memory: 60 Mb
Used memory: 70 Mb
Used memory: 80 Mb
Used memory: 90 Mb
Used memory: 100 Mb
Used memory: 110 Mb
Used memory: 120 Mb
Used memory: 130 Mb
Used memory: 140 Mb
Used memory: 150 Mb
Used memory: 160 Mb
Used memory: 170 Mb
Used memory: 180 Mb
Used memory: 190 Mb
Used memory: 200 Mb
Used memory: 210 Mb
Used memory: 220 Mb
Killed
bash-2.05b$ tcc -D MB=100 memeat.c
Used memory: 100 Mb
Used memory: 200 Mb
Can't malloc: Cannot allocate memory
bash-2.05b$ 

Почему так происходит. Почему если я выделаю 100 мб то как и полагается говорят что памяти нет. Если 10 - говорят что есть, но потом пришибают. Если установить overcommit в единицу в обоих случаях как и должно быть получаем Killed.

Хм... У меня то же самое с 2.6.0-test11. Правда, проверял только при /proc/sys/vm/overcommit_memory=0

> Не верно. На 32-разрядных архитектурах больше 4Гб не получить.

Так ведь и написано "условно говоря никогда не кончалась".
Знаешь такое слово - "условно"? ;)

> Почему если я выделаю 100 мб то как и полагается говорят что памяти нет.

Потому что граница срабатывания несколько больше, чем объем доступной
памяти. Иными словами, overcommit не жесткий. В первом случае твоя прога
по старинке прибивается OOM-киллером. В ветке -ac есть так называемый
strict-overcommit. Тот не даст памяти, если система не может ее
физически предоставить. А вообще, я советую всё и всегда запускать со
взведенными лимитами. Попробуй то же самое повторить после команды
ulimit -v 100000