System zawiesza się, gdy zabraknie pamięci

34

Mam eeePC 900a: ma 8 GB pamięci flash jako dysk i tylko 1 GB pamięci RAM. Zainstalowana na nim dystrybucja Linuksa to ArchLinux.

Kiedy systemowi zabraknie pamięci, staje się on wyjątkowo niereagujący: zajmuje kilka sekund / minut, aby wykonać takie czynności, jak przejście do TTY1 lub nawet przesunięcie wskaźnika myszy. Czasami wygląda na to, że system się zawiesza: trzy nasze dawno temu zostawiłem go w spokoju i jak dotąd nic się nie zmieniło.

Wolałbym unikać tworzenia partycji / pliku wymiany na tym eeePC, ponieważ dysk jest już tak mały, a także dlatego, że wiele zapisów na przestrzeni wymiany znacznie skróciłoby żywotność karty flash. Co więcej, myślę, że plik / partycja wymiany po prostu przeniósłby problem, zamiast zdecydowanie go naprawić.

Czy jądro nie powinno zabijać losowych aplikacji, gdy zabraknie pamięci? Dlaczego to się nie udaje (lub zajmuje wieki)?

Kilka miesięcy / lat temu próbowałem już przyjrzeć się temu, ale nie mogłem znaleźć niczego, co faktycznie działałoby ...

linux memory freeze

— peoro
źródło

1

Jakich DE / WM używasz w konfiguracji, jakich usług / demonów używasz? Korzystanie z pełnego środowiska pulpitu i przeglądanie na przykład w Chromium lub Firefox zjada pamięć RAM na brunch. 1 GB pamięci RAM powinno wystarczyć do uruchomienia samego Arch Linuxa, ale tak naprawdę liczy się to, co na nim umieścisz.

1

Używam LXDE. Chrom to program, który zwykle zajmuje większość pamięci RAM. W każdym razie nie o to chodzi. To nie ja muszę dbać o ilość pamięci używanej przez mój system, to mój system nie powinien umrzeć z tego powodu. Jeśli w moim systemie zaczyna brakować pamięci, można dowolnie zabijać dowolną aplikację, chcę tylko, żeby się nie zawieszała !

— peoro

6

To znaczy, jestem poważnie myśli o prowadzeniu takiego skryptu (w Pseudokod) while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. To zdecydowanie rozwiązałoby mój problem. Ale czekaj, czy jądro nie powinno tego robić (i to w znacznie lepszy sposób niż mój skrypt)? Dlaczego nie spełnia swojej roli?

— peoro

2

@Marcin, który tylko przesunąłby problem, nie naprawi go. Nawet gdybym miał 4 GB pamięci (dzięki pewnej zamianie), w moim systemie mogło zabraknąć pamięci (a więc zawiesić się). To, czego chcę uniknąć, to zawieszanie się systemu, gdy brakuje pamięci RAM. Gdyby moje jądro nagle zabiło chrom, gdy tylko skończy się pamięć RAM, byłbym szczęśliwy nawet z 1 GB, który mam teraz.

— peoro

4

@Lee „Magic sysrq” to kombinacja klawiszy, która przechodzi bezpośrednio do jądra. To często działa, nawet jeśli klawiatura i mysz nie reagują. Zobacz en.wikipedia.org/wiki/Magic_SysRq_key

— Raman

14

Możliwe jest wywoływanie OOM-Killera (poza pamięcią) bezpośrednio przez kombinację klawiszy:

SysRq-F

Klawisz SysRq jest zwykle łączony z klawiszem PrtSc na klawiaturze.

OOM-killer zabija niektóre procesy (-es) i system ponownie reaguje.

Dzięki Raman za porady na temat tej funkcji w komentarzach powyżej.

PS: To mi bardzo pomogło. Zgadzam się z opinią, że jest to najbardziej przydatna porada na temat tego problemu, jeśli jest spowodowany przez Chrome lub inne chciwe oprogramowanie pamięci. Ale musisz pamiętać, że zabójca OOM może zabić jakiś naprawdę ważny proces, używaj go ostrożnie.

— Arkemlar
źródło

2

Mam klucz PrtScn|SysRq. Ale naciśnięcie SysRq - Fpowoduje tylko zrzut ekranu

— Lee

2

Ponieważ w zasadzie wziąłeś mój komentarz powyżej i udzieliłeś odpowiedzi, małe uznanie byłoby przyjemne. I tak cię głosowałem. :-)

— Raman

3

@Lee Musisz to włączyć. Niektóre dystrybucje nie mają domyślnie włączonej funkcji magicznego sysrq. To powinno pomóc: google.ca/search?q=sysrq+enable

— Raman

2

@Raman Założę się, że 99%, którzy stwierdzą, że nie może „włączyć” domyślnie, ponieważ ich komputer jest już zamrożony ... dlaczego nie jest domyślnie włączony?

— themihai

3

@ thehehai, ponieważ wiele osób uważa to za zagrożenie dla bezpieczeństwa - daje bezpośredni dostęp do jądra poprzez fizyczny dostęp do urządzenia wejściowego, niezależnie od stanu aplikacji, np. blokad ekranów i tym podobnych.

— Raman

12

Naturalnym stanem rzeczy jest to, że dane aplikacji znajdują się w pamięci RAM, a pliki są na dysku.
Idealnym stanem, pod względem wydajności, jest to, że często używane dane znajdują się w pamięci RAM, a dane, które w tej chwili nie są potrzebne, znajdują się na dysku.
W normalnym systemie jądro robi dwie rzeczy, aby osiągnąć ten ideał:

Dane aplikacji, które nie były używane przez jakiś czas, można przenieść na dysk: jest to zamiana.
Dane z ostatnio używanych plików są przechowywane w pamięci RAM: jest to pamięć podręczna dysku (dane odczytywane z dysku) i bufory dysku (dane, które mają zostać zapisane na dysk).

W typowym systemie znaczna część pamięci RAM jest przeznaczona na pamięć podręczną i bufory (50% to typowa liczba). Ponieważ pamięć RAM jest zasobem skończonym, może to wymagać przesunięcia niektórych danych aplikacji do wymiany (zamiana jest konieczna tylko wtedy, gdy istnieje lepszy sposób korzystania z pamięci RAM).

W systemie bez zamiany jest taki moment, że dane aplikacji używają prawie całej pamięci RAM, więc nie ma już prawie miejsca na pamięć podręczną. Wtedy system będzie prawdopodobnie wolny. Jądro nie zacznie zabijać aplikacji, dopóki nie będzie musiało. Tak długo, jak aplikacje wypełniają tylko 99% dostępnej pamięci, system działa, ale bardzo powoli, ponieważ dane plików muszą być ładowane i ponownie ładowane z dysku przez cały czas. Przy tych samych aplikacjach system byłby szybszy z wymianą w tym momencie.

Aby uzyskać więcej informacji na ten temat, zobacz dyskusję lkml i ten post na blogu .

Nie znam bezpośredniego sposobu poinformowania jądra o zarezerwowaniu minimalnej ilości pamięci RAM na pamięć podręczną dysku. Możesz ustawić małą część pamięci RAM jako przestrzeń wymiany , być może nawet skompresowaną . Istnieją doniesienia o sukcesie na tym froncie , ale nie udzielam żadnych gwarancji w konkretnym przypadku.

— Gilles „SO- przestań być zły”
źródło

1

Dzięki za wyjaśnienia i linki pomogli wyjaśnić wątpliwości dotyczące wymiany. po odpowiedzi @Marcin na moje pytanie, skonfigurowałem 256 MB skompresowanej wirtualnej wymiany (compcache) w mojej pamięci RAM. To jednak nie w pełni odpowiada na moje pytanie: Rozumiem, że mój system będzie działał wolno, gdy cała pamięć RAM będzie używana tylko przez aplikację i nic nie będzie buforowane; Nadal nie rozumiem, dlaczego ten system zawiesza się przez kilka minut / godzin (może na zawsze?), Kiedy całkowicie brakuje mi pamięci RAM. Myślę, że moje jądro nie wykonuje zadań polegających na zabijaniu aplikacji, gdy brakuje pamięci, jeśli 3 godziny nie wystarczą, aby przejść na TTY1.

— peoro

Zamiana została wyłączona z 32 GB pamięci fizycznej, a gdy złe oprogramowanie ucieka z alokacją pamięci (witaj ld, śmieciu), nadal zawiesza się przez prawie minutę, budząc się na tyle, że mogę na chwilę poruszyć niesamowicie opóźnioną myszą lub dwa co kilka sekund. Obsługa OOM w Linuksie to bzdura. Jeśli mam szczęście, zabójca OOM zabija właściwy proces, nie psując całkowicie środowiska pulpitu. Jestem wielkim fanem Linuksa. Jest znacznie gorzej z włączonym stronicowaniem. Stronicowanie Linuksa to żart.

— doug65536

6

Jest to znany błąd od 2007 r. - zobacz Zatrzymywanie systemu w przypadku dużego zużycia pamięci .

W tej sytuacji system Windows wyświetla okno dialogowe ostrzegające użytkownika o zamknięciu jednej lub więcej aplikacji.

— Dan Dascalescu
źródło

2

W Ubuntu wydaje się być „nieprzypisany”. Być może DE powinien ostrzec użytkownika, a nawet zawiesić aplikację wymagającą dużej ilości pamięci?

— nkkollaw

1

@nbrogi - nic poza cichym zamrożeniem. Ale powodzenia przekonanie twórców Ubuntu do zrobienia tego.

— Dan Dascalescu

6

Ostatnio znalazłem rozwiązanie mojego problemu.

Ponieważ Linux OOM Killer nie jest w stanie poprawnie wykonywać swojej pracy, zacząłem używać OOM Killer w przestrzeni użytkownika: wcześnie . Jest napisany w C, dość konfigurowalny i działa jak urok dla mnie.

Słyszałem również o niektórych alternatywach, takich jak OOMD Facebooka , opracowanych do działania na ich serwerach, ale nie próbowałem tego

— peoro
źródło