OOM Killer nie działa?

Z tego co rozumiem, kiedy system jest blisko i nie ma wolnej pamięci, jądro powinno zacząć zabijać procesy, aby odzyskać trochę pamięci. Ale w moim systemie tak się wcale nie dzieje.

Załóżmy, że prosty skrypt, który po prostu przydziela znacznie więcej pamięci niż dostępna w systemie (na przykład tablica zawierająca miliony ciągów znaków). Jeśli uruchomię taki skrypt (jako zwykły użytkownik), po prostu pobierze całą pamięć, aż system całkowicie się zawiesi (działa tylko SysRQ REISUB).

Dziwne jest to, że gdy komputer zawiesza się, dioda dysku twardego włącza się i pozostaje tak do momentu ponownego uruchomienia komputera, czy mam zamontowaną partycję wymiany, czy nie!

Więc moje pytania to:

1. Czy to zachowanie jest normalne? Dziwne, że aplikacja wykonana jako zwykły użytkownik może po prostu zawiesić system w ten sposób ...
2. Czy jest jakiś sposób, aby zmusić Ubuntu do automatycznego zabijania tych aplikacji, gdy mają za dużo (lub najwięcej) pamięci?

Dodatkowe informacje

• Ubuntu 12.04.3
• Jądro 3.5.0-44

• RAM: ~ 3,7 GB z 4 GB (współdzielone z kartą graficzną). *

  $ 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
  

Z oficjalnej /proc/sys/vm/*dokumentacji :

oom_kill_allocating_task

To włącza lub wyłącza zabijanie zadania wyzwalającego OOM w sytuacjach braku pamięci.

Jeśli ta wartość zostanie ustawiona na zero, zabójca OOM przejrzy całą listę zadań i wybierze zadanie oparte na heurystyce do zabicia. Zwykle wybiera to nieuczciwe zadanie zapamiętywania pamięci, które zwalnia dużą ilość pamięci po zabiciu.

Jeśli jest ustawiona na niezerową, zabójca OOM po prostu zabija zadanie, które wywołało stan braku pamięci. Pozwala to uniknąć kosztownego skanowania listy zadań.

Jeśli wybrano opcję panic_on_oom, ma ona pierwszeństwo przed dowolną wartością użytą w zadaniu oom_kill_allocating_task.

Wartość domyślna to 0.

Aby podsumować, podczas ustawiania oom_kill_allocating_tasksię 1, zamiast skanowanie systemu szuka procesów zabijać, który jest kosztowny i powolny zadanie, jądro będzie po prostu zabić proces powodujący, że system wyjść z pamięci.

Z moich własnych doświadczeń wynika, że ​​po uruchomieniu OOM jądro nie ma już wystarczającej „siły” do wykonania takiego skanowania, dzięki czemu system jest całkowicie bezużyteczny.

Bardziej oczywiste byłoby po prostu zabicie zadania, które spowodowało problem, więc nie rozumiem, dlaczego jest ustawione 0domyślnie.

Aby przetestować, możesz po prostu napisać w odpowiednim pseudo-pliku /proc/sys/vm/, który zostanie cofnięty przy następnym uruchomieniu:

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

Dla stałej poprawki, napisać następujące do /etc/sysctl.conflub do nowego pod pliku /etc/sysctl.d/, z .confrozszerzeniem ( /etc/sysctl.d/local.confna przykład):

vm.oom_kill_allocating_task = 1

Aktualizacja: Błąd został naprawiony.

Odpowiedź Teresy wystarczy, aby obejść problem i jest dobra.

Dodatkowo, zgłosiłem raport o błędzie, ponieważ jest to zdecydowanie zepsute zachowanie.

Możesz spróbować wcześnie , zabójca OOM, który działa w przestrzeni użytkownika i próbuje zabić największy proces w sytuacji OOM.

Przede wszystkim polecam aktualizację do 13.10 (czysta instalacja, zapisz dane).

Jeśli nie chcesz aktualizować, zmień vm.swappiness na 10 i jeśli napotkasz problemy z ram, zainstaluj ZRAM.