Как убить самый прожорливый прцесс

oom-killer, ulimits

OOM сам убьёт самый прожорливый процесс.

Там на самом деле лотерея получается: он может грохнуть не то, что хотелось бы.

А чего все докапываются до самого прожорливого ? Предлагаю убивать последнего запушенного , до него всё работало. И с отслеживанием лимита тоже фигня получается, несколько виртуалок ,каждая «ограниченная», очень даже неплохо всё подвешивают.

он может грохнуть не то, что хотелось бы

У каждого процесса в /proc/$PID/ есть пара-тройка файлов oom_adj, oom_score, oom_score_adj Для важных процессов, например sshd, выставляется приоритет ООМ, так что его убьют в последнюю очередь.

Ну дык я только вчера проверял: freecad подвесил мне систему, я жамкнул alt+sysrq+f, oom-killer грохнул firefox.

Я, конечно, понимаю, что firefox — дрянь, от которой надо избавляться (правда, пока никаких аналогов нет), но таки жрал он 350МБ оперативки и ~10% CPU, а freecad пытался 3ГБ отожрать (всю оперативку + изрядный кусок свопа) и ~300%CPU.

настрой oom-killer, там не просто самый прожорливый процесс должен убиваться
к тому же бездумно килять процессы по крону - черевато
если очень хочется велосипед - man ps, man sort, man head, man kill

Если я правильно помню логику НБП-убивца (oom-killer), он старается не убивать процессы с активным IO, чтобы избежать порченных файлов. Потому и не тронул freecad и убил «неактивный» firefox

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

а если таких процессов несколько, то какая логика должна быть?

Спасибо!

Не совсем понятно как его настроить, я так понял нужно изменить значение этого файла: /proc/sys/vm/overcommit_memory в 1 или 2?

Алгоритм расчета уровня негодности процесса
http://www.linuxsoft.ru/info/articles/art5113/

вот, например:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80
vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152

Только осторожно этим пользоваться: если перестараться, то вообще новые процессы запускаться не смогут.

а если этим процессом окажется сервер БД - ты ничтоже сумняшеся убьешь его ?

Вообще конечно хочется убивать процессы которые заняли более 4-5ГБ оперативки.

Вот и думал может грепать вывод какой нибудь команды типа top брать оттуда id процесса и убивать.

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

Изначально проблема в php процессе, который запускатеся из под root, и по каким то причинам отжирает всю память (8ГБ) и остаётся только писать в тех поддержку что бы рестартанули сервер потому что даже по ssh не войти.

vm.overcommit_memory = 2

Я бы не советовал.

У меня так на работе. Более-менее ОК.

Можете рассказать что означают эти параметры? vm.dirty_bytes = 2097152 vm.dirty_background_bytes = 2097152

Спасибо!

http://www.kernel.org/doc/Documentation/sysctl/vm.txt

Ещё такой вопросик, а можно логировать информацию о процессах которые убиваются oom-killer'ом или что то подобное?

Это лучше тех, кто ближе с ядром знаком, спрашивать. post-factum'а, например.

OOM-killer плюётся в dmesg. Соответственно, логи могут быть где-то в /var/log.

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

fixed.

Этот скрипт будет регулярно убивать апач и системные демоны. Слабо придумать некостыльное решение?

У меня так на работе. Более-менее ОК.

Запусти для примера sbcl пару экземпляров.

sbcl

Что это?

Плюется:

tailf /var/log/messages.log
…
Jul 10 11:40:49 localhost kernel: [ 1940.834987] SysRq : Manual OOM execution
…

Но никаких упоминаний о том, что прибит firefox.

Это пример. В данном случае это lisp, но не в этом дело.

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

нужно изменить значение этого файла: /proc/sys/vm/overcommit_memory в 1 или 2?

нет - это совсем другая история

Ой не факт, если руками не задать oom-приоритеты.

Этот пример связан с методом выделения памяти. Ты хоть почитай что делает vm.overcommit_memory = 2 . Не копируй настройки не глядя.

выключи своп

Ты хоть почитай что делает vm.overcommit_memory = 2

Читал, знаю: он запрещает выделять памяти больше, чем ее есть физически. Ничего плохого в этом не вижу.

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

Ну ладно.

а что за дистрибутив?

Арч

и по каким то причинам отжирает всю память (8ГБ) и остаётся только писать в тех поддержку

ulimit

Как убить самый прожорливый прцесс

В твоём случае это будет не убийстово, а суицид (одновременно сдохнет и самый бесполезный «процесс»)

ты не пользуешься явой. она у меня с такими параметрами overcommit не завелась вообще

ты не пользуешься явой

Явно не пользуюсь, но что-то ее в зависимостях имеет. Кажется, либреофис.