"mit csinaljon az OOM esemeny hatasara a kernel?"
ez egy letezo kerdes. a kovetkezo ket valaszlehetoseg van a linuxban:
- crash
- oom_killer
Ha belegondolsz, nem is lehetseges mas. (*) Ettol teljesen fuggetlen az a kerdes, hogy lehetseges-e OOM esemeny. Vannak olyan oprendszerek, amik lehetetlenne teszik az OOM esemenyt, a linux nem ilyen. A linuxban elvileg lehetseges az OOM esemeny.
Az "overcommit_ratio" hatarozottan csak a processzekre vonatkozik, azonban a memoriaban vannak nem processzhez kapcsolt teruletek.
Az egyik klasszikus 30 eves megoldas a problemara:
- a processzeknek csak annyi virtualis memoriat adhatunk, amennyi a swap space. Hiba van meg fizikai memoria, nem hasznalhatjak.
Linux mimic erre a megoldasra:
overcommit_memory:2
overcommit_ratio:0
ekkor swap space nelkul nem mukodik a rendszer, de ha csak fizikai memoria meretu swap spacet adsz, akkor tenylegesen nem fog oda kilapozni.
ennyire szelsosegesnek nem kell lenni. Ha esetleg tudod, hogy a kernel mennyit fog fogyasztani a fizikai memoriabol, akkor azt levonhatod a 100%-bol, es azt beirhatod az overcommit_ratio -ba, swap space nelkul hasznalhatod a rendszert.
Sajnos ez az ertek nem tudhato.
Nalunk egy clusternode halala nem olyan nagy baj, hiszen a kizarolagos allokacio miatt szigoruan csak egy jobot erinthet. egy big smp node eseten nyilvan nagy baj.
Viszont nalatok van lokalis diszk a gepben, lehet ra swap spacet rakni. A kovetkezot javaslom elsosorban es azonnal, mielott vegerejarunk ennek a cpuset temakornek:
- overcommit_memory: 2
- legyen swap space. ennek a merete legyen az szummma tmpfs meret + a fizikai memoria 3% -a. Ez legyen kisebb, mint a fizikai memoria. Lehetoleg ne legyen olyan baromi sok a tmpfs meret. (**)
- hany szazaleka a swap space a fizikai memorianak? ha 19, akkor legyen az overcommit_ratio: 100-19. na jo, tartalek: 100-20.
Ezzel azt ered el, hogy a processzek szumma csak a fizikai memoria mereteben tudnak dolgozni, valodi lapozasi aktivitas nem lesz, de OOM esemeny helyett lapozasi esemeny lesz, ami azert joval olcsobb.
Monitorozassal azt is latod, hogy mennyi a maximalisan hasznalt swap space, na ennyit kellett volna kihagyni az overcommit_ratio -bol swap nelkul.
---------
"lapozasi esemeny" alatt "major page fault" mas terminologiaban "hard page fault" vagyis fizikai IO aktivitast, pongyolan fogalmazva "swappeles"-t ertettem most. Ettol fuggetlenul nagy mennyisegu minor page fault uzemszeru, ami a numa architecturaban meg komoly gondot is okozhat, tehat a cpuset temakornek javasolt a vegere jarni. Mindenesetre a fent javasolt modositassal a gep stabilitasa varhatoan novekszik.
(*) dehogynem lehetseges mas: OOM esemeny hatasara a kernel varhatna is, hogy hatha onmagatol szabadul fel lap. Ilyenkor viszont, hogy ne legyen ciklikus varakozas, egy deadlock killernek kell rendet raknia. A deadlock killer egy kicsit bonyibb, mint egy oom killer, a deadlock killer hatasara konnyebben elszabadul a kenkoves pokol, plane, ha kolcsonos lapravaras okozza a deadlockot, nem pedig jolszitualt valodi lock struktura.
(**) en szeretem hasznalni a tmpfs -t, mert nagyon jo a teljesitmenye, de egyszeruen fogalmam sincs, hogy hova szamit a vfs memoriaja, es hogyan befojasolja a lapozasi rendszert.