Przez lata zabójca OOM mojego systemu operacyjnego nie działa poprawnie i prowadzi do zawieszenia systemu.
Kiedy użycie pamięci jest bardzo duże, cały system ma tendencję do „zamrażania” (w rzeczywistości: staje się bardzo wolny) przez godziny lub nawet dni , zamiast zabijania procesów w celu zwolnienia pamięci.
Maksymalne, które zarejestrowałem, to 7 dni przed rezygnacją z operacji resetowania.
Kiedy OOM ma zostać osiągnięty, iowait jest bardzo, bardzo wysoki (~ 70%), zanim staje się niemożliwy do zmierzenia.
Narzędzie: iotopwykazało, że każdy program odczytuje z mojego dysku twardego bardzo dużą przepustowość (na dziesiątki MB / s).
Co czytają te programy?
- Hierarchia katalogów?
- Sam kod wykonywalny?
Nie do końca teraz.
[edytuj] W tym czasie, kiedy pisałem ten komunikat (w 2017 r.), korzystałem z zaktualizowanego ArchLinux (4.9.27-1-lts), ale problem ten występował już wiele lat wcześniej.
Wystąpił ten sam problem z różnymi dystrybucjami Linuksa i różnymi konfiguracjami sprzętowymi.
Obecnie (2019) używam zaktualizowanego Debiana 9.6 (4.9.0) Mam 16 GB pamięci RAM, dysk SSD, na którym jest zainstalowany mój system operacyjny, a nie żadną partycję wymiany .
Z powodu ilości pamięci RAM, którą mam, nie chcę włączać partycji wymiany, ponieważ opóźniłoby to pojawienie się problemu.
Ponadto zbyt częsta zamiana dysków SSD może potencjalnie skrócić żywotność dysku.
Nawiasem mówiąc, próbowałem już z partycją wymiany i bez niej, okazało się, że opóźnia to pojawienie się problemu, ale nie jest rozwiązaniem.
Dla mnie problem jest spowodowany tym, że Linux upuszcza niezbędne dane z pamięci podręcznych , co prowadzi do zamrożenia systemu, ponieważ musi on odczytywać wszystko za każdym razem z dysku twardego.
Zastanawiam się nawet, czy Linux nie upuściłby wykonywalnych stron kodowych uruchomionych programów, co tłumaczyłoby, dlaczego programy, które zwykle nie czytają dużo danych, zachowują się w ten sposób.
Próbowałem kilku rzeczy, aby rozwiązać ten problem.
Jeden zestaw miał /proc/sys/vm/min_free_kbytesna 1000000(1 GB).
Ponieważ ten 1 GB powinien pozostać wolny, pomyślałem, że ta pamięć zostanie zarezerwowana przez Linuksa do buforowania ważnych danych.
Ale to nie zadziałało.
Ponadto uważam, że warto dodać, że nawet jeśli mogłoby to brzmieć świetnie w teorii, ograniczając rozmiar pamięci wirtualnej do rozmiaru pamięci fizycznej, określając, /proc/sys/vm/overcommit_memoryże 2nie jest to technicznie możliwe w mojej sytuacji, ponieważ tego rodzaju aplikacje którego używam, wymagają więcej pamięci wirtualnej niż z pewnych powodów efektywnie wykorzystują.
Z akt sprawy wynika /proc/meminfo, Commited_ASwartość jest często wyższa niż podwójna fizycznej pamięci RAM w moim systemie (16 GB, Commited_AS często> 32 GB).
Wystąpił ten problem z /proc/sys/vm/overcommit_memoryjego wartością domyślną: 0i przez pewien czas go zdefiniowałem: 1ponieważ wolałem, aby programy były zabijane przez zabójcę OOM niż zachowywały się źle, ponieważ nie sprawdzają zwracanych wartości, mallockiedy przydziały są odrzucane.
Kiedy mówiłem o tym problemie na IRC , spotkałem innych użytkowników Linuksa, którzy doświadczyli tego samego problemu, więc myślę, że wielu użytkowników jest tym zaniepokojonych.
Dla mnie jest to niedopuszczalne, ponieważ nawet Windows lepiej radzi sobie z wysokim zużyciem pamięci.
Jeśli potrzebujesz więcej informacji, napisz sugestię, proszę mi powiedzieć.
Dokumentacja:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/
Mówią o tym:
Dlaczego zabójca braku pamięci w systemie Linux (OOM) nie działa automatycznie, ale działa na kluczu sysrq?
Dlaczego zabójca OOM czasami nie udaje się zabić wieprzy zasobów?
Wstępne ładowanie OOM Killera
Czy można uruchomić OOM- Killera przy wymuszonej zamianie?
Jak uniknąć dużych opóźnień w pobliżu sytuacji OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843
min_free_kbytesnie ma znaczenia, nie jest rezerwą dla stron w pamięci podręcznej. AFAICT żaden z systemów vm nie pozwala na rezerwowanie pamięci specjalnie dla stron buforowanych, tj. Ograniczenie przydziałów MAP_ANONYMOUS :(.