Jak otestovat Oom-killer z příkazového řádku?

OOM Killer nebo Nedostatek paměti Killer je proces, který
linux jádro využívá, když má systém kriticky málo paměti. … To maximalizuje využití systémové paměti tím, že zajišťuje, že
paměť, která je přidělena procesům, je aktivně využívána.

Tato otázka s vlastní odpovědí zní:

• Jak otestovat oom-killer z příkazového řádku?

Byla by přijata rychlejší metoda než 1/2 hodiny, kterou zabere vlastní odpověď.

Přijatá odpověď:

Klíčem k rychlému spuštění OOM zabijáka je vyhnout se uvíznutí přístupy na disk. Takže:

1. Vyhněte se swapování, pokud není vaším cílem konkrétně otestovat chování OOM při použití swapu. Swap můžete před testem zakázat a poté jej znovu povolit. swapon -s vám řekne, jaké swapy jsou aktuálně povoleny. sudo swapoff -a deaktivuje všechny swapy; sudo swapon -a obvykle stačí k jejich opětovné aktivaci.

2. Vyhněte se prolínání přístupů k paměti s přístupy bez výměnného disku. Tato metoda založená na globbingu nakonec spotřebuje vaši dostupnou paměť (vzhledem k dostatečnému počtu záznamů ve vašem souborovém systému), ale důvod, proč potřebuje tolik paměti, je ukládání informací, které získá přístupem k vašemu souborovému systému. I u SSD je pravděpodobné, že většinu času strávíte čtením z disku, i když je swap vypnutý. Pokud je vaším cílem konkrétně testovat chování OOM pro přístupy do paměti, které jsou proloženy přístupy na disk, je tato metoda rozumná, možná dokonce ideální. Jinak můžete dosáhnout svého cíle mnohem rychleji.

Jakmile deaktivujete swap, jakákoli metoda, která zřídka čte z fyzického disku, by měla být poměrně rychlá. To zahrnuje tail /dev/zero (nalezl falstaff, výše komentoval Doug Smythies). Ačkoli čte ze znakového zařízení /dev/zero , toto „zařízení“ pouze generuje nulové bajty (tj. bajty všech nul) a nezahrnuje žádný fyzický přístup k disku, jakmile je uzel zařízení otevřen. Tato metoda funguje, protože tail hledá ve svém vstupu koncové řádky, ale proud nul neobsahuje žádný znak nového řádku, takže nikdy nedostane žádné řádky k vyřazení.

Pokud hledáte jednotný řádek v interpretovaném jazyce, který alokuje a naplňuje paměť algoritmicky, máte štěstí. Téměř v jakémkoli obecně interpretovaném jazyce je snadné alokovat spoustu paměti a zapisovat do ní, aniž byste ji jinak používali. Zde je jednořádkový perl, který se zdá být rychlý jako tail /dev/zero (ačkoli jsem to příliš netestoval):

perl -wE 'my @xs; for (1..2**20) { push @xs, q{a} x 2**20 }; say scalar @xs;'

S vypnutým swapem na starém počítači se 4 GiB RAM, obojí a tail /dev/zero trvalo asi deset sekund pokaždé, když jsem je spustil. Obojí by mělo stále fungovat na novějších počítačích s mnohem větší RAM než to. Můžete vytvořit ten perl příkaz mnohem kratší, pokud je vaším cílem stručnost.

Ten Perl one-liner opakovaně generuje (q{a} x 2**20 ) oddělte středně dlouhé řetězce – každý asi milion znaků – a uchováte je všude kolem tím, že je uložíte do pole (@xs ). Čísla pro testování můžete upravit. Pokud nevyužijete veškerou dostupnou paměť, jednořádkový výstup vypíše celkový počet vytvořených řetězců. Za předpokladu, že zabiják OOM zabije perl – s přesným příkazem uvedeným výše a bez kvót zdrojů, které by překážely, věřím, že v praxi to bude vždy – pak by vám měl váš shell ukázat Killed . Poté, jako v každé situaci OOM, dmesg má podrobnosti.

Související:Co by mělo být na kontrolním seznamu DVT (Design Verification Test)?

Ačkoli se mi tato metoda líbí, ilustruje něco užitečného o psaní, kompilaci a používání programu C – jako je ten v odpovědi Douga Smythiese. Alokace paměti a přístup k paměti nevypadají jako samostatné věci v interpretovaných jazycích na vysoké úrovni, ale v C si můžete všimnout, a pokud se rozhodnete, prozkoumat tyto podrobnosti.

A konečně, vždy byste měli zkontrolovat, že váš program zabil OOM zabiják . Jedním ze způsobů, jak to zkontrolovat, je zkontrolovat dmesg . Na rozdíl od všeobecného přesvědčení je ve skutečnosti možné, že pokus o alokaci paměti rychle selže, a to i na Linuxu. Je snadné to udělat s obrovskými alokacemi, které očividně selžou... ale i ty se mohou stát neočekávaně. A zdánlivě rozumné alokace mohou rychle selhat. Například na mém testovacím počítači perl -wE 'say length q{a} x 3_100_000_000;' uspěje a perl -wE 'say length q{a} x 3_200_000_000;' tisky:

Out of memory!
panic: fold_constants JMPENV_PUSH returned 2 at -e line 1.

Ani jedno nespustilo OOM zabijáka. Obecněji řečeno:

• Pokud váš program předpočítá, kolik paměti je potřeba, a požádá o to v rámci jediné alokace, alokace může být úspěšná (a pokud ano, OOM zabiják může nebo nemusí zabít program, když je využito dostatek paměti), nebo může alokace jednoduše selhat.
• Rozšíření pole na obrovskou délku přidáním mnoha a mnoha prvků ve skutečné praxi často spouští zabijáka OOM, ale dělá to spolehlivě při testování je překvapivě složité. Téměř vždy se to dělá – protože je to nejúčinnější způsob, jak to udělat – vytvořit každý nový buffer s kapacitou x násobek kapacity staré vyrovnávací paměti. Společné hodnoty pro x zahrnují 1,5 a 2 (a tato technika se často nazývá „zdvojení tabulky“). To někdy překlene propast mezi tím, kolik paměti lze skutečně alokovat a použít, a tím, kolik toho jádro ví, že je příliš mnoho na to, aby se obtěžovalo předstírat, že je rozdává.
• Alokace paměti může selhat z důvodů, které mají jen málo společného s jádrem nebo s tím, kolik paměti je skutečně k dispozici, a to také nespustí zabijáka OOM. Konkrétně může program rychle selhat na alokaci libovolné velikosti poté, co úspěšně provedl velmi velký počet malých alokací. K tomuto selhání dochází při vedení účetnictví, které provádí samotný program – obvykle prostřednictvím knihovny, jako je malloc() . Mám podezření, že to je to, co se mi stalo dnes, když během testování s bash pole (která jsou ve skutečnosti implementována jako dvojitě propojené seznamy), bash ukončete s chybovou zprávou o přidělení 9 bajtů selhalo.

OOM zabiják je mnohem snazší spustit náhodně než úmyslně.

Při pokusu o záměrné spuštění zabijáka OOM je jedním ze způsobů, jak tyto problémy obejít, začít tím, že budete vyžadovat příliš mnoho paměti a postupně se zmenšovat, jak to dělá program C Douga Smythiese. Dalším způsobem je alokovat celou hromadu středně velkých kousků paměti, což je to, co dělá Perl jednořádkový řádek zobrazený výše:žádný z řetězců s milionovými znaky (plus trocha dodatečného využití paměti v zákulisí) není nijak zvlášť náročný, ale dohromady se všechny nákupy o jeden megabajt sčítají.