Вот тут лежит годный мануал от местного товарища catap, там и описание и способ порулить.

Это часть ядра. Активируется автоматически, если забито всё(даже своп), и некуда выделять память даже ядру. Где-то в /proc/sys есть парочка файлов, регулирующих его поведение.

man magic key

sysrq+f убъёт самый затратный по мнению ядра процесс

Нужно отключиться swap.

херню написал

Гуглил долго, про oom-killer много чего прочитал
whereis его не нашёл, в репах его не нашёл.

нюню. иди ищо погугли да репах поищи получше.

alt+SysRq+F

только оно в некоторых дистрибутивах по умолчанию отключено (посмотреть на предмет kernel.sysrq = 0 в /etc/sysctl.conf или что-то подобное)

Можно переключить в /etc/sysctl.conf ООМ что бы он убивал задачу на которой кончилась память

vm.oom_kill_allocating_task = 1

Но во первых, не факт что такое выскочит на именно на хроме, во вторых убивать он начнет когда кончится ram+swap

То есть возможно придется отрубать swap, если я правильно понял начальный посыл

Плохо гуглил.

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

Тут ключевая фраза «по мнению ядра», попробовал - по моему мнению самый затратный firefox был убит с 9 попытки.

не «своп медленный», подсистема виртуальной памяти кривая. помогает наоборот поднять swappiness и min_free_kbytes

это очень глупо, тк постоянно будут валиться невиновные программы

Плохо гуглил.

Да нет, нормально. Но у меня оом-киллер не запускался сам, раз я фризы ловил. Подумал, вдруг у меня его вообще нет. В гугле описываются разные параметры, которые позволяют на него повлиять. Но это для тех, кто знает, с чем дело имеет - я не понял например сразу, как и куда их применять.

помогает наоборот поднять swappiness и min_free_kbytes

т.е. я могу указать, чтобы когда например 50Мб оперативной памяти остаётся - оом-киллер запускался?

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

Ну я вот фриз словил бывало, мышка не двигается почти. Пошёл покурил, чая попил итд, вернулся - всё как было.

Тут ключевая фраза «по мнению ядра», попробовал - по моему мнению самый затратный firefox был убит с 9 попытки.

grep -i kill /var/log/messages* > killed.txt
fpaste killed.txt

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

это очень глупо, тк постоянно будут валиться невиновные программы

Как будто по умолчанию ООМ убивает очень «по умному» и только «виновные» программы.

/var/log/messages-20150412:Apr 8 10:44:40 localhost kernel: [69324.522384] Out of memory: Kill process 23986 (chrome) score 365 or sacrifice child

Угадай, что в буквосочетании «OOM-Killer» обозначают буквы «OOM»?
И по ссылке, приведённой выше, можно узнать, каким образом ядро высчитывает очки для программы, которую будет убивать.

Посоны, а шо никто не запиливал какой-нить демон-следильщик за конкретным процессом и его тредами? Шоп можно было внести команду запуска, выставить лимиты на память, проц, кол-во тредов, шоп он это отслеживал и если лимит превышен — тогда килял бы этого гада. А?

ды есть один, пилит всякие низкоуровневые штуки. с финки в сшп свалил, на лоре не зареган. крч, интроверт. линус, кажется, звать

JK ★ (15.04.2015 9:00:03) хамло

Люблю, когда заметки о людях подтверждаются.

systemd же.

(systemd.resource-control(5))

Вопрос явно не про ядро, ибо туда не залезешь. Пусть оно там дальше OOM дергает когда захочет. Я именно про демона. Вон intelfx правильно понял.

Чот я не нашел там что можно четко сказать этой хрени «виш вон хром запущен — если будет жрать более 1 гб при 10 вкладках (тредах) то убей десятую, пусть 9 останется»

По мнению оом-киллера всё в порядке, по ходу фризы его не волнуют. Если в графике сидеть прибивается firefox, все правильно, но руки сводит нажимать ctrl alt sysrg f, поэтому переключаюсь в консоль, а там alt sysrg f, но «затратными» становятся переключалка раскладок, буфер обмена и прочая мелочевка. Загадочно всё это.

у меня вполне адекватно

это и есть oom killer, а в юзерспейсе его нельзя реализовать, он сам может стать жертвой нехватки памяти

фризы происходят потому, что во многих частях ядра просто крутится бесконечный цикл, пока kalloc возвращает ошибку

можно задать для каждого процесса «виновность» /proc/$pid/oom_score_adj, для отожравших много памяти это значение автоматически повышается

помогает наоборот поднять swappiness и min_free_kbytes

Не уверен насчёт min_free_kbytes, но swappiness выкрутить в 100 ТСу будет явно полезно.
Сразу куча анонимных страниц, иначе почём зря болтающихся в памяти, посыпется в своп.