Důvodem, proč není OOM-killer automaticky volán, je to, že systém, i když je zcela zpomalený a nereaguje již v době blízko nedostatku paměti y, ve skutečnosti nedosáhl stavu nedostatku paměti.
Zjednodušeno, téměř plná paměť RAM obsahuje 3 typy dat:
- data jádra, to jsou zásadní
- stránky základních údajů o procesu (např. jakákoli data, která proces vytvořil pouze v paměti RAM)
- stránky nepodstatných procesních dat (např. data, jako je kód spustitelných souborů, pro které existuje kopie na disku/v souborovém systému a která, i když jsou aktuálně mapována do paměti, by mohla být při použití znovu načtena z disku )
V situaci nedostatku paměti je linuxové jádro, pokud mohu říci, kswapd0 vlákno jádra, aby se zabránilo ztrátě dat a ztrátě funkčnosti, nemůže zahodit 1. a 2., ale může alespoň dočasně odstranit data mapovaná do souborů paměti z paměti RAM, což jsou procesy formulářů, které aktuálně neběží.
I když je to chování, které zahrnuje drcení disku, neustálé vyhazování dat a jejich opětovné čtení z disku může být považováno za užitečné, protože zabraňuje nebo alespoň odkládá nezbytné odstranění/zabití procesu a uvolnění-ale-také- ztrácí paměť, má vysokou cena:výkon.
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ]
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ]
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
je zjevně drahé IO a systém pravděpodobně přestane reagovat, i když technicky ještě zcela nevypršel paměti.
Z pohledu uživatele, jakkoli se to zdá, být pozastaveno/zmrazeno a výsledné nereagující uživatelské rozhraní nemusí být ve skutečnosti vhodnější, než prostě zabít proces (např. karta prohlížeče, jejíž využití paměti mohlo být velmi dobře hlavní příčinou/viníkem začít s.)
Zde se zdá, jak otázka naznačovala, spouštěč tlačítka Magic SysRq pro ruční spuštění OOM skvělé, protože Magic SysRq je méně ovlivněn necitlivostí systému.
I když mohou existovat případy použití, kdy je důležité procesy vůbec zachovat (výkon ) náklady, u stolních počítačů je pravděpodobné, že uživatelé upřednostňují zabijáka OOM před zmrazeným uživatelským rozhraním. V této odpovědi na stackoverflow existuje patch, který tvrdí, že v takové situaci vyjímá čisté mapované soubory zálohované fs z paměti.
Během zátěžového testu se můžete podívat na soubor /sys/fs/cgroup/memory/memory.oom_control.
nebo
Můžete se podívat na datum poslední změny a zjistit, zda bylo změněno v době posledního zamknutí. To vám prozradí, zda to bylo vůbec pokusem udělat svou práci.
under_oom 0
To je váš problém:
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
Pokud je nastaveno na 1, znamená to, že je pod kontrolou. Povoleno.
Pokud je nastaveno na 0, není to pod kontrolou Oom. Zakázáno.