NUMA architektúra + cpuset kérdések

Linux-haladó

Sziasztok,

0. kérdés: tudtok olyan fórumot a széles Interneten, ahol NUMA rendszerek üzemeltetésével kapcsolatban lehet feltenni kérdéseket?

Van egy sokprocesszoros (1000+) linuxos NUMA rendszer, ahol a memórialokalizáció maximalizálása érdekében igyekszünk cpuseteket használni. Két problémát nem sikerült eddig megnyugtató módon megoldanunk:

1. Ha egy program túllépi a számára engedélyezett memória node-ok által biztosított memóriát, akkor elkezd futni az oom-killer. Naiv feltételezésem szerint ilyenkor gyorsan meghal a hibát okozó processz és minden visszatér a rendes kerékvágásba. Ezzel szemben a tapasztalatok szerint változatos hibák mellett lerohad a komplett rendszer, valószínűleg túlterhelődik a numalink kapcsolat. Mi lehet az oka? Hogyan lehet az ilyet elkerülni? (A memory overcommit-ot kikapcsoltam, de az vsz. csak a komplett memóriára vonatkozik, egy cpusetben történő túlfoglalás ellen nem véd.)

2. A gépen fut 20000+ "processz" (vagy szál). Ezek többsége kernel szál, amelyek mind az ezer processzorra külön pid-ként jelennek meg. Az a probléma, hogy ezek mind a root cpusetben futnak, így a linux ütemező (elvileg) össze-vissza pakolhatja őket cpu core-okra, sőt ezt a terhelés minél jobb megosztása miatt szereti is csinálni. Vajon honnan lehet látni, hogy egy kernel szál "rögzített-e" egy adott cpu core-ra? (Dilettáns tudásom alapján a kernel tud ilyet mondani egy szálra.) Érdemes-e sportolni azon, hogy (bizonyos) kernel szálak ne a root cpusetben, hanem egy kisebb, konzisztens egységben (pl. egy kicsi boot cpuset) fussanak? Az egyik elsődleges ilyen jelöltem az nfsd lenne.

( bajnokk | 2012. 10. 27., szo – 10:44 )

UP. Valamint megpróbáltam "szexibbé" tenni a tárgyat. :)

( uid_2716 | 2012. 10. 27., szo – 15:55 )

memórialokalizáció maximalizálása érdekében igyekszünk cpuseteket használni

most szaladnom kell, úgyhogy csak ömlesztve: autonuma numad numatop schednuma?

( egeresz | 2012. 10. 27., szo – 22:19 )

Olyan topic, ahol TE tehetsz fel kerdeseket, vagy olyan, ahol NEKED tesznek fel kerdeseket? :-)

sajnos csak egy 16 magos altix van itt, egyszeruen nem jelentkeznek az altalad emlitett problemak.

OOM killer kikapcsolva?
hogyan?
2 > overcommit_memory
95 > overcommit_ratio

ez az en szokasos megoldasom az oom killer ellen.

Olyan topic, ahol TE tehetsz fel kerdeseket, vagy olyan, ahol NEKED tesznek fel kerdeseket? :-)

Hát, úgy csöppentem ebbe a történetbe, mint Pilátus a Credóba... Végtére ez is csak egy Linux, ugyan nem fogok megijedni, hogy kicsit több benne a processzor meg a memória, mint szokott lenni, gondoltam.

Aztán amikor jött ez, meg még 3-4 teljes mértékben értelmezhetetlen hiba, akkor rájöttem, hogy ugyan idáig remekül el-adminolgattam a rendszereket mélyebb kernel ismeretek nélkül, de itt nem úszom meg, hogy a hardver architektúrát és a kernel belső világát (virtuális memória, processzor ütemezés, stb) alaposabban meg ne ismerjem... de igazság szerint rohadtul nem tudom, hol is kezdjek neki. (És azt végképp nem, hogy mikor, de ez részletkérdés.)

Szóval HPC témakörben azt hiszem, én legfeljebb kezdő kérdéseket tudok feltenni, de mennél jobban nézek ebbe a kútba, annál jobban tisztában vagyok vele, hogy nem látom az alját.

( egeresz | 2012. 10. 27., szo – 23:43 )

most egy 4 socket opteronos rendszeren kiprobalom, erdekel.

debian 6.0.5 


mkdir /dev/cpuset
mount -t cpuset cpuset /dev/cpuset
cd /dev/cpuset

SOCKETS=$(cat /sys/devices/system/cpu/cpu*/topology/physical_package_id | 
sort -u)

for i in $SOCKETS ; do mkdir sokcet$i ; done

fgrep  "" /sys/devices/system/cpu/cpu*/topology/physical_package_id | 
sed -e 's"/sys/devices/system/cpu/cpu""' | 
sed -e 's"/topology/physical_package_id""' |
awk -F: '
   {CPUS[$2]=CPUS[$2] "," $1}
   END{for( i in CPUS)print "echo", CPUS[i], " > socket" i "/cpus"}' | 
sed -e 's/ ,/ /' |
 /bin/bash

oke, ez utobbi pipeline kicsit eros volt igy ejfelkor.

a /sys/devices/system/node/node*/cpulist hierachiat most inkabb nem nyalom fel egy hasonlo szep pipeline-vel, hanem:

echo 0,1 > socket0/mems
echo 2,3 > socket1/mems
echo 4,5 > socket2/mems
echo 6,7 > socket3/mems

A doksi szerint ( Documentation/cpusets.txt ) neked mem_exclusive kell, ha a kerneltheradek memoriajat sem akarod kiengedni, mondjuk:

echo 1 > socket0/mem_exclusive

es akkor most mozgassunk egy jolszitualt kernelthreadet


root 1013 0.0 0.0 0 0 ? S Sep11 6:07 \_ [nfsiod]
...

fgrep Cpus_allowed_list /proc/1013/status
Cpus_allowed_list: 0-63

echo "1" > socket0/memory_migrate

echo 1013 > socket0/tasks
cat socket0/tasks
1013

fgrep Cpus_allowed_list /proc/1013/status
Cpus_allowed_list: 0-11

Ugy nezem, atrakta. Hogy lesz-e ebbol baja a nfsiod -nek, az par nap alatt kiderul :-)

idaig nem volt vele gond.

Talan akkor lehetne vele gond, ha a user processek meg egy masik hardwalled cpusetbe kerulnenek.

jo jatek, aztan az sshd -t berakod egy masik, "ineteraktiv" nevu cpusetbe, es egeszen cluster modban hasznalod ezt a szep smp gepet :-)

peldaul szetvagni blade-kre, a slurm (*) alkalmas arra, hogy mindegyiken inditson slurmd-t, es akkor kapsz egy meglehetosen hetkoznapi clustert, extrem kivallo mpi teljesitmennyel.

(*) tudom, hogy nem slurm van nalatok, de en csak a slurm-hoz ertek.

( egeresz | 2012. 10. 28., v – 00:52 )

Vajon honnan lehet látni, hogy egy kernel szál "rögzített-e" egy adott cpu core-ra?

pl vegyuk a kovetkezo ertelemszeruen cpu-hoz rogzitett kernelthreadet:

root 147 0.0 0.0 0 0 ? S Sep11 3:52 \_ [events/0]
...
fgrep Cpus_allowed_list: /proc/147/status
Cpus_allowed_list: 0

ez bizony csak ott tud futni.

( egeresz | 2012. 10. 28., v – 01:02 )

valószínűleg túlterhelődik a numalink kapcsolat.

ebben ketelkedek. Egyreszt nem hiszek a fizikai tulterhelhetosegben (vagyis, hogy a numalink hibazna). Masreszt abszolult egyszeru picike szerveren (ket darab intel E5520) is a legvaltozatosabb orult hibajelensegeket tudja produkalni az oom_killer.

elofordult mar az is, hogy a felhasznalo szamolo jobjat dobta ki, de valoszinubb, hogy valami extra gazt csinal.

Az oom_killer kulonosen akkor viselkedik felfoghatatlanul, ha van tmpfs, es nincs swap space. (a mi clusterunk zome ilyen)

Az mondjuk lehetseges, hogy a numalink terheltsege miatti lassu memoriaeleres soran a kernel valahol timeoutra fut. Vagy valami nincs vedve lockkal, es csak lassu memoria eseten jon elo a hiba.

( egeresz | 2012. 10. 28., v – 01:14 )

0. kérdés: tudtok olyan fórumot a széles Interneten...

regota dedelgetett vagyam, hogy a magyar hpc rendszergazdai tarsasag valamifele onszervezodo modon alkosson csoportot, peldaul legalabb ismerjek egymast :-)

Van egy https://listserv.niif.hu/mailman/listinfo/hpc-forum lista (meglehetősen elhanyagolható forgalommal), akad néhány tényleg okos felhasználó arrafelé, legalábbis erre következtetek abból, hogy néha a felét sem értem abból, amit írnak.
Igaz, adminok egyelőre nem nagyon vannak... de jó lenne, ha lennének. Nyílt ez mindenkinek.

( egeresz | 2012. 10. 29., h – 11:47 )

Na, miutan hetvegen felszetapoltam, most kiprobalom ezt az oom killer dolgot.

feltetelek:
- nem mem hardwalled cpuset
- az ulimit nem korlatoz
- /proc/sys/vm/overcommit_memory:2
- /proc/sys/vm/overcommit_ratio:97
- 256Gi memoria, 500G swap,
- 64Gi memoria ebben a cpusetben

es most mi legyen? ha van swap, akkor kilapozza oda, ahelyett, hogy masik memorynode-ba lapozna.

viszont ha nem hardwalled, akkor a kilapozas soran atkerulhet masik memorynode-ba a lap, akar millios nagysagrendben is.

itt lesz a gond, nem a cpuset-tel.
bele kellene nezni a kernelbe, hogy a softpagefaultot hogyan csinalja cpuset eseten, a tippem az, hogy siman atpakolja masik memorynode-hoz.

Most ezen gondolkodom.

"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.

[gn]befolyasolja[/gn]

Nagyon jo leiras, koszonom. Ezt kicsaphatnad blogba is, mert eddig nem tudok ilyen jo, tomor, lenyegretoro es ertheto leirasrol a Linux memoriamenedzsmentjerol. Valami kodos fogalmaim nekem is vannak rola - de szavakba onteni nem tudnam, plane nem igy.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Valószínűleg az zavart meg engem, hogy ha cpusetben történik az OOM, akkor a kernelnek még dögivel van memóriája, csak éppen az adott processz nem tud már több helyet lefoglalni, mivel ő csak néhány node-ot használhat. De nyilván erre is az a logikus válasz, hogy elindul az oom-killer. Ami viszont szemlátomást nem tud arról, hogy ez csak egy lokális esemény, és nekiáll átnézni mind a soktízezer processzt, hogy melyiket is ölje meg. Valószínűleg az "átnézés" olyannyira kicsinálja a gépet, hogy megakad a kapcsolat a blade-ek között, amitől egy idő után az eredeti problémánál sokkal nagyobb baja lesz a gépnek. (Például elveszíti a root diszkjét.)

Tmpfs-t tényleg jó lenne használni, bár most nem tesszük, sajna. Sőt, swapet sem. A 3% hogy jött ki?

Az a baj nálunk, hogy ha valaki sok memóriát akar használni, akkor kénytelen sok core-t lefoglalni és vice versa. Nem tudom, hogy máshol hogyan kezelik kulturáltan, de valószínűleg ez a tömbösítés okozza a sok fejfájást... :/

Az a baj nálunk, hogy ha valaki sok memóriát akar használni, akkor kénytelen sok core-t lefoglalni és vice versa. Nem tudom, hogy máshol hogyan kezelik kulturáltan.

ugy tudom, hogy sehogy.
Legalabbis nalunk sehogy, mivel cluster van, exclusiven allokalt node-okkal.

de, mivel az altix UV1000 -ben (tippem szerint) 2 nagysagrend van a legtavolabbi es a cpu-lokalis memoria-eleres sebesseg kozott, emiatt olyba tunik, hogy a memora az bizony a cpu egyik tulajdonsaga, nem tekintheto kozosnek.

az adott processz nem tud már több helyet lefoglalni, mivel ő csak néhány node-ot használhat [...] elindul az oom-killer [...] nem tud arról, hogy ez csak egy lokális esemény

Ezen már annyival is segíthetsz, hogy kikapcsolod az oom killert (overcommit_memory=2). Így amikor az adott processz nem tud több helyet lefoglalni, pontosan az a processz fog elszállni (jobban megírt program esetén lesz cleanup is). Ez eléggé lokális kezelése a problémának.

Az overcommit_memory=0 egy ordenárén desktop-orientált alapbeállítás.

Pontosan ezt gondoltam én is, de tévedtem. (És az overcommit_memory=2 csak bizonyos feltételek megléte esetén "kapcsolja ki" az oom-killert.)

Jelenlegi tapasztalataim szerint egy cpusetben történő OOM esemény a kernel VM beállításaival nem küszöbölhető ki (*). És bármilyen OOM eseményre az oom-killer fog elindulni.

(*): Ezt egyelőre csak kikapcsolt swappel néztem, lehet, hogy ez a baj. Sajnos a tesztelés elég kockázatos, a fenti okok miatt, de ha a swap változtat a dolgon, akkor visszajelzek.

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.

Szeretném árnyalni: az általad is említett

nem processzhez kapcsolt teruletek

kedvéért hajlandó kilapozni (ld. vm.swappiness). Pl. alvó processz heap-jét dentry/inode cache vagy socket buffer-ek kedvéért.

A hangoláshoz: ha jól értem, abból indulunk ki, hogy a processzeknek odaadjuk a teljes RAM-ot. Ebből aztán a tmpfs-sel kikényszerítünk X százalékot a swap-re (X <= 20), majd a kernel "hard" igényeivel további Y százalékot (Y <= 5). Így a swap mérete (X+Y)/100 * ramsize.

Mivel abból indultunk ki, hogy a processzek teljes igénye ne haladja meg a RAM-ot, azért

ramsize == (swapsize + ramsize * (overcommit_ratio/100))
ramsize == ((X+Y)/100 * ramsize + ramsize * (overcommit_ratio/100))
ramsize == ramsize / 100 * ((X+Y) + overcommit_ratio)
100 == (X+Y) + overcommit_ratio
100 - (X+Y) == overcommit_ratio

Korrekt :)

cgroup?

mit csinaljon az OOM esemeny hatasara a kernel?

http://www.kernel.org/doc/Documentation/cgroups/memory.txt


memory.oom_control # set/show oom controls.

10. OOM Control

memory.oom_control file is for OOM notification and other controls.

Memory cgroup implements OOM notifier using cgroup notification
API (See cgroups.txt). It allows to register multiple OOM notification
delivery and gets notification when OOM happens.

To register a notifier, application need:
- create an eventfd using eventfd(2)
- open memory.oom_control file
- write string like " " to
cgroup.event_control

Application will be notified through eventfd when OOM happens.
OOM notification doesn't work for root cgroup.

You can disable OOM-killer by writing "1" to memory.oom_control file, as:

#echo 1 > memory.oom_control

This operation is only allowed to the top cgroup of sub-hierarchy.
If OOM-killer is disabled, tasks under cgroup will hang/sleep
in memory cgroup's OOM-waitqueue when they request accountable memory.

For running them, you have to relax the memory cgroup's OOM status by
* enlarge limit or reduce usage.
To reduce usage,
* kill some tasks.
* move some tasks to other group with account migration.
* remove some files (on tmpfs?)

Then, stopped tasks will work again.

At reading, current status of OOM is shown.
oom_kill_disable 0 or 1 (if 1, oom-killer is disabled)
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)

11. TODO

1. Add support for accounting huge pages (as a separate controller)
2. Make per-cgroup scanner reclaim not-shared pages first
3. Teach controller to account for shared-pages
4. Start reclamation in the background when the limit is
not yet hit but the usage is getting closer

Summary

Overall, the memory controller has been a stable controller and has been
commented and discussed quite extensively in the community.

Határozottan érdekes.

És mit kell hozzá bekapcsolni, hogy legyen? 


# mount -t cgroup -o cpuset none /tmp/cgroup/cpuset/
# mount -t cgroup -o memory  none /tmp/cgroup/memory/
mount: special device none does not exist
# mount -t cgroup -o cpu  none /tmp/cgroup/cpu/   
# mount -t cgroup -o devices  none /tmp/cgroup/devices/
# mkdir foobar 
# mount -t cgroup -o foobar  none /tmp/cgroup/foobar/
mount: special device none does not exist

( egeresz | 2012. 11. 05., h – 18:18 )

Ismét volt rá egy kis időm.

Tesztkörnyezet:
debian 6.0.5, 2.6.32-5-amd64
4 x Opteron 6238 (total 48 cores)
256GiB ram
Numa:
8 memory node
cpuset konfig: minden cpu -ra egy cpuset (tehát 2 memory node 1 cpuset)
64 GiB /cpuset

megjegyzések
Az alábbi fogalmak a linux kernelben egymástol függetlenek, az algoritmusuk nincs összehangolva.

overcommit
Hogy a processz kaphat-e több memóriát a malloc() hatására, mint amennyi ténylegesen rendelkezésre áll. A vm.overcommit_memory és a vm.overcommit_ratio *nem* kapcsolja ki az overcommitot, csak egy felső határt adhatsz neki. Semmi fogalma nincs a cpuset -ről.
OOM esemény
Ha egyszercsak kiderül, hogy overcommit volt, és az hiba volt (elfogyott a memória). Ekkor oom_killer van, vagy panic. (vm.panic_on_oom) Az oom_killer elindul, ha lap kellene, de ténylegesen már nincs. Akkor is elindul, ha csak egy cpuset-ben fogy el a memória.
cpuset
Limitálhatod egy processz cpu és memóriahasználatát valamely subsetre. Ez, valójában a process (resident size) working set -jét limitálja, nem a "memóriáját" ami nem túl definit.
resident set, resident set size, rss, working set
A processz memórájából az a rész, ami a fizikai memórában éppen aktuálisan a processzhez van mappelve, és ezt a területet a processz laphiba esemény (page fault exception) nélkül éri el. Általában working set -nek hívják, de pont a linuxnál gyakran resident set -nek :-) Eltérés van még aközött, hogy egy processz bemeppelt területét, vagy az összes processz bemeppelt területét hívják working set -nek. Nekem most a tesztelés során úgy tünt, hogy a cpuset a benne lévő összes processz working set-jét limitálja. See man ps, "SIZE and RSS fields"
procesz virtuális memória
Amit a programozó a programján keresztül lát. Ennek egy része benne van a working set-ben, más része az in page cache-ben, más része az out page cache-ben, vagy kint a diszken, vagy a 3rd level pagecacheben, vagy az mmapp()-elt file-ban, vagy a futtatható exe-ben, vagy másik processzel közös lapokban, vagy... baromira nem egyszerű tényleg kikapcsolni az overcommitot.

teszteléshez használt program, környezetek
írtam egy C progit, ami a paraméterében megadott mennyidégű memóriát lefoglalja, majd megtölti.
A tesztprogramnak egy kicsit nagyobb méretet adtam, mint ami a cpuset-be befér. (64GiB + 1KiB)
A tevékenységét monitoroztam a 'sar -B 1' paranccsal. (man sar)
vm.overcommit_memory:2, vm_overcommit_ratio:97

tesztesetek

mem_exclusive:0, mem_hardwall:0, swap
A 'sar -B 1' kimeneten (részlet) jól látszik, amikor megtelik a cpuset, és elkezd lapozni. Fizikai diszkre-írás történik, de nem értem ez miért nem látszik a majflt/s értéken. A program rendben lefutott. 

  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
      0.00      0.00 413940.00      0.00     50.00      0.00      0.00      0.00      0.00
      0.00      0.00 413991.00      0.00     50.00      0.00      0.00      0.00      0.00
      0.00  58760.00 349209.00      0.00   6620.00  11264.00   9792.00   6357.00     30.19
  17272.00 137140.00  28572.00      2.00  30343.00  33280.00  29664.00  28658.00     45.53

Az első sorban lévő nagy fault/s érték azért van, mert a kernel akkor annyi üres lapot adott oda processznek (working set növelés). A végén elég rendes pgpgin/s pgpgout/s érték van, a swap disk 100% -on ment. (ellenőrizve 'sar -d 1' -gyel)

mem_exclusive:0, mem_hardwall:0, no swap
OOM esemény történt, az oom_killer elindult, és szerencsére ezt a processzt találta meg. 6-7 sec teljes megakadás után a rendszer újra magához tért. A tesztprogram ki lett lőve.
mem_exclusive:1, mem_hardwall:1, swap
Nem láttam látható és érzékelhető különbséget az első esethez képest.
mem_exclusive:1, mem_hardwall:1, no swap

nem látható eltérés a korábbi 'no swap' konfighoz képest. Az oom_killer elindult, a rendszer kicsit állt, majd az oom_killer megtalálta ezt a processzt és kilötte.

Javaslat

  • Legyen swap.
  • Olyan queue rendszert/shedulert kell használni, ami képes a memóriát osztható és felhasználható erőforrásnak tekinteni (consumable resources) A felhasználókat kötelezni kell az igényelt memória megadására. A job inditásakor be kell állítani (ulimit -v) a felhasználható memóriát. Ez persze csak akkor működik, ha a queue rendszer képes megérteni a cpuset-ek topológiáját.

Jövök egy sörrel, köszönöm!

A méréseid az én tapasztalataimnak is megfelelnek, be is állítottam a swapet. Az, hogy miért döglik meg a rendszer az oom_killer elindulása után, továbbra sem értem, de megnyugtató, hogy ez kisebb rendszeren is több másodperces klinikai halált jelent.

A kétségbeesett tesztelések közben fogtam egy hibás numalink kapcsolatot is, ami biztos nem javít a helyzeten. Kíváncsi vagyok, hogyan csinálják meg (kábelcsere?) és lesz-e látható eredménye.

( egeresz | 2012. 11. 05., h – 17:19 )

A problémát nem tudom korrektül megoldani.

Nem tudok olyan queue rendszerről / ütemezőről, ami az altix uv1000 cseppet sem egyszerű topológiáját figyelembe tudná venni. Hogy lehessen viszonylag kis jobot is allokálni (1 cpu), és visznyolag nagyot is (1000 cpu). Hogy lefuthasson 10000 darab single -thread job jó hatásfokkal. Hogy ne fragmentalódjon szét az egész apróra.

( bajnokk | 2012. 12. 04., k – 15:48 )

UPDATE: válaszolt az SGI.

There is a new sysctl which prevents oom from printing memory statistics. The kernel holds a global lock while doing so and on large machines this can take a long time when no other activity is possible. It will resolve the customer's problem in the short term until the proper fix is available from Novell. Once installed and rebooted, you need to set the following sysctl: # sysctl vm.oom_show_mem=0

Erre nagyon kíváncsi leszek. Sajnos most átépítik a gép alatt az épületet, ezért még néhány napig nem fogom tudni kipróbálni.

Bosszant, hogy az oom_show_mem opcióról nem tud a google (wtf?!), pedig szeretnék többet tudni róla.

Az SGI-nek vannak kernelprogramozoi, de javareszt SUSE-t hasznal.

"printing memory statistics. The kernel holds a global lock while doing so"

ez alapjan az mm/oom_kill.c -ben van egy dump_header() nevu rutin, ami hivja a dump_tasks() nevu rutint, ami tenyleg eleg sok mindent csinal lock alatt.

viszont a hivasa a legfrissebb kodben: 


	if (sysctl_oom_dump_tasks)
		dump_tasks(memcg, nodemask);

tehat a git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -ben mar bennevan.

A dump_task() nem csinal semmi ertelmeset, amennyiben nem akarsz utananezni, hogy mi volt a helyzet az oom esemenykor.

itt egy patch, ami egyaltalan beletette a dump_task() rutint ezzel a sysctl -lel egyutt. De akkor meg default off volt.
David Rientjes rientjes@google.com Thu, 7 Feb 2008 08:14:07

Itt egy masik patch, ami ezt a defaultot on -ba tette.
David Rientjes rientjes@google.com Tue, 10 Aug 2010 00:18:53 +0000 (17:18 -0700)

A leállás után kipróbáltam az SGI-s custom kernelt, és láss csodát, az (oom_show_mem kikapcsolásával) szinte azonnal, alig észrevehető bizonytalankodás után helyreállt a rendszer OOM után az ezer processzorral.

DE: a custom kernellel 30% felett volt a gép csomagvesztése, ezért nem maradhatott a gépen. :(

És mivel nem adtak hozzá értelmezhető információt, a komplett kernelfát kellett volna diffelni, hogy megnézzem, hogy miket változtattak benne. Ha valakit érdekel, oda tudom adni a kernel-source-foobar.rpm -et tanulmányozásra. Mivel most ismét fut a gép, nem nagyon tudok tesztelni, pedig azóta már van újabb custom kernel. (Éljen a nyílt fejlesztési modell. google://oom_show_mem :/)

( egeresz | 2012. 12. 17., h – 17:10 )

Gondoltam haladok valamit ezzel is,
írtam egy 'lagmeter' programot, ami egy ciklus{ usleep(1) } jellegu cucc, es azt meri, hogy tenylegesen mennyi ideig is tart egy ciklus.

Kozben fut a 'memeater' ami triggereli a oom_killert. Cpuset felsetapolva, vm.overcommit_memory es vm.overcommit_ratio a szokasos 2/97 erteken, swap nincs, debian gyari 2.6.32-5-amd64.

Az elso futtatasnal 2.46 masodperces lagget mert a lagmeter.
A masodik futtatsnal nem mert lagot. Es a 'sar -B 1' sem laggolt szemre.

Itt egy kis dmesg reszlet:

[1048653.284355] memeater invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[1048674.047655] Killed process 19521 (memeater)

[1048726.152085] memeater invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[1048746.909093] Killed process 19529 (memeater)

[1048788.352354] memeater invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0
[1048809.033438] Killed process 19532 (memeater)

Az elso teszt 21 masodpercig loggolt, a masodik 20 masodpercig, 21 masodpercig. Itt nincs lathato kulonbseg.
A 'memeater' ezt a 20-21 masodpercet megvarta.

Vajon ez a eloszor mert 2.46 masodperces leak az addig tartott, amig a cpu l1/l2/l3 cachebe be nem kerult valami kernbel belso info?
Akkor a kovetkezo teendo cpu cache kiurites. Ezt 48x bzip2-nek hivjak. Lacosnak pont van egy olyen progija ;)

Igen, ugy tunik, hogyha minden cpu cache valami mast tartalmaz, akkor laggol az oom_killer eseteben. Szinte teljesen merhetetlenne teszi az ugyet...
Raadasul a lagmeter hol mer, hol nem mer ertekelheto lagget. Ugy nez ki, at kellene irni pthread alapura, de legalabbis forkolosra.

Folyt. kov.

Át kell írni pthread alapúra

wc -l lagmeter.c meeting.h
288 lagmeter.c
103 meeting.h
391 total

Nem kicsit elszállt ez a probléma. Ez a lag dolog jó nehezen mérhető. Egész éjjel gondolkodtam a task meeting implementáción. De most komolyan. ezzel álmodtam is. Meg azon is, hogy tényleg szükséges-e, hogy a taszkok rendkívül precizen szinkronban fussanak. (Szükséges, különben van lag, amit nem veszel észre).

(mellékszál: ez a 48 magos opteron linux 2.6.32-5 -tel nem teljesít szépen 32 mag felett, olvastam is valahol, hogy az ujabb linuxokban drasztikusan megnövelték a 32 mag feletti teljesítményt)

De legalább értékelhető eredményt ad a lagmeter.
48 magon terülve, szálak bindelve az adott magra, többszöri, reprodukálható eredmények:

alap rendszer (egy sar -B fut, meg a lagmeter)
alap maximum lag: 0.02 sec
oom_killer triggerelve: (sar -B, lagmeter, memeater)
oom lag: 20.7 sec (20.70, 20.75, 20,78, 20.75)

Szóval, másfél napnyi munkával biztosra állítható, hogy ezen a rendszeren 20.7 sec az oom_killer által hozott lag. Huh, lehet továbblépni :-)

Ezúton is köszönettel tartozom James Carter Organ Trio -nak a fejlesztésben való közreműködésért :-)

a debian/stable linux 2.6.32.5 -ös kerneljében az sysctl vm.oom_dump_tasks értéke alapértelmezetten 0. Vagyis az oom_killer nem ír processzlistát a dmesg -be.
Ezt bekapcsolva (echo 1 > /proc/sys/vm/oom_dump_tasks) az oom_kill által okozott lag 22.4 másodpercre nő (22.38, 22.43, 22.43)

A lag növekmény szignifikáns, és nem is csekély (10%).

Na, akkor most mit fogok csinálni? :-)

Módosítottam a debian/stable kernelt a következő pontban:

kernel_source/mm/oom_kill.c

erről: 


                show_mem();
                if (sysctl_oom_dump_tasks)
                        dump_tasks(mem);

erre: 



                if (sysctl_oom_dump_tasks){
                        show_mem();
                        dump_tasks(mem);
                }

Az első verzióban a show_mem() lefut minden oom eseménynél, a másodikban nem ( vm.oom_dump_tasks ezen a rendszeren nulla).

Ezzel végeztem egy új lag mérést, és azt tapasztaltam, hogy ugyanezen a 8 nodes, 48 cores gépen, a fent ismertetett beállításokkal az oom_kill miatti lag lecsökkent 0.5 másodpercre! (0.57, 0.53, 0.71)

Ebből származóan:
- az sgi mérnökei jó munkát végeztek, tényleg ez a show_mem() adja az oom_kill lag többségét (nálam 20 másodpercet).
De, hogy az általuk adott patch mit csinál e néhány soron kívül, az passz :-)

Megjegyzés:
Nekem egy hetembe került, mire sikerült a debiántól _tényleg_ azt a forrást feltennem, amiből a gyári kernelt építették. Debian power. Eheti tanulság:
az 'apt-get source' nem jó forrást szed le a futó kernelhez. Tessék a rendszergazdai apt-get install kernel-source...' paranccsal machniálni.