Czy jest możliwe, aby zabójca OOM interweniował wcześniej?

34

Staram się dostosować mój system programistyczny do maksymalnej niezawodności. Wyłączyłem swap, ponieważ w przypadku użycia GUI powoduje to, że maszyna przestaje reagować w taki sposób, że nie jest już dłużej użyteczna. Niemniej jednak, jeśli agresywne aplikacje pochłaniają pamięć, wydaje się, że niektóre mechanizmy wykorzystują to, aby maksymalnie wykorzystać koszt szybkości. Nie ma operacji wymiany dysku twardego, ale system również przestaje reagować. Chcę więc pozwolić, aby zabójca OOM uruchomił się, zanim system podejmie jakiekolwiek specjalne wysiłki w celu zwiększenia pamięci. Czy można skonfigurować zabójcę OOM do działania, jeśli na przykład jest mniej niż 100 MB wolnej pamięci fizycznej?

linux-kernel memory-management

— dronus
źródło

2

Myślę, że prawdziwym problemem jest to, że nie ma wystarczającej ilości pamięci RAM na początek. Nie użyjesz zamiany, chyba że nie będzie pamięci RAM. Wyłączając swap ... zabrakło ci pamięci RAM i nie masz gdzie go przeszukać. Co powoduje brzydkie rzeczy. Wygląda na to, że twój system jest źle skonfigurowany i żadne poprawki nie naprawią tego.

— Journeyman Geek

8

Nie zgadzam się Rozwój i „zużycie energii” często wiąże się z użyciem eksperymentalnym. Na przykład, gdy używasz narzędzia do przetwarzania obrazu z wiersza poleceń, nie ma specyfikacji, ile pamięci zajmuje jego operacja w stosunku do rozmiaru obrazu. Więc po prostu próbuję. I nie oczekuję, że cała moja maszyna stanie się bezużyteczna. W przypadku pojedynczego eksperymentu mógłbym użyć ulimit, aby zabezpieczyć go, ale w przypadku operacji całego systemu z czasami dużą liczbą operacji powstrzymanie jednego procesu nie jest tak przydatne, ale zdecydowanie „ubezpieczenie na życie” dla całej maszyny.

— dronus

1

Podejrzany jest fakt, że twój system zatrzymuje się podczas korzystania z zamiany. Twój komputer używa funkcji wymiany, ponieważ brakuje pamięci. Swap zwalnia, ponieważ dostęp do dysku jest powolny. Dostęp do dysku jest wolny z powodu ???. Jego problemy do końca. Nie chodzi tylko o to, że masz mało pamięci RAM. Chodzi o to, że nie można użyć jednego sposobu na złagodzenie tego z powodu czegoś innego.

— Journeyman Geek

7

@JourneymanGeek, jesteś w lewym polu. Dyski są powolne w porównaniu do pamięci RAM, kropka, dlatego ciężka zamiana zawsze powoduje zatrzymanie systemu. Oczywiście brakuje mu pamięci, ponieważ próbował uruchomić program, który zużywa dużo pamięci. Pytanie brzmi: co zrobić, gdy brakuje pamięci? Zabij wieprza lub zwolnij z powodu braku pamięci dla pamięci podręcznej dysku.

— psusi

2

@TomWijsman, dyskowe operacje we / wy są o wiele rzędów wielkości wolniejsze niż operacje we / w pamięci, więc użycie zamiany dysku zawsze oznaczało ogromne spowolnienie. Czasami (szczególnie w dawnych czasach, kiedy baran był drogi, a więc większość ludzi nie miała wiele), lepiej nie móc robić tego, czego próbujesz. W dzisiejszych czasach dysk jest TAK znacznie wolniejszy niż taran, a taran jest na tyle tani, że większość ludzi ma go dużo, więc w rzadkich przypadkach, gdy przypadkowo uruchamiają coś, co zużywa więcej taranowania niż zwykle, często lepiej jest zrezygnować niż wziąć 1000 tyle razy, aby to zrobić.

— psusi

36

Walczyłem również z tym problemem. Chcę tylko, aby mój system pozostał responsywny, bez względu na wszystko, i wolę tracić procesy niż czekać kilka minut. Wydaje się, że nie ma sposobu na osiągnięcie tego przy użyciu narzędzia do zabijania jądra.

Jednak w przestrzeni użytkownika możemy robić, co chcemy. Napisałem więc demona Early OOM ( https://github.com/rfjakob/earlyoom ), który zabije największy proces (przez RSS), gdy dostępna pamięć RAM spadnie poniżej 10%.

Bez wczesnej przerwy można łatwo zablokować maszynę (8 GB pamięci RAM), uruchamiając http://www.unrealengine.com/html5/ kilka razy. Teraz winne karty przeglądarki giną, zanim sprawy wymkną się spod kontroli.

— Jakob
źródło

3

Dzięki za podrapanie tego świądu! Jak dotąd kochanie wcześnie.

— Thomas Ferris Nicolaisen,

1

Właśnie zorientowałem się, że Android robi to samo przez długi czas. Nie jestem pewien, czy używa do tego niestandardowego kodu takiego jak Twój.

— dronus

1

Testuję earlyoomteraz, sprawdza się w pierwszym teście wyzwalania. Zastanawiam się tylko, dlaczego nie można tego zaimplementować za pomocą konfiguracji jądra lub narzędzi systemowych.

— dronus

12

Domyślną zasadą jądra jest zezwalanie aplikacjom na alokowanie pamięci wirtualnej tak długo, jak jest wolna pamięć fizyczna. Pamięć fizyczna nie jest faktycznie używana, dopóki aplikacje nie dotkną przydzielonej pamięci wirtualnej, więc aplikacja może przydzielić znacznie więcej pamięci niż system, a następnie rozpocząć dotykanie jej później, powodując brak pamięci w jądrze i wyzwolenie pamięci zabójcy pamięci (OOM). Zanim jednak proces zatrzymania został zabity, spowodował opróżnienie pamięci podręcznej dysku, co powoduje, że system reaguje przez chwilę, dopóki pamięć podręczna się nie zapełni.

Możesz zmienić domyślną zasadę, aby nie zezwalać na nadmierną pamięć, zapisując wartość 2 na /proc/sys/vm/overcommit_memory. Domyślna wartość /proc/sys/vm/overcommit_ratioto 50, więc jądro nie pozwoli aplikacjom na przydzielenie więcej niż 50% ram + swap. Jeśli nie masz wymiany, jądro nie zezwoli aplikacjom na przydzielenie więcej niż 50% pamięci RAM, pozostawiając pozostałe 50% wolnej pamięci podręcznej. Może to być nieco przesadne, więc możesz zwiększyć tę wartość, powiedzmy, o 85%, aby aplikacje mogły przydzielić do 85% pamięci RAM, pozostawiając 15% na pamięć podręczną.

— psusi
źródło

1

Zmiana tych wartości z domyślnych bez teoretycznego tła nie będzie osiągana w bardziej niezawodnym systemie, można to uzasadnić tylko za pomocą odpowiednich statystyk. To, że możesz to zmienić, nie oznacza, że powinieneś. Jeśli ciągle masz mało pamięci, co oznacza, że używasz więcej pamięci niż masz i powinieneś kupić więcej pamięci, nie oznacza to, że powinieneś majstrować przy ustawieniach i zabijać przypadkowe aplikacje. Przerywanie codziennej pracy lub wprowadzanie korupcji, to naprawdę nie jest dobra droga ...

— Tamara Wijsman,

3

@TomWijsman, pytanie wyjaśnia, że nie jest on ciągle w stanie niskiej pamięci; po prostu czasami wykonuje polecenie, które zajmuje nieoczekiwanie dużą ilość pamięci. Kupowanie większej ilości pamięci nie jest jedynym rozwiązaniem, gdy skończy Ci się. Inne potencjalne rozwiązania obejmują znalezienie lepszych sposobów wykorzystania posiadanej pamięci lub po prostu nie robienie czegokolwiek, co wymaga takiej ilości pamięci. Pytanie wyjaśnia, że to drugie jest bardziej akceptowalne niż wychodzenie i kupowanie większej ilości barana.

— psusi

Który wiersz pytania wyjaśnia to? Widzę odwrotnie podane w I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Wspomniał o GUI, a ty zakładasz, że wykonuje polecenie. Kupowanie większej ilości pamięci to pierwsze rozwiązanie, a samodzielne korzystanie z mniejszej ilości pamięci to drugie rozwiązanie, powodujące niestabilność systemu przez majstrowanie przy stabilnych ustawieniach domyślnych to ostatnie rozwiązanie. Na pytanie nie trzeba odpowiadać dosłownie, więc nie rozumiem, na czym polega problem, że musicie niepokoić nas oboje w komentarzach. Rant nie pomaga ...

— Tamara Wijsman

4

Hej, ta odpowiedź brzmiała całkiem fajnie. Niestety, „zatwierdzenie” odnosi się do zapotrzebowania na pamięć wirtualną, co wydaje się dość źle oszacowane przez programistów aplikacji. Na przykład z moim (bez wymiany) z systemem stacjonarnym, istnieje około 400 2000mb pamięci fizycznej używane, ale 1600mb „commit'ted jako /proc/meminfo” s Committed_ASstanach. Przy niektórych uruchomionych aplikacjach wartość ta z łatwością przekracza pamięć fizyczną, dlatego trudno jest ustalić przez to wykonalny limit.

— dronus

3

Zapisz swoją pracę przed wypróbowaniem tego! : PI miał natychmiastowe awarie ze wszystkiego (bash, menedżer okien itp.).

— jozxyqk

8

Dla mnie ustawienie vm.admin_reserve_kbytes = 262144 robi dokładnie to samo. OOM Killer interweniuje, zanim system całkowicie przestanie odpowiadać.

— Michał Wigowski
źródło

1

Podoba mi się pomysł, ale czy to oznacza, że nigdy nie korzystałeś z 256 MB pamięci fizycznej?

— Jérôme Pouiller

1

256 MB zostanie wykorzystane do buforowania. Bufory są naprawdę ważne, nie chodzi tylko o szybsze działanie, system w ogóle nie działałby, gdyby nie było wystarczającej ilości pamięci dla buforów. Kod każdego działającego programu można wyładować z pamięci, ponieważ jest on ukształtowany i można go odczytać z dysku. Bez pamięci podręcznej każdy przełącznik zadań będzie wymagał odczytu dysku, a system całkowicie przestanie odpowiadać.

— Michael Vigovsky,

4

Inne odpowiedzi mają dobre automatyczne rozwiązania, ale uważam, że pomocne może być również włączenie SysRqklucza, gdy sprawy wymykają się spod kontroli. Za pomocą SysRqklucza możesz ręcznie wysyłać wiadomości do jądra i możesz robić takie rzeczy, jak bezpieczny restart (z SysRQ + REISUB), nawet jeśli przestrzeń użytkownika została całkowicie zamrożona.

Aby jądro kernel.sysrq = 1mogło nasłuchiwać żądań, ustaw lub włącz tylko funkcje, których prawdopodobnie będziesz używać z maską bitową ( tutaj udokumentowane ). Na przykład kernel.sysrq = 244włączy wszystkie kombinacje potrzebne do bezpiecznego ponownego uruchomienia powyżej, a także ręczne wywołanie zabójcy OOM za pomocą SysRq + F.

— timuzhti
źródło

-2

Niezawodność nie jest osiągana przy niskim poziomie pamięci i zabójcy OOM.

Błędem jest organizowanie imprezy w szafie i umieszczanie „czyszczenia mojej szafy” na małej liście odtwarzania.

Czy jest możliwe, aby zabójca OOM interweniował wcześniej?

Spowoduje to niezamierzone skutki uboczne, ponieważ nie masz kontroli nad tym, co zostanie zabite.

Staram się dostosować mój system programistyczny do maksymalnej niezawodności.

Maksymalna niezawodność polega na testowaniu systemu i ulepszaniu systemu na podstawie tych testów.

Po prostu poprawianie losowych rzeczy nigdzie cię nie doprowadzi ...

Wyłączyłem swap, ponieważ w przypadku użycia GUI powoduje to, że maszyna przestaje reagować w taki sposób, że nie jest już dłużej użyteczna. Niemniej jednak, jeśli agresywne aplikacje pochłaniają pamięć, wydaje się, że niektóre mechanizmy wykorzystują to, aby maksymalnie wykorzystać koszt szybkości.

Z powodu niskiego poziomu pamięci wyłączenie wymiany nie poprawi zachowania , robi odwrotnie .

Aby zwiększyć niezawodność w tej sytuacji, dodaj więcej pamięci, aby system był bardziej responsywny i nie było zabijania przypadkowych procesów bez intencji użytkownika. Nie powinieneś uciekać się do warunków niskiej pamięci i takiego mechanizmu, szczególnie nie w środowisku programistycznym ...

Nie ma operacji wymiany dysku twardego, ale system również przestaje reagować.

Niskie warunki pamięci rzeczywiście powodują brak reakcji, niezależnie od tego, czy masz zamianę, czy nie.

Chcę więc pozwolić, aby zabójca OOM uruchomił się, zanim system podejmie jakiekolwiek specjalne wysiłki w celu zwiększenia pamięci.

Specjalne wysiłki, które przyniosą więcej szkody niż pożytku, jak wyjaśniłem powyżej. Zamiast tego możesz zabijać procesy, których sam nie potrzebujesz, ale myślę, że nie możesz tego zrobić, więc OOM zabije procesy, których potrzebujesz.

Czy można skonfigurować zabójcę OOM do działania, jeśli na przykład jest mniej niż 100 MB wolnej pamięci fizycznej?

Być może, ale zyskujesz wyższy zwrot z inwestycji, jeśli kupisz dodatkową pamięć, która w dzisiejszych czasach nie kosztuje dużo. Zastanów się, czy na dłuższą metę uderzysz się w stopę, jeśli będziesz kontynuować pracę w warunkach niskiej pamięci. OOM jest jak komornik, nie pomaga, pomaga OS ...

— Tamara Wijsman
źródło

7

Oczywiście wyłączenie swap poprawia zachowanie, ponieważ zamiast zgniatania dysku OOM uruchamia się i zabija wieprz pamięci. Skończył się RAM, nie jest problemem (a dodanie więcej oznacza, że musisz bardziej się starać, aby skończyć się). Problem polega na tym, co zrobić, gdy skończą ci się. Chcesz, aby OOM zabił wieprz, a tym samym złagodził stan niskiej pamięci.

— psusi

7

Ponieważ zabijanie aplikacji, która próbuje zużywać więcej pamięci niż masz, jest lepsze niż rzucenie całego systemu na kolana. W idealnym świecie miałbyś nieograniczoną pamięć i nigdy się nie zabrakło, ale w rzeczywistości czasami zabrakło ci przypadkiem i wolałbyś powiedzieć „za mało pamięci” niż zatrzymać system.

— psusi

5

Zakup dodatkowej pamięci może rozwiązać niektóre problemy, w zależności od zakupionej kwoty. Ale to nie zmienia faktu, że mogą być nieoczekiwane zastosowania według rzędów wielkości. Dlatego chcę, aby aplikacja uległa awarii, ale NIE system w tych warunkach. Kilka przykładów: Przetwórz folder pełen skompresowanych obrazów, większość z nich „normalnych”, ale niektóre naprawdę duże. Mały błąd może spowodować martwą pętlę z niekontrolowaną pamięcią, jedzącą 1 GB / s. Przypadkowo otwórz plik wideo w edytorze tekstu. Zwykle kończy się to takimi objawami, jak szarpana mysz i prawie martwy interfejs użytkownika, dopóki nie

— pojawi się

6

@TomWijsman istnieją również prawie martwe pętle, ponieważ istnieją algorytmy, które zachowują się liniowo w przypadku średniej, ale w najgorszym przypadku mają charakter wykładniczy, w zależności od danych wejściowych. I nie mogę wysłać sygnału zabicia, jeśli mysz jest szarpana, a kliknięcia, a także wejście klawiatury pokazuje jednominutowe opóźnienie. Zazwyczaj przechodzę wtedy do trybu tekstowego i czekam kilka minut, aż logowanie się rozpocznie, by wydać killślepo wpisany tekst .

— dronus

7

Nie mam też problemów z zabijaniem aplikacji, które działałyby martwe. Rozważ system z 2 GB wymiany fizycznej + 2 GB wymiany. Aplikacja, która szybko wyczerpuje pamięć fizyczną, może z łatwością zjeść swap. Po prostu umrze później, po tym, jak system przestanie odpowiadać na minuty lub godziny. Dlaczego więc nie zabić go szybko, zanim operacja GUI stanie się niestabilna? Wiele procesów wykonuje całą swoją pracę z 10 MB, niektóre wymagają 1 GB, a niektóre rzadkie wymagają 10 GB, to jest życie.

— dronus