Alapból az OOM killer úgy működik, hogy azt a processt próbálja megmenteni, ami a sok erőforrást eszi, minden mást kilövöget, hogy annak jusson. Kérdésem az: hogyan lehet ezt a működést megfordítani? Hogy azt lője ki, ami sok erőforrást kezd el enni. Emlékeimben rémlik, hogy volt valami kernel patch, de aligha lett a vanilla része. Disztribúció recent CentOS 5.5.
Köszi!
- 2456 megtekintés
Hozzászólások
http://lwn.net/Articles/317814/
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Nagyon köszi, ezekszerint a /proc/<pid>/oom_adj adhat egy kis segítséget legalább a sorrendek meghatározásában. Hátránya, hogy folyamatosan figyelni kell, mert pl. egy apache restart esetén új pid lesz, és újra be kell állítani, hogy mennyi legyen az adjust értéke. Thx!
- A hozzászóláshoz be kell jelentkezni
cd /proc ;ls -1 | grep -E '[[:digit:]]+' | while read a; do printf "%10s %30s %s\n" $a `cat $a/comm` `cat $a/oom_score`; done 2>/dev/null | sort -n +2 -3 -r
Egy halalozasi sorrend, ha erdekel.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Köszi, nagyon hasznos!
- A hozzászóláshoz be kell jelentkezni
Mellesleg elkepzelheto, hogy neked inakbb egy jo ulimit max virtualis memoria limit / process beallitas kene.
Ha valami lassan emeszti el a memoriat es van SWAP-od, konnyen lehet, hogy a rendszer hasznalhatatlna szintre lassul, es az OOM killer nem aktivalodik (epeszu idokereten belul).
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Bocs, nem tudtam megállni:
cd /proc ; ls -1 | grep -E '[[:digit:]]+' | while read a; do printf ...
cd /proc ; for a in [0-9]*; do printf ...
- A hozzászóláshoz be kell jelentkezni
hogyan lehet lassítani az oom killert?
4gb ramom van, 4gb swap, két virtuális gépet futtatok 2gb rammal, 470mb swapolt a rendszer, amikor az oom kivágta az egyik gépet. sztem nyugodtan elswapolhatna több gb swapig és az sem baj ha közben lassú vagy nem válaszol a rendszer percekig (ami 4 lemezen raid0), csak fusson végig a processz.
- A hozzászóláshoz be kell jelentkezni
En arra tipelnek, hogy a virtualgepes dolgod nem swapolhatonak jelolt meg sok teruletet (mlock(2)) , vagy valami tenyleg lefoglalt hirtelen sok gigat.
Milyen VM -ek ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
két linux telepítés virtualboxban, 4.1.4.
- A hozzászóláshoz be kell jelentkezni
perl -e 'my $sum=0; while(<>){$sum+=$1 if /Locked:\s+(\d+) kB/ }; print "$sum kB\n"' /proc/$PORCESS_ID/smaps
Igy megnezheted, hogy mlockolt -e memoriat egy adott process. Ez a helyzet ? A VirtualBox mlockol ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
ez 0 kB.
- A hozzászóláshoz be kell jelentkezni
Akkor valoszinuleg a masik eset volt.
Mondott valamit erdekest OOM killer?
64 bites a host ugye ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
érdekeset, azt nem tudom: http://pastebin.com/n6d8JxmR
nem 64bites.
$ uname -a
Linux koma 2.6.40.6-0.fc15.i686.PAE #1 SMP Tue Oct 4 00:44:38 UTC 2011 i686 i686 i386 GNU/Linux
$ free -m
total used free shared buffers cached
Mem: 4026 2815 1210 0 37 982
-/+ buffers/cache: 1796 2230
Swap: 4191 169 4022
- A hozzászóláshoz be kell jelentkezni
use 64 bit :) - bar most talan nem ez az ok.
http://www.redhat.com/archives/taroon-list/2007-August/msg00006.html
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
azannya, köszi!
- A hozzászóláshoz be kell jelentkezni
Most nem ez volt a helyzet...
Mivel a HIGHmem fogyott el.
Utan nezve a dolognak, ha mar OOM killerig fajul a dolog, akkor nincs swapra irogatas.
A megfontolas mogotte,hogy ha swap eszkoz device driverenek kellene a memoria az szopo lenne, mivel igy az nem nyerheto, egyszeruen nem meghatarozhato, hogy nem neki kellett.
Javaslom a swappiness feljebbtekereset, esetleg, ha az sem jo, le lehet tiltani az oom-killert.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
ahah (szaralinux). swappiness 100-on, először egész jól nézett ki, sokáig nem is swapolt, majd elszámolt 515-ig, aztán kidobott (és nem az oom:P), hogy üröm volt nézni:
Nov 6 11:56:43 koma kernel: [ 1609.015026] npviewer.bin[1994]: segfault at b5241bfc ip 4f5d9508 sp b51d804c error 6 in libpthread-2.14.so[4f5cf000+16000]
ezután lement a swap 515-ről 490 alá..
Nov 6 11:59:24 koma gnome-keyring-daemon[1548]: dbus failure unregistering from session: Connection is closed
Nov 6 11:59:24 koma gnome-keyring-daemon[1548]: dbus failure unregistering from session: Connection is closed
Nov 6 11:59:25 koma gnome-session[1556]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Erőforrás átmenetileg nem érhető el) on X server :0.#012
Nov 6 11:59:35 koma kernel: [ 1780.428799] VBoxSVC[1907]: segfault at d00b980c ip 4f4b2538 sp b75eb128 error 5 in libc-2.14.so[4f441000+185000]
Nov 6 11:59:39 koma gnome-session[2284]: WARNING: Failed to start app: Unable to start application: Nem sikerült a gyermekfolyamat („/usr/libexec/at-spi-registryd”) végrehajtása (Nincs ilyen fájl vagy könyvtár)
Nov 6 10:59:41 koma rtkit-daemon[1454]: Successfully made thread 2304 of process 2304 (/usr/bin/pulseaudio) owned by '42' high priority at nice level -11.
Nov 6 10:59:41 koma rtkit-daemon[1454]: Failed to make thread 2305 RT: Operation not permitted
- A hozzászóláshoz be kell jelentkezni
Én először is kikapcsolom a memory overcommit-ot; akinek nem garantálható a kért memória, annak megmondjuk rögtön, aztán csináljon, amit akar (vagy tud). Plusz ulimit-tel vagy újabb disztróknál cgroups-szal korlátozzuk a kiadható memóriát akkor is, ha még lenne szabad (és garantálható).
Az OOM killer egy olyan esetre heurisztika, amely eset "termelő szerveren" elő sem fordulhatna. (Megígérünk a processnek valami virtuális memóriát, aztán amikor használná, akkor pofára esik.)
- A hozzászóláshoz be kell jelentkezni
Tulajdonképpen +1.
Hozzáteszem: amikor pl. desktop felhasználó vagyok, az a tapasztalatom, hogy a nagyobb memóriaigényű appoknak így hamarabb elmegy a kedvük a futástól.
Szerveren nem tudom, nem gyakoroltam ilyesmit, de hasznos gondolat, hogy élesben ennek nem volna keresnivalója.
Fejlesztőként viszont minden kartársnak jó szívvel javaslom az overcommit kikapcsolását programozáshoz, rendszerintegráláshoz, teszteléshez, stb. :-)
- A hozzászóláshoz be kell jelentkezni
szábszkrájb
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni