Jak oswoić responsywność, pamięć i stronicowanie Linuksa

Pierwsze pytanie o przepełnienie =) ... +100 nagród. Nie mogłem wymyślić czegoś, na czym naprawdę mi zależało:

Naprawdę mam dość responsywności pulpitu Linuksa, np. Http://brainstorm.ubuntu.com/item/85/ - w sytuacjach z małą ilością wolnej pamięci RAM lub z dużą przepustowością dysku system zwalnia przeszukiwania ; jest to absolutnie straszne w przypadku aplikacji wymagających przyzwoitej wydajności. Ponadto interfejs użytkownika całkowicie nie odpowiada. Porównaj to na przykład z OS X, w którym jeśli aplikacja przejmuje zasoby, zawsze można kliknąć opcję, aby wymusić jej zamknięcie, podczas gdy w systemie Linux nie mogę nawet Alt-Tab ani przełączać pulpitu, ani nawet Ctrl-Alt-F1, aby uzyskać terminal - cóż, mogę, zajmuje to około 1-2 minut na operację.

Korzystam z gkrellm, dzięki czemu widzę, jak się rozwija. Zazwyczaj wykorzystanie pamięci staje się dość wysokie lub przepustowość dysku gwałtownie wzrasta.

Nie jest to zły sprzęt, z czterordzeniowym 2,6 GHz i 4 GB pamięci RAM DDR2 800 MHz (miałby 6 GB, ale z powodu niezgodności sprzętowej nie mógł się łączyć ze starym zestawem). Ten problem może zniknąć, gdy nieuchronnie dostanę więcej pamięci RAM, ale nie sądzę, że to jest sedno problemu. Mam nawet dwie partycje wymiany na różnych dyskach.

Wydaje mi się, że problem jest trojaki:

• niekontrolowane programy, które pochłaniają ogromne ilości pamięci - należy ustanowić prawo dla tych programów, z ich ograniczeniami
  • (np. karty w Chrome, z których każda ma 20-50 MB, z których niektóre mogą używać setek MB)
  • (np. inne programy, takie jak update-db i indeksatory, które musiałem wyłączyć i usunąć z crona, ponieważ spowalniały system do indeksowania przy każdym uruchomieniu itp.)
• coś okropnego dzieje się w sporze o jądro lub magistralę, na przykład sytuacje o wysokiej przepustowości dysku spowalniają cały system do przeszukiwania (być może poprzez wywoływanie ważnych programów)
• jądro nie traktuje priorytetowo interfejsu użytkownika ani ważnych programów pod względem zasobów, takich jak pamięć, stronicowanie, a nawet wykorzystanie procesora

Komentarze przychodzą do:

Dlatego szukam rozwiązania, w którym wszystkie takie programy znikną. W szczególności szukam rozwiązania, w którym procesy będą proporcjonalnie spowalniać, podczas gdy system i inne programy pozostają całkowicie nienaruszone i reagują wystarczająco długo, aby ręcznie zabić coś. Również proces menedżera okien (i wszystko inne, co może mieć wpływ na responsywność interfejsu użytkownika) powinien być responsywny w każdych okolicznościach.

W szczególności intryguje mnie /etc/security/limits.conf( man limits.conf), ale martwię się, że daje to kontrolę tylko nad użytkownikiem, a komentowane przykłady w pliku wydają się raczej niejasne pod względem opisu lub od czego zacząć. Mam nadzieję, że limits.confzadziała, ale nie zdziwiłbym się, gdyby nawet nie zadziałał, lub nie byłby odpowiednim rozwiązaniem dla mojego problemu lub byłby tak szczegółowy, jak próbuję osiągnąć. Nazwa na proces limits.confbyłaby idealna, zakładając, że działa limit.conf. Z przyjemnością wypróbuję limit.conf, który ludzie dostarczają, aby sprawdzić, czy to działa, chociaż jestem otwarty na wszystkie rozwiązania w tym momencie.

Przydatne może być również posiadanie wglądu w to, jak OS X zarządza tak dobrą reakcją interfejsu użytkownika.

Poprawiłem już moje /tmpfoldery i pamięć podręczną, aby były włączone tmpfs, i ogólnie użycie dysku jest prawie zerowe.

Tematy niejasno powiązane:

• nadmierna pamięć

Odpowiedzi, które moim zdaniem nie będą działać:

• swapoff (wciąż pozwala to programom wymykającym się pamięci uniknąć morderstwa, a system permanentnie zawiesza się, jeśli pamięć jest naprawdę zła - głosuje na głos każdego, kto może zasugerować ulepszenie, które wywołało zabójcę OOM wcześniej przed zamianą i atakuje określone programy)
• echo ?? > /sys/.../swappiness (brak dostrzegalnego efektu)
• nice (nigdy nie działał)
• ionice (nigdy nie zauważyłem różnicy)
• selinux (niezgodność programu wydaje się koszmarem)
• Linux w czasie rzeczywistym, tj. może przerwać jądro (nie chcę zajmować się kompilacją i aktualizacją niestandardowego jądra; może być w porządku, jeśli migrował do repozytoriów)
*

Wygląda na to, że Twój system ulega ciężkiej zamianie. Używanie vmstat 1może ujawnić pewne szczegóły - po prostu pozwól mu działać w oknie terminala i przełącz się na niego, gdy zacznie się spowolnienie.

Zamiast umieszczać / tmp i „cache” w tmpfs, użyłbym normalnego systemu plików na dysku zamontowanego z tą noatimeopcją. Często używane dane i tak pozostaną w pamięci podręcznej, a starsze dane można zapisać na dysku, aby zwolnić pamięć RAM dla aplikacji. Jeśli / tmp i / lub cache rosną, może to bardzo pomóc.

Nie jestem programistą jądra, ale spędziłem lata na filozofowaniu tego problemu, ponieważ wiele razy wpadłem na to. Właściwie wymyśliłem metaforę dla całej sytuacji, więc powiem ci to. Zakładam w mojej historii, że rzeczy takie jak „zamiana” nie istnieją. W dzisiejszych czasach zamiana nie ma większego sensu z 32 GB pamięci RAM.

Wyobraź sobie swoją okolicę, w której woda jest podłączona do każdego budynku za pomocą rur, a miasta muszą zarządzać wydajnością. Załóżmy, że produkujesz tylko 100 jednostek wody na sekundę (a cała niewykorzystana pojemność marnuje się, ponieważ nie masz zbiorników zbiornikowych). Każdy dom (dom = mała aplikacja, terminal, widget zegara itp.) Wymaga jednej 1 jednostki wody na sekundę. To wszystko jest miłe i dobre, ponieważ twoja populacja wynosi 90, więc każdy dostaje wystarczającą ilość wody.

Teraz burmistrz (= ty) decyduje, że chcesz otworzyć dużą restaurację (= przeglądarkę). Ta restauracja pomieści wielu kucharzy (= karty przeglądarki). Każdy kucharz potrzebuje 1 jednostki wody na sekundę. Zaczynasz od 10 kucharzy, więc całkowite zużycie wody w całym sąsiedztwie wynosi 100 jednostek wody, co wciąż jest dobre.

Teraz zaczyna się zabawa: zatrudniasz innego kucharza w swojej restauracji, co daje całkowite zapotrzebowanie na wodę 101, czego oczywiście nie masz. Musisz coś zrobić.

Zarządzanie wodą (= jądro) ma 3 opcje.

1. Pierwsza opcja to po prostu odłączyć usługę dla domów, które ostatnio nie korzystały z wody. Jest to w porządku, ale jeśli odłączony dom chce ponownie skorzystać z wody, będzie musiał ponownie przejść długą procedurę rejestracji. Kierownictwo może odłączyć wiele domów, aby zwolnić więcej zasobów wodnych. W rzeczywistości rozłączą wszystkie domy, które ostatnio nie używały wody, dzięki czemu zawsze będzie dostępna pewna ilość darmowej wody.

Chociaż twoje miasto nadal funkcjonuje, wadą jest to, że postęp zatrzymuje się. Większość czasu spędzasz na oczekiwaniu na zarządzanie zasobami wodnymi w celu przywrócenia usługi.

To właśnie robi jądro ze stronami z kopiami plików. Jeśli uruchomisz duży plik wykonywalny (np. Chrome), jego plik zostanie skopiowany do pamięci. Gdy zabraknie pamięci lub jeśli są części, do których ostatnio nie uzyskano dostępu, jądro może je upuścić, ponieważ i tak może je ponownie załadować z dysku. Jeśli zostanie to zrobione nadmiernie, spowoduje to zatrzymanie pulpitu, ponieważ wszystko będzie tylko czekało na We / Wy dysku. Zauważ, że jądro upuści również wiele ostatnio używanych stron, kiedy zaczniesz robić dużo IO. Dlatego po skopiowaniu kilku dużych plików, takich jak obrazy DVD, potrzeba wielu lat, aby przejść do aplikacji działającej w tle.

Jest to dla mnie najbardziej denerwujące zachowanie, ponieważ nienawidzę czkawek i nie masz nad tym kontroli. Byłoby miło móc to wyłączyć. Myślę o czymś podobnym do

sed -i 's/may_unmap = 1/may_unmap = (vm_swappiness >= 0)/' mm/vmscan.c

a następnie możesz ustawić vm_swappiness na -1, aby to wyłączyć. To działało całkiem dobrze w moich małych testach, ale niestety nie jestem programistą jądra, więc nie wysłałem go nikomu (i oczywiście powyższa mała modyfikacja nie jest kompletna).

2)Kierownictwo mogłoby odrzucić prośbę nowego kucharza o wodę. To początkowo brzmi jak dobry pomysł. Istnieją jednak dwie wady. Po pierwsze, są firmy, które wymagają dużej ilości abonamentów wodnych, nawet jeśli ich nie używają. Jednym z możliwych powodów jest uniknięcie narzutów związanych z zarządzaniem zasobami wodnymi, ilekroć potrzebują dodatkowej wody. Zużycie wody rośnie i maleje w zależności od pory dnia. Np. W przypadku restauracji firma potrzebuje znacznie więcej wody w południe w porównaniu do północy. Żądają więc wszelkiej możliwej wody, której mogą użyć, ale marnuje przydziały wody o północy. Problem polega na tym, że nie wszystkie firmy mogą prawidłowo przewidzieć szczytowe zużycie, dlatego żądają znacznie więcej w nadziei, że nigdy nie będą musiały się martwić o dodatkowe.

Oto, co robi maszyna wirtualna Java: przy uruchamianiu przydziela dużą ilość pamięci, a następnie działa z tego. Domyślnie jądro przydziela pamięć tylko wtedy, gdy aplikacja Java faktycznie zacznie z niej korzystać. Jeśli jednak wyłączysz opcję overcommit, jądro potraktuje rezerwację poważnie. Pozwoli to na pomyślne zakończenie alokacji, jeśli faktycznie ma na to odpowiednie zasoby.

Istnieje jednak jeszcze jeden poważniejszy problem z tym podejściem. Powiedzmy, że jedna firma zaczyna żądać jednej jednostki wody każdego dnia (zamiast w krokach co 10). W końcu osiągniesz stan, w którym masz 0 wolnych jednostek. Teraz ta firma nie będzie mogła przydzielić więcej. W porządku, i tak zależy na dużych firmach. Problem polega jednak na tym, że małe domy również nie będą mogły poprosić o więcej wody! Nie będziesz w stanie zbudować małych publicznych łazienek, aby poradzić sobie z nagłym napływem turystów. W pobliskim lesie nie będzie można zapewnić awaryjnej wody do pożaru.

W kategoriach komputerowych: W sytuacjach bardzo niskiej pamięci bez nadmiernego zaangażowania nie będziesz mógł otworzyć nowego Xtermu, nie będziesz mógł ssh na swoim komputerze, nie będziesz mógł otworzyć nowej karty, aby wyszukać możliwe poprawki Innymi słowy, wyłączenie overcommit powoduje, że pulpit jest bezużyteczny, gdy brakuje mu pamięci.

3. Oto ciekawy sposób rozwiązania problemu, gdy firma zaczyna zużywać zbyt dużo wody. Gospodarka wodna wysadza to w powietrze! Dosłownie: trafia na stronę restauracji, wrzuca do niej dynamity i czeka, aż wybuchnie. Spowoduje to natychmiastowe zmniejszenie zapotrzebowania miasta na wodę, dzięki czemu nowi ludzie będą mogli się wprowadzać, tworzyć publiczne łazienki itp. Ty, jako burmistrz, możesz odbudować restaurację w nadziei, że tym razem zużyje mniej wody. Na przykład powiesz ludziom, aby nie chodzili do restauracji, jeśli w środku jest już zbyt wiele osób (np. Otworzysz mniej kart przeglądarki).

To właśnie robi jądro, gdy zabraknie mu wszystkich opcji i potrzebuje pamięci: wywołuje zabójcę OOM. Wybiera dużą aplikację (opartą na wielu heurystykach) i zabija ją, zwalniając sporo pamięci, ale utrzymując responsywny pulpit. W rzeczywistości jądro Androida robi to jeszcze bardziej agresywnie: zabija ostatnio używaną aplikację, gdy pamięć jest niska (w porównaniu do podstawowego jądra, które robi to tylko w ostateczności). Nazywa się to Viking Killer w Androidzie.

Myślę, że jest to jedno z najprostszych rozwiązań problemu: to nie tak, że masz więcej opcji niż to, więc dlaczego nie przejść przez to wcześniej niż później, prawda? Problem polega na tym, że jądro czasami wykonuje sporo pracy, aby uniknąć wywoływania zabójcy OOM. Właśnie dlatego widzisz, że twój pulpit jest bardzo wolny i jądro nic z tym nie robi. Ale na szczęście istnieje możliwość samodzielnego wywołania zabójcy OOM! Najpierw upewnij się, że magiczny klawisz sysrq jest włączony (np. echo 1 | sudo tee /proc/sys/kernel/sysrq), A następnie za każdym razem, gdy czujesz, że w jądrze zaczyna brakować pamięci, po prostu naciśnij Alt + SysRQ, Alt + f.

OK, więc to wszystko jest miłe, ale chcesz to wypróbować? Niski poziom pamięci jest bardzo prosty do odtworzenia. Mam do tego bardzo prostą aplikację. Będziesz musiał uruchomić go dwa razy. Pierwsze uruchomienie określi, ile masz wolnej pamięci RAM, drugie uruchomienie spowoduje powstanie niskiej ilości pamięci. Zauważ, że ta metoda zakłada, że ​​masz zamianę wyłączoną (np. Wykonaj a sudo swapoff -a). Kod i sposób użycia są następujące:

// gcc -std=c99 -Wall -Wextra -Werror -g -o eatmem eatmem.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main(int argc, char** argv)
{
    int limit = 123456789;
    if (argc >= 2) {
        limit = atoi(argv[1]);
    }
    setbuf(stdout, NULL);
    for (int i = 1; i <= limit; i++) {
        memset(malloc(1 << 20), 1, 1 << 20);
        printf("\rAllocated %5d MiB.", i);
    }
    sleep(10000);
    return 0;
}

A oto jak go wykorzystujesz:

$ gcc -std=c99 -Wall -Wextra -Werror -g -o eatmem eatmem.c
$ ./eatmem
Allocated 31118 MiB.Killed
$ ./eatmem 31110
Allocated 31110 MiB.Killed

Pierwsze wywołanie wykryło, że mamy 31 118 MB wolnej pamięci RAM. Powiedziałem więc aplikacji, aby przydzieliła 31 110 MiB RAM, aby jądro jej nie zabiło, ale pochłonęło prawie całą moją pamięć. Mój system zamarł: nawet wskaźnik myszy nie drgnął. Nacisnąłem Alt + SysRQ, Alt + f i to zabiło mój proces jedzenia i system został przywrócony.

Mimo że omawialiśmy nasze opcje, co robimy w sytuacji braku pamięci, najlepszym podejściem (podobnie jak w każdej innej niebezpiecznej sytuacji) jest unikanie tego w pierwszej kolejności. Istnieje wiele sposobów, aby to zrobić. Jednym z powszechnych sposobów, w jaki widziałem, jest umieszczanie źle działających aplikacji (takich jak przeglądarki) w innych kontenerach niż reszta systemu. W takim przypadku przeglądarka nie będzie miała wpływu na pulpit. Ale sama prewencja nie wchodzi w zakres pytania, więc nie będę o tym pisać.

TL; DR: Chociaż obecnie nie ma możliwości pełnego uniknięcia stronicowania, można ograniczyć całkowite zatrzymanie systemu, wyłączając funkcję overcommit. Ale twój system będzie nadal bezużyteczny w sytuacji niskiego poziomu pamięci, ale w inny sposób. Niezależnie od powyższego, w sytuacji braku pamięci naciśnij Alt + SysRQ, Alt + f, aby zabić duży proces wybrany przez jądro. Twój system powinien przywrócić swoją responsywność po kilku sekundach. Zakłada się, że magiczny klucz sysrq jest włączony (domyślnie nie jest).

Umieszczenie wszystkich plików tymczasowych i pamięci podręcznej na dysku tmpfszmniejsza ilość dostępnej pamięci RAM, więc może to powodować, że system zacznie zamieniać się szybciej niż byłoby to konieczne bez tego.

Wygląda na to, że masz aplikacje, które korzystają z jakiegoś narzędzia jądra lub sterownika, który jest przeciążony. Nie wchodzisz w szczegółowe informacje na temat rodzajów aplikacji innych niż używasz przeglądarek i indeksatorów oraz że wyłączyłeś indeksatory.

Możesz spróbować przejść do środowiska pulpitu lub menedżera okien, który zużywa mniej zasobów, takich jak LXDE lub IceWM. W pracy używam systemu Linux z zainstalowanym LXDE i ROX-Filer dla bardzo minimalnego środowiska pulpitu. Celem tego systemu Linux jest uruchomienie VMWare Player, dzięki czemu mogę jednocześnie uruchomić system Windows XP i Windows 7. Jest to specyfikacja sprzętu podobna do tego, co mówisz i nie mam zbyt wielu problemów z reakcją pod tym dużym obciążeniem, przez które narażam sprzęt. Nie mam żadnych problemów z responsywnością z samym Linuksem (zazwyczaj maszyny wirtualne czasami zmuszają mnie do oczekiwania i dzielenie 1 dysku między 2 maszynami wirtualnymi + 1 system operacyjny jest oczekiwany) i zawsze byłem w stanie zawiesić lub zamknąć maszyny wirtualne za każdym razem Chcę.

Dla mnie wskazuje to na jakiś problem z konkretnymi aplikacjami, które uruchamiasz.

Czy obsługa dysków DMA jest włączona? (use hdparm) Jeśli używasz szyfrowania całego dysku, wymaga to całego ruchu dysku, aby przejść przez procesor, co neguje większość korzyści DMA. Skutkiem tego byłby duży ruch na dysku powodujący skok CPU, co spowolniłoby cały system. (EDYCJA: aby wyjaśnić, wyłączenie DMA LUB użycie dm-cryptspowoduje wysoki procesor podczas dużego ruchu na dysku)

Jest to częsty problem z harmonogramem Linuksa. System zwalnia do pełzania za każdym razem, gdy występują ciężkie działania IO. Naprawdę niewiele jest rzeczy, które możesz zrobić, aby poprawić sytuację, chyba że jesteś włamany do jądra :)

Może te mogą pomóc:

http://www.phoronix.com/scan.php?page=article&item=linux_2637_video&num=1

http://www.osnews.com/story/24223/Alternative_to_the_200_Lines_Kernel_Patch_that_Does_Wonders_

Chociaż pytanie ma ponad dwa lata i odpowiedź @ ypsu jest świetna, sytuacja z systemami Linux ulegającymi pogorszeniu z powodu braku pamięci RAM jest nadal obecna.

Oto moja obserwacja problemu: nawet jeśli w ogóle nie mam zamiany, gdy w systemie zabraknie pamięci, wskaźnik dysku twardego zaświeci się, ponieważ jest w 100% obciążony. Biorąc pod uwagę ten fakt, wydaje się, że główną przyczyną jest to, że jądro próbuje zwolnić pamięć, uwalniając coś, co można przywrócić z dysku, a na pewno są to biblioteki współdzielone. Ponieważ aplikacje GUI mają zwykle mnóstwo bibliotek współdzielonych, wydaje się, że system może pomyśleć, że wystarczy po prostu zwolnić niektóre z nich, ale działa to tylko do następnej operacji przestrzeni użytkownika, która wymaga ponownego zwolnienia bibliotek. Wydaje się, że jest to najbardziej prawdopodobny scenariusz powodujący niekończącą się pętlę rozładowywania bibliotek współdzielonych i ładowania ich z powrotem.

Istnieje projekt, który działa jak demon przestrzeni użytkownika, zabijając najbardziej wymagające pamięci, zanim będzie za późno: https://github.com/rfjakob/earlyoom

Ponadto używałem pojemników Docker z rozsądnymi limitami pamięci dla aplikacji wymagających dużej ilości pamięci (np. Chrome).