Történt vala pedig, hogy figyelmetlenségből ráindítottam egy virtuális gépre, mielőtt még az előző teljesen leállt volna. Ettől persze elhasalt a rendszer, mert azért nincs végtelen mennyiségű memória beépítve. Nyilván belépett az OOM killer, de fertály óra alatt sem tudott rendet tenni, miközben a reboot max. 30 mp. Elkezdtem ezen agyalni, hogy OK, alapvetően stabil a rendszer, de tulajdonképpen alaposan fejbe lehet vágni egy ügyetlen felhasználói mozdulattal, még root-nak sem kell lenni. Van ebben valami, ami nem túl esztétikus számomra. Elkezdtem tehát kísérletezni, utánaolvasni, miközben jópárszor elhasaltattam a rendszert. Az első számú bűnbakom az overcommit. A sysctl.conf-ban módosítottam egy kicsit, többedik iteráció után egy stabil, agyonüthetetlen beállítás: vm.overcommit_memory=2 vm.oom_kill_allocating_task=1 vm.admin_reserve_kbytes = 8192 vm.min_free_kbytes=16384 vm.overcommit_ratio=99 És bamm! Össze-összeomlik a memóriára éhes processz, ha túl lépné korlátait, meg akár el sem tud indulni, ha már eleve kevesebb a szabad memória, mint kéne neki, de a rendszer egésze töretlenül megy tovább, és reszponzív marad. Megyek tovább, mert viszont azt vettem észre, hogy bizonyos dolgok, pl. a Davinci Resolve nem igazán szereti a szigorúbb memória kezelést. Ráadásul úgy tűnik, nem is mindig tudom kimaxolni a gép terhelését. Találtam egy olyat, hogy "earlyoom". Visszaállítottam sysctl.conf-ot, és beindítottam az earlyoom ( https://packages.debian.org/stable/admin/earlyoom ) démont. Azt hiszem, ezt tartom meg. Az első tapasztalataim elég jók. Az alapértelmezett beállításain még semmit sem változtattam, de a rendszert nem tudom kiakasztani túlzott memóriahasználattal, bár most a vm.overcommit_memory az alap 0 értéken van.
Üdvözöljük az ubuntu.hu oldalán
Early OOM Daemon: avagy a rendszer ütésállóságának fokozása
Hozzászólások (2)
A hozzászólások nem engedélyezettek ennél a cikknél
Történt vala pedig, hogy figyelmetlenségből ráindítottam egy virtuális gépre, mielőtt még az előző teljesen leállt volna. Ettől persze elhasalt a rendszer, mert azért nincs végtelen mennyiségű memória beépítve. Nyilván belépett az OOM killer, de fertály óra alatt sem tudott rendet tenni, miközben a reboot max. 30 mp. Elkezdtem ezen agyalni, hogy OK, alapvetően stabil a rendszer, de tulajdonképpen alaposan fejbe lehet vágni egy ügyetlen felhasználói mozdulattal, még root-nak sem kell lenni. Van ebben valami, ami nem túl esztétikus számomra. Elkezdtem tehát kísérletezni, utánaolvasni, miközben jópárszor elhasaltattam a rendszert. Az első számú bűnbakom az overcommit. A sysctl.conf-ban módosítottam egy kicsit, többedik iteráció után egy stabil, agyonüthetetlen beállítás: vm.overcommit_memory=2 vm.oom_kill_allocating_task=1 vm.admin_reserve_kbytes = 8192 vm.min_free_kbytes=16384 vm.overcommit_ratio=99 És bamm! Össze-összeomlik a memóriára éhes processz, ha túl lépné korlátait, meg akár el sem tud indulni, ha már eleve kevesebb a szabad memória, mint kéne neki, de a rendszer egésze töretlenül megy tovább, és reszponzív marad. Megyek tovább, mert viszont azt vettem észre, hogy bizonyos dolgok, pl. a Davinci Resolve nem igazán szereti a szigorúbb memória kezelést. Ráadásul úgy tűnik, nem is mindig tudom kimaxolni a gép terhelését. Találtam egy olyat, hogy "earlyoom". Visszaállítottam sysctl.conf-ot, és beindítottam az earlyoom ( https://packages.debian.org/stable/admin/earlyoom ) démont. Azt hiszem, ezt tartom meg. Az első tapasztalataim elég jók. Az alapértelmezett beállításain még semmit sem változtattam, de a rendszert nem tudom kiakasztani túlzott memóriahasználattal, bár most a vm.overcommit_memory az alap 0 értéken van.
Ez szuperül hangzik, de hadd legyek kicsit óvatos, mielőtt duhajkodnék. Ez ahogy olvasom, egy általánosságban használható "eszköz", nem csak virtuális géphez. Ugye? "it checks the amount of available memory and swap periodically, and when both are below a preconfigured value, it kills the largest process. " A fenti mondat, meg azt jelenti, hogy tökmindegy mi az a folyamat, akkor is a legnagyobbat állítja le? Úgy értem nem érdekli, hogy éppen mivel dolgozok, kilövöm és kész. Bár ha úgyis fagyás lenne a vége, akkor végül is mindegy.
sömikeIgen ez egy általános eszköz, és ha jól értem, a legnagyobb zabálót fogja kicsapni. Nekem 16 GB RAM van a gépemben, ezt a leghatékonyabban én a virtuális gépekkel tudom annyira elpocsékolni, hogy "baj" lehessen belőle. Ezért emlegettem ezeket, de nem kizárólag rajtuk működik. El tudom képzelni, hogy egy 2GB RAM+1GB swap felszerelt gépben, a gúglikrómot fogja fejbevágni, mikor beletekersz vele egy fércbúk lap alja felé... Amúgy a kernel saját OOM killere is ugyanezt tenné valószínűleg, ha kivárnánk. Időközben találtam olyan beállítást (vm.admin_reserve_kbytes 256MB, vm.min_free_kbytes a fizikai RAM 10% körül), amikor az OOM killer már 17 percen belül végezni tudott VALAMIVEL a pontrendszere alapján, a rendszer utána ment tovább. De sok köszönet abban sem volt, mert az ideig csak félholt állapotban tengett a gép, és az egérkurzor is kb. 20-30 mp-enként ugrott egyet. Beállítva a vm.oom_kill_allocating_task=1 paramétert, az is a legnagyobbat fogja kicsapni, (nálam többnyire) ez az újonnan indított virtuális gép volt, néhány esetben az előzőt ütötte ki. De iszonyat sokat kell rá várni! Akkor már jobb az earlyoom, megdöglik a legnagyobb, konstatálod, és kész...
Fórumnavigáció