Избежать смерти убийцы OOM в Linux

1315
Waxhead

Проведя небольшое исследование, я обнаружил, что можно настроить или даже сделать определенные процессы невосприимчивыми к убийце OOM, указав значение в / proc / pid / oom_adj. Мне, конечно, нужно найти pid для своего процесса, используя pidof или pgrep или что-то в этом роде и создайте скрипт, который я запускаю, когда все мои процессы запущены.

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

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

6

1 ответ на вопрос

6
haimg

You should not be relying on OOM killer to manage your processes. OOM killer is a measure of last resort, when the only other alternative is a system crash. E.g. all cache and disk buffers memory was flushed and committed, everything that can be swapped out/discarded is processed, and you still don't have enough memory... Obviously you don't want your running system to ever reach this state.

Because of the strict constrains that OOM killer operates under (cannot allocate more memory, cannot swap in other processes, etc.), it will kill processes you don't want to be killed to relieve memory pressure.

I think if your system just doesn't have enough memory, you need to add more memory or swap space, depending whether you're running out of physical memory or total virtual memory.

If, on the other hand, you have a few runaway processes that consume too much memory from time to time, due to a memory leak or some other bug, you can control that via other means:

  1. Set ulimit -m before starting the offending process and limit how much memory that process can allocate.

  2. Restart the offending process gracefully on a schedule via cron, if there is a memory leak and it is fairly predictable.

In any case, OOM killer is not your friend, it's a loose cannon :-/

это 64-битная система Debian с 8 ГБ оперативной памяти и 6 ГБ подкачки. Я также знаю, какой процесс вызывает проблемы. Завтра я проверю ulimit как вариант. Спасибо за ваш совет! Waxhead 11 лет назад 0