Administrace komentářů

Treba sa na to pozerat trosku komplexnejsie. V provom rade OOM Kiler je uz posledne stadium a velmi zle. Spravne navrhnuty produkcny system by sa k tomu nemal nikdy dostat. Jednak nedostatok pamate je zly "sizing", alebo nedostatocne otestovana app. Dalsia vec je, ze nie je garancia co bude zabite. Zo skusenosti mozem povedat, ze takmer vzdy to schyta aj ina app. Ak je to prave DB s velkym, ale staticky alokovanym priestorom, tak potom to uz je jedno ... server je zrely na reboot a kontrolu integrity ... ale k veci

Ako som povedal OOM Kiler je az posledne stadium. Ked si zoberieme ako priklad vas server s 8GB ram, tak celkom dost miesta urcite ostane na buffer a cache. Pocas behu systemu sa tam dostane dost vela dat a za beznych okolnosti v cache moze byt aj niekolko 100MB stranok, ktore si vyzaduju zapis na disk.

V momente, ked sa na takom systeme "kusne" applikacia vo "for (::) malloc();", tak zacina prve stadium. Vsetky data, ktore nie su "aktualne" potrebne sa zacnu vytlacat z pamate. Kernel zacne redukovat cache. Algoritmus na spravu cache najprv zacne vyhadzovat najmenej potrebne stranky a s rastucou potrebou pamate zacne agresivnejsie "upratovat". V istom momente spotrebovava znacnu cast cpu vykonu a snazi sa zapisat "dirty" stranky na disk. Sucastne s "upratovanim" sa beziace applikacie dozaduju svojich dat a "natahuju" si data s5 do cache v pamati. Cim je menej volnej pamate, tym je pravdepodobnejsie, ze kod/data nie je v pamati a je ho potrebne nacitat z disku. Priebezne ako zacina byt zaplnenie pamate kriticke, zacinaju "zlyhavat" algoritmy na predcitanie a spravu pamate. Nie pre problem v navrhu, ale problem s nedostatkom volnej pamate. Alokovanu cast pamate "programom" nie je mozne uvolnit a miesto na cache zufalo klesa. V tomto momente uz neostava nic ine ako disku zurivo blikat a nacitavat kazdy kusok kodu pre "beziace" aplikacie z disku. Toto je presne moment, kedy prestava system odpovedat v rozumnom case a disk sa ide zblaznit, ale stale este neprichadza na scenu OOM Kiler.

V momente, ked uz nie je co uvolnit (ziadne cache a buffer v pamati) prichadza OOM Kiler. Podla istych internych pravidiel vyberie jeden, alebo niekolko procesov. Tym da riadne "po hlave" a system uvolni ich pamat. Uvolnenie pamate je velmi rychle (pre istotu si mozte skontrolovat logy kernelu), ale kedze system uz pred nastupom OOM Kileru neodpovedal, tak tazko urcit moment kedy "upratal". Dalsia vec je, ze s prazdnou cache system musi znova natahat mnozstvo "stranok" z disku aby mohol pokracovat s vykonavanim kodu aplikacii. Ak mate moznost sledovat kernel logy napr. cez seriovu linku a zaujima vas to, tak to porucujem skusit :) ... tak isto pohladat stranky na webe spominajuce zazracne anglicke slovicko "Thrashing".

Ak by sme k tomu vsetkemu, co som hore napisal pridali este aj swap. Tak pocas "upratovania" sa system snazi dostat co sa da do swapu a tym sa cely proces spomali.

Cital som ten bug report, co ste pridali ako linku. Osobne si myslim, ze by sa mal zavriet ako "won't fix". Uz z principu je zle ak dojde pamat a su na to ine prostriedky ako predchadzat takemu stavu, alebo ho riesit. OOM Kiler je az posledna zachrana, no maximalne tak na "Desktop" stroje. Na servri je lepsie spravit dump pamate a analyzovat co sa stalo, ako bezhlavo zabijat co tam bezi. Ked zakuliluje spolu s povodcom problemu aj backend nejakej sluzby, alebo databazy, tak potom je to uz aj tak jedno. System sa sice zotavil, ale sluzby nie.

pre zaujimavost doporucujem pozriet aj

# sysctl -a | grep -F vm.
# sysctl -a | grep -F oom

Cela tato tema, je na viac ako len odpoved v diskusii. Ak je este nieco stale nejasne, tak v priebehu dalsich dni sa isto budem pozerat sem do diskusie :o) Staci sa spytat ...