Memory overcommitting - ráj nebo peklo?

25.5.2005 20:33 | Přečteno: 1916× | Ze života

Je příjemné alokovat si více paměti, než je k dispozici. Na druhou stranu, má to dost nepříjemná úskalí. Mnohokrát jsem o tom přemýšlel, ptal jsem se řady lidí na jejich názor, ale jisté zůstává jenom jedno - je to záležitost vysoce kontroverzní.

Pravděpodobně všichni vědí, o co jde - ale raději to aspoň ve stručnosti nastíním:

Pokud se alokuje paměť (např. funkcí malloc() v jazyce C), paměť k dispozici buďto je (a v tom případě volání skončí úspěchem, paměť se alokovala), anebo není (a volání skončí neúspěchem). Protože programy obvykle alokují více paměti, než jí pak skutečně využijí (je to z různých důvodů, někdy je skutečné využití velmi malé, např. u málo vytížených serverových aplikací), používá se technika zvaná overcommitting (česky bych řekl třeba "přealokace", ale není to přesné). Z pohledu aplikace to vypadá tak, že alokace skončí vždycky úspěšně, i když dané množství k dispozici není. Většinou to není problém, systém úspěšně funguje.

Problém nastane, když je alokováno víc paměti, než může systém dát k dispozici (když selžou veškeré pokusy o uvolnění paměti). Pak nastupuje hrubé násilí - v Linuxu reprezentované procesem oom-killer. Ten se spustí ještě dřív, než k dané situaci dojde (spouští se při poklesu volné paměti pod určitý práh) a vytipuje vhodné kandidáty na odstřelení. Pokud už skutečně není volná paměť, oom-killer zlikviduje proces, který byl nejžhavějším kandidátem. A tak pokračuje tak dlouho, dokud nejsou požadavky uspokojeny.

Otázka je, zda je použití overcommittingu vůbec výhrou. Jednoznačná odpověď není, čím dál víc jsem ale přesvědčen, že minimálně v prostředí, kde požadujeme stabilitu, své místo nemá (jen pro úplnost - overcommitting lze snadno vypnout). Poměrně snadno lze totiž takový systém destabilizovat.

Před časem jsem si tu stěžoval na problémy s X.org v souvislosti se zběsilou alokací paměti. Tato alokace souvisela s prohlížečem Opera, nicméně paměť alokoval X server. A nejen že alokoval, ale také nějak používal (podrobnosti neznám), takže brzy (za několik sekund) došlo k tomu, že se vyčerpala veškerá paměť včetně swapu a došlo na nejhorší. To co se dělo dál, nešlo předem předvídat - oom-killer (aspoň ten v jádře 2.6.10) je špatný střelec a svůj cíl si často vybere nevhodně. Takže i když by měl být sestřelen původce (tj. X server; správněji spíš Opera, ale takovou inteligenci od "ničitele" chtít nemůžeme), odnesl to často jiný, zcela nevinný proces.

Jaké nebezpečí z toho plyne, je zřejmé. Jakýkoli program, který v systému běží, ho snadno může zásadním způsobem poškodit, aniž by dělal nějakou složitou činnost. Stačí pouze alokovat paměť. Bez overcommittingu by jeho alokace byla prostě najednou neúspěšná, a i když by se mu podařilo vyčerpat volnou paměť, přímé následky by nebyly. Kdežto takto by mu mohlo za oběť padnout i několik procesů, než by byl sám sestřelen.

Nechávám celou věc otevřenou, jednoznačný názor jsem si neudělal. Jen si říkám, zda cena, která se platí za možnost "kouzelného nafouknutí" paměti, není příliš vysoká.

       

Komentáře

[Michal Marek (twofish)]

Důvod pro tuhle strategii může být ten, že glibc si paměť alokuje po větších kusech, aby nemusela moc často volat brk() nebo mmap(). Podobně se chovají některé algoritmy v jiných knihovnách / aplikacích (např. při zvětšování pole se malloc()uje dvojnásobek původní velikosti). Tudíž pár stránek nakonec zůstane ležet ladem. Ale zdůvodnění od někoho fundovanějšího by mě docela zajímalo

PS: limity nejsou špatná věc...

[Luk]

Tohle je jasné. Ostatně u souborů se používá něco podobného - také lze vytvořit soubor určité velikosti, ale bloky se ve skutečnosti alokují až v případě potřeby ... a tehdy už nemusí být k dispozici (ale tam to není taková tragédie).

Jinak ještě k oom-killeru - nevím, jak kvalitně funguje teď, ale v jádrech řady 2.4 s ním byly takové problémy, že byl v jednu chvíli prakticky odstraněn (resp. nevybíral kandidáta, nýbrž sestřelil proces, který potřeboval paměť).

[doubleZ]

kernel 2.4.29, me sestrelil nejen proces, ktery potreboval pamet, jez neexistuje, ale i jeho rodicovsky proces se vsemi ostatnimi child

[Michal Marek (twofish)]

oom_kill.c ve 2.6.11 na mi první pohled přijde stejný jako ve 2.4, a funguje tak, že X server by neměl zabít skoro nikdy: Zvýhodňuje totiž procesy běžící pod rootem a procesy, které spotřebovaly hodně CPU času (komentář: "There is no particular reason for this other than that it turned out to work very well in practice." ).

Ono zabít X server SIGKILLem by stejně nejspíš znamenalo reboot, protože bůhví v jakém stavu by zůstala grafická karta...

[Luk]

Ale v případě, který jsem popsal (a který se mi s X.org stával - nyní s XFree86 už naštěstí ne ), alokoval právě X server (ale čert ví proč - bylo to kvůli nějakému požadavku Opery). Pokud je to právě takhle, tak je chování oom-killera logické, ale v daném případě nic neřeší - dokud žije X server nebo Opera, problém přetrvává.

Jinak po odstřelení X serveru se to chovalo korektně, normálně nastartoval (s kartou nVidia, modul "nv"), reboot nebyl potřeba. Ale s danou verzí Opery + X.org se dala situace (zobrazením toho "správného" webu) kdykoliv navodit znovu (čili bylo to systematické).

[doubleZ]

tak se mi to povedlo mno, vystup byl fakt divnej ;) na tty7 (alt + F7) jsem mel pochybne znaky vypadajici jako hebrejstinoazbukocinstina a nova xka nabehla na 8micku

[doubleZ]

myslim si, ze nekdy tato cena vysoka opravdu je, zrovna pred dvema dny jsem si takto nechal prizabit Xka, kdyz jsem za pomoci Wilbura (GIMPU :) naprosto vymrhal ramku i swap, kdy alokace byla provedena tak obrovska,ze sezrala vsechno mozne misto, a takovy webserver, ktery lezel ladem a skladem a mam ho tu jen pro ladeni svych stranek, zustal bez povsimnuti a me to zabilo naprosto vsechno, veskerou rozdelanou praci... jenze kdyby nedoslo k realokacim pameti pro httpd tak by nenastaly takovehle problemy... nevim, je to sporne

[unchallenger]

U GIMPu je to IMO jen tvoje blbost, protože si tam můžeš nastavit, kolik paměti se smí spotřebovat na tile cache, což je ten velký žrout paměti. Takový valgrind je mnohem záludnější.

[Pmx]

Když to jde snadno vypnout (jedním echo někam do /proc jestli se nemýlím), tak si snad každý může vybrat, co pro něj lepší jest, ne? :) Lepší, než kdyby vyšší síly (kernel maintaineři) rozhodly takto za nás. Takže moc nechápu kritický tón tohoto článku, ale jinak je přínosný popisem problematiky, která podle mě Jediné správné(TM) řešení zatím ani nemá...

Tak mě napadá - dal by se udělat prográmek, který v takové těžké chvilce paměťového nedostatku vytvoří na disku nějaký soubor jako další (dočasný) swap...

[Libor Klepac]

swapd?

[Triton]

Tak jsem si na jednom desktopu(kernel 2.6.11.10) defaultně ten overcommit vypnul a zkusím alespoň týden testovat, jestli to bude použitelný.

[Mikuláš Patočka]

Kdyby overcommit byl vypnut (což snad ani nejde), byl by na tom systém ještě hůř ... nějaký proces sežere veškerou paměť, a ty se pak už nepřihlásíš ani ze sítě ani z konzole (protože programu sshd a login je odepřena paměť). V případě, že jseš přihlášený, tak toho žrouta paměti taky nezabiješ, protože program kill nedostane žádnou paměť. Eventuálně bash vůbec nedostane paměť, do které si ukládá stisklé klávesy, takže ani nic nenapíšeš.

Pokud vypneš oom-killer, tak ti to zastřelí proces, který o paměť naposled žádal, takže k výše zmíněnému scénáři může a nemusí dojít.

Nejlepší by v takové situaci bylo vytipovat uživatele, jehož procesy žerou nejvíc paměti a tomu zabít proces, který nejvíc žere.

X-server se bohužel zabít nesmí, protože nechá grafickou kartu v neznámém stavu (schválně si ho zkus zabít pomocí kill -9 --- ale pak už ti nezbyde nic jiného než ctrl-alt-del).

[Martin Vidner]

V případě, že jseš přihlášený, tak toho žrouta paměti taky nezabiješ, protože program kill nedostane žádnou paměť.

Proto je taky kill zabudovany prikaz shellu (prinejmensim bash a zsh).

[Luk]

1. Overcommit vypnout jde (viz třeba "man malloc")

2. Rozdíl je v tom, že bez overcommittingu nějaký proces "jen" nedostane paměť (ale může žít dál, pokud je napsaný tak, aby se z toho vzpamatoval), kdežto oom-killer rovnou zabíjí, což není úplně nejčistší.

3. X server nejen že se zabít smí, ale on se dokonce i zabíjí (viz můj příklad) - aspoň v jádře 2.6.9 ve FC. Zabití pomocí kill -9 nemá fatální následky, dopadne (aspoň u mě) úplně stejně, jako kdybych stiskl Ctrl-Alt-BkSp.

[doubleZ]

ano, smi, stava se to, viz take muj priklad, nevim kde kdo vycetl ze nesmi, me to melo temer shodny efekt jako Ctrl+Alt+BkSp, jen se spustil na novym screenu a stary nechal spadly, myslim, ze kdybych na nem dodatecne dal reboot xek tak by tam zas nabehly...

[#Tom]

Overcommit je jednoznačně na škodu, uvítal bych, kdyby byl implicitně vypnutý, nelíbí se mi, že při startu systému musím použít tohle:

  echo 2 > /proc/sys/vm/overcommit_memory

Nejhorší zkušenosti s nedostatkem přealokované paměti mám taky pod Xkama, pravým původcem je pro změnu Mozilla/FireFox (je jedno, co je to za verzi). Poprvé jsem si toho všiml na své celkem nevinně vyhlížející stránce s naskenovanými skripty. Na novějších počítačích s větší pamětí (>= 512 MB), nebo i na starších s Konquerorem (nebo s Mozillou/IE pod Windows) nehrozí žádné nebezpečí, pod Linuxem s Mozillou/FireFoxem a 256 MB RAM+128 MB swapem to ale končí špatně...

P.S.: Ta stránka obsahuje jen 96 PNG obrázků s celkovou velikostí cca 2,5 MB.

[petr_p]

Tech 96 obrazku ale ma 84 Mpixelu. Pak taky musis zvazit, ze drawable Firefoxu ma nejakou barevnou hloubku. Takze kdyz to zabere pres 200 MB, tak se neni cemu divit.

[#Tom]

Chybička se vloudila - nahrál jsem tam jen 61 obrázků (1.8 MB), o to ale nejde. Rozměry jsou vždy přibližně 1000x1500, tak mi vychází cca 90M pixelů. To je hodně, FireFox zřejmě nepočítá s tím, že mu budou podstrkovány takovéto stránky. (Konqueror je v tomto o dost lepší.) Ale hlavní je, že s povoleným overcommitem tak může Linux úplně spadnout úplně snadno jen kvůli otevření jednoduché (a - to uznávám - ne zrovna pěkně udělané) stránky.

[Libor Klepac]

hmm

echo "vm.overcommit_memory = 2" >> /etc/sysctl.conf

?

[#Tom]

Rada je to pěkná, jenže obsah souboru /etc/sysctl.conf se sám nezavede, nejdřív někdo či něco musí spustit třeba /sbin/sysctl -p. Takže se tím neřeší nic... Nebylo by od věci si ten overcommit zakázat rovnou ve zdrojácích jádra

[Libor Klepac]

hmmm

:cat /etc/init.d/procps.sh  | grep sysctl
# /etc/init.d/procps: Set kernel variables from /etc/sysctl.conf
[ -x /sbin/sysctl ] || exit 0
               if [ ! -r /etc/sysctl.conf ]
               eval "/sbin/sysctl $n -q -p $redir"

[Libor Klepac]

no ten grep dopadl teda

[VícNežNic]

Já to tak píšu odjakživa a ještě mi nikdo nic neřekl

[Libor Klepac]

ja myslel, ze pod sebe prisly ty radky tak, ze to vypada, ze kdyz tam neni ten soubor, tak ze se pouzije

[VícNežNic]

Je to grepnutý, tak to dá rozum… Já myslel, že myslíš to s tím grepem a catem

[#Tom]

Proč ne Ale není to v každé distribuci, přidávat něco takového jen kvůli overcommitu je na nic...