LINUX.ORG.RU

Linux 2.4.23


0

0

Вышло ядро 2.4.23. Вкратце из сделанного:

- Множество исправлений и обновлений в ACPI, USB, Netfilter, сетевой подсистеме, драйверах и др.
- Крупные вливания патчей VM-подсистемы из ветви -aa. Больше нет oom killer'а.
- SCTP -- новый транспортный протокол уровня TCP и UDP.
- IP Virtual Server.

И это только часть. Интересующиеся смотрите ссылку

>>> Changelog



Проверено: maxcom

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

svyatogor ★★★★★
()

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

turanchox
()
Ответ на: комментарий от turanchox

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

nickg
() автор топика
Ответ на: комментарий от nickg

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

saper ★★★★★
()
Ответ на: комментарий от saper

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

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

Shaman007 ★★★★★
()

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

anonymous
()
Ответ на: комментарий от Shaman007

:)))))

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

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

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

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

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

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

Sun-ch
()
Ответ на: :))))) от Sun-ch

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

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

anonymous
()
Ответ на: комментарий от saper

2saper:

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

anonymous
()
Ответ на: комментарий от anonymous

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

//Losiki

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

//Losiki

anonymous
()
Ответ на: комментарий от Deleted

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

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

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

nobody ★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

sS ★★★★★
()
Ответ на: комментарий от nobody

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

anonymous
()
Ответ на: комментарий от sS

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

saper ★★★★★
()
Ответ на: комментарий от saper

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

anonymous
()
Ответ на: :))))) от Sun-ch

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

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

anonymous
()

сделал 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.

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

> особенно вспомним 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.

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

nobody ★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от nobody

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Объясните мне слудующию штуку.
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.

anonymous
()
Ответ на: комментарий от anonymous

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

yozhhh ★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.