Вбивця OOM не працює?

Наскільки я розумію, коли система близько не має вільної пам'яті, ядро ​​повинно починати вбивати процеси, щоб відновити деяку пам'ять. Але в моїй системі цього взагалі не відбувається.

Припустимо простий скрипт, який просто виділяє набагато більше пам’яті, ніж наявний в системі (наприклад, масив з мільйонами рядків). Якщо я запускаю такий сценарій (як звичайний користувач), він просто отримує всю пам'ять, поки система повністю не застигне (працює тільки SISRQ REISUB).

Дивна частина тут полягає в тому, що коли комп'ютер замерзає, світлодіодний накопичувач включається і залишається таким чином, поки комп'ютер не перезавантажиться, чи у мене встановлений розділ підкачки, чи ні!

Тому мої запитання:

1. Це нормальна поведінка? Як не дивно, що програма, виконана як звичайний користувач, може просто зламати систему таким чином ...
2. Чи є спосіб, щоб я змусив Ubuntu просто вбити автоматично ті програми, коли вони отримують занадто багато (або найбільше) пам'яті?

Додаткова інформація

• Ubuntu 12.04.3
• Ядро 3.5.0-44

• ОЗУ: ~ 3,7 Гб від 4 ГБ (спільне використання відеокарти). *

  $ tail -n+1 /proc/sys/vm/overcommit_*
  ==> /proc/sys/vm/overcommit_memory <==
  0
  
  ==> /proc/sys/vm/overcommit_ratio <==
  50
  
  $ cat /proc/swaps
  Filename                Type        Size    Used    Priority
  /dev/dm-1                               partition   4194300 344696  -1
  

З офіційної /proc/sys/vm/*документації :

oom_kill_allocating_task

Це дозволяє або забороняє вбивати завдання, що спрацьовує OOM, у ситуаціях, що не мають пам'яті.

Якщо для цього встановлено нульове значення, вбивця OOM просканує весь список завдань і вибере завдання на основі евристики для вбивства. Зазвичай це вибирає шахрайське завдання, пов'язане з пам’яттю, яке звільняє велику кількість пам’яті при вбиванні.

Якщо для цього встановлено ненульове значення, вбивця OOM просто вбиває завдання, яке викликало стан поза пам'яті. Це дозволяє уникнути дорогого сканування списку завдань.

Якщо вибрано panic_on_oom, він має перевагу над тим, яке значення використовується в oom_kill_allocating_task.

Значення за замовчуванням - 0.

Щоб підсумувати, під час встановлення oom_kill_allocating_taskна 1, замість сканування вашої системи шукати процеси для вбивства, що є дорогим і повільним завданням, ядро ​​просто знищить процес, через який система вийшла з пам'яті.

З мого власного досвіду, коли спрацьовує OOM, ядро ​​не має більше «сили», щоб зробити таке сканування, що робить систему абсолютно непридатною.

Крім того, було б більш очевидним просто вбити завдання, яке спричинило проблему, тому я не розумію, чому це встановлено 0за замовчуванням.

Для тестування ви можете просто записати у відповідний псевдофайл у /proc/sys/vm/, який буде скасовано при наступному перезавантаженні:

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

Для постійного виправлення, написати наступне /etc/sysctl.confабо в новий файл під іншим /etc/sysctl.d/, з .confрозширенням ( /etc/sysctl.d/local.confнаприклад):

vm.oom_kill_allocating_task = 1

Оновлення: помилка виправлена.

Відповіді Терези достатньо, щоб вирішити проблему, і це добре.

Крім того, я подав звіт про помилку, оскільки це, безумовно, порушена поведінка.

Ви можете спробувати earlyoom , убивцю OOM, який працює в просторі користувачів і намагається вбити найбільший процес у ситуації OOM.

Перш за все, я рекомендую оновлення до 13.10 (чисте встановлення, збережіть ваші дані).

Якщо ви не хочете оновлювати, змініть vm.swappiness на 10 і якщо у вас виникнуть проблеми з вашим операційним пакетом, встановіть zRAM.