Debian – Oom Killer nefunguje správně, vede k zamrzlému OS?

Po léta zabiják OOM mého operačního systému nefunguje správně a vede k zamrznutí systému.
Když je využití paměti velmi vysoké, celý systém má tendenci „zamrzat“ (ve skutečnosti:stává se extrémně pomalé) po hodiny nebo dokonce dny , místo zabíjení procesů za účelem uvolnění paměti.
Maximum, které jsem zaznamenal, je 7 dní, než jsem rezignoval na provedení resetu.
Když se blíží dosažení OOM, iowait silný> je velmi velmi vysoká (~ 70 %), než se stane neměřitelnou.
Nástroj:iotop ukázal, že všechny programy čtou velmi vysokou propustností (na desítky MB/s) z mého pevného disku.
Co tyto programy čtou?
– Hierarchie adresářů?
– samotný spustitelný kód?
Teď přesně nevím.

[upraveno] V době, kdy jsem psal tuto zprávu (v roce 2017), jsem používal aktualizovaný ArchLinux (4.9.27-1-lts), ale s tímto problémem jsem se setkal již roky předtím.
Zažil jsem stejný problém s různými distribucemi Linuxu a různými hardwarovými konfiguracemi.
V současné době (2019) používám aktualizovaný Debian 9.6 (4.9.0)
Mám 16 GB fyzické paměti ram, SSD, na kterém je nainstalován můj OS, a ne žádné swapy oddíl.

Kvůli množství paměti RAM, kterou mám, nechci povolit swapovací oddíl, protože by to jen zdrželo odhalení problému.
Příliš častá výměna SSD by také mohla potenciálně snížit životnost disku. disku.
Mimochodem, už jsem to zkoušel s odkládacím oddílem i bez něj, ukázalo se, že to pouze oddálí objevení problému, ale není to řešení.

Podle mě je problém způsoben tím, že Linux vynechává důležitá data z mezipaměti , což vede k zamrznutí systému, protože musí číst všechno, pokaždé z pevného disku.

Dokonce by mě zajímalo, jestli Linux nezahodí spustitelné kódové stránky běžících programů, což by vysvětlovalo, proč se programy, které běžně nečtou velké množství dat, v této situaci chovají takto.

Zkusil jsem několik věcí v naději, že tento problém napravím.
Jednou z nich bylo nastavení /proc/sys/vm/min_free_kbytes na 1000000 (1 GB).
Protože toto 1 GB by měla zůstat volná, myslel jsem, že tato paměť bude vyhrazena Linuxem pro ukládání důležitých dat do mezipaměti.
Ale nefungovalo to.

Také považuji za užitečné dodat, že i když by to teoreticky mohlo znít skvěle, omezení velikosti virtuální paměti na velikost fyzické paměti, definováním /proc/sys/vm/overcommit_memory až 2 není v mé situaci slušně technicky možné, protože aplikace, které používám, vyžadují z určitých důvodů více virtuální paměti, než efektivně využívají.
Podle souboru /proc/meminfo , Commited_AS hodnota je často vyšší než dvojnásobek fyzické paměti RAM v mém systému (16 GB, Commited_AS je často> 32 GB).

Mám tento problém s /proc/sys/vm/overcommit_memory na výchozí hodnotu: a na chvíli jsem to definoval jako:1 , protože jsem preferoval, aby byly programy zabity OOM zabijákem místo toho, aby se chovali špatně, protože nekontrolují návratové hodnoty malloc když jsou alokace odmítnuty.

Související:Co dělá . ~/.bashrc příkaz do??

Když jsem o tomto problému mluvil na IRC , Setkal jsem se s dalšími uživateli Linuxu, kteří zažili stejný problém, takže si myslím, že to znepokojuje mnoho uživatelů.
Pro mě to není přijatelné, protože i Windows se lépe vypořádají s vysokou spotřebou paměti.

Pokud potřebujete další informace, máte návrh, řekněte mi.

Dokumentace:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www. kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/ 317814/

Mluví o tom:
Proč se linux out-of-memory (OOM) zabiják nespouští automaticky, ale funguje na sysrq-key?
Proč OOM-killer někdy selže při zabíjení zdroje vepřů?
Přednačtení OOM Killer
Je možné spustit OOM-killer při vynucené výměně?
Jak se vyhnout vysoké latenci v blízkosti OOM situace?
https://lwn.net/Articles/104179 /
https://bbs.archlinux.org/viewtopic.php?id=233843

Přijatá odpověď:

Našel jsem dvě vysvětlení (stejné věci), proč to kswapd0 dělá konstantní čtení disku probíhá dlouho předtím, než OOM-killer zabije problematický proces:

1. viz odpověď a komentář této odpovědi askubuntu SE
2. viz odpověď a komentáře Davida Schwartze k této odpovědi na unix SE

Budu zde citovat komentář z 1., který mi opravdu otevřel oči, proč jsem neustále četl disk, když bylo všechno zamrzlé:

Zvažte například případ, kdy máte nulový swap a systému
téměř dochází RAM. Jádro si vezme paměť např. z
Firefoxu (může to udělat, protože Firefox spouští spustitelný kód
, který byl načten z disku – kód lze v případě potřeby znovu načíst z disku
). Pokud pak Firefox potřebuje znovu získat přístup k paměti RAM o N
sekund později, CPU vygeneruje „těžkou chybu“, která donutí Linux
uvolnit část RAM (např. odebrat část RAM z jiného procesu), načíst
chybí data na disku a poté povolte Firefoxu pokračovat jako obvykle.
Toto je docela podobné normálnímu swapování a kswapd0 to dělá. – Mikko
Rantalainen 15. února v 13:08

Pokud má někdo způsob, jak toto chování zakázat (možná překompilovat jádro s jakými možnostmi?), dejte mi prosím vědět co nejdříve! Moc si toho vážím, díky!

AKTUALIZACE: Jediný způsob, který jsem zatím našel, je přes záplatování jádra a funguje mi to se zakázaným swapem (tj. CONFIG_SWAP is not set ), ale zdá se, že nefunguje pro ostatní s povoleným swapem; viz patch uvnitř této otázky.