![ICQ [62610883]](http://blog.air4web.com/bblog/templates/markon/img/icq_status/){kind=small}
Linux: propadák ve správě paměti
25.02.2006
Dlouhou dobu jsem si myslel, že Linux má rozumě řešenou správu paměti, dokonce lepší než Windows, ale to jsem ještě netušil, jak jsem se mýlil. Hodně programátorů mě už upozorňovalo, že správa paměti a priorit procesů je mnohem horší než v dnešních Windows XP, a konečně jsem se o tom přesvědčil i já.
Co udělá žrout paměti?
Včera jsem na Linuxu pustil skript, který měl převést starší databázi do nového formátu, trošku jsem ovšem nečekal, že to bude tak velký žrout paměti. Na stroji jež využívám pro testování nových věcí (kancelářský Dell pohozený pod stolem s 256MB RAM) začla velice rychle docházet fyzická pamět, potažmo i virtuální SWAP soubor o velikosti 512MB.
Jakmile běžící proces sežral všechnu dostupnou paměť, stala se pro mě neočekávaná věc, Linux vypsal hlášku o nedostatku paměti a sestřelil náhodně zcela jiný proces. Podivil jsem se a zkusil jsem to znovu, ovšem příběh se opakoval.
Linux jednoduše, když mu dojde paměť RAM sestřelí libovolný proces, který mu stojí v cestě. Nikoli proces jež zabírá skoro gigabajt paměti, ale například potřebný DNS nebo dokonce SSH server. Byl jsem neskutečně rád, že toto se mi nestalo na produkčním prostředí.
Jak dynamicky zvětšit SWAP?
Samozřejmě existuje řešení, a to je při spouštění náročného procesu zvětšit chvilkově SWAP soubor. Jak to ovšem udělat bez zvláštního oddílu? Zde máte menší příklad, jak rozšířit SWAP chvilkově za běhu o 4GB.
dd if=/dev/zero of=/tmp/.swap bs=1M count=4096
/sbin/mkswap /tmp/.swap
/sbin/swapon /tmp/.swap
Tento trik vytvoří swapovací soubor v adresáři /tmp o velikosti 4GB.
Bude to trochu jinak od Petr Šnajdr
25.02.2006 #Ten popis neříká vůbec nic o kvalitě memory managementu Linuxu a je souhrou údálostí a administrátorských pochybení
1. Linux určitě nesestřelí náhodně vybraný proces. Ovšem sestřelí proces, který se pokusí ve chvíli nedostatku paměti nějakou paměť alokovat a počítá s tím, že se mu tato opera vždy povede.
2. Pokud tvůj program by měl lépe ošetřenu alokaci paměti, pak by systén neměl mít důvd proč ho killnout.
3. Pokud se ti zdá, že se program chová nekorektně i když z pohledu OS to korektní je (až na to, že ho to položí na kolena a to by bylo stejné Linux, nelinux všude), pak tomuto programu pomocí ulimit vytvoř prostředí, které mu takovou rozpínavost nedovolí. Zvlášť na produkčním serveru by bylo lépe aby byl nejdříc ukončen tento program než na nedostatek paměti upadlo něco jiného. Ale musíš to OS nějak říct, že to tak chceš, jinak je spravedlivý ke všem stejně.
Re: Linux: propadák ve správě paměti od markon
25.02.2006 #Petr Šnajdr: Sestřelilo mi to třeba proces NAMED a ten považuji za relativně solidně napsaný. A jinak já porovnávám hlavně s Windows, kde se toto opravdu nestane. Když pustím Adobe Photoshop a edituji obrázek o velikosti řekněme 400MB, tak možná spadne Photoshop, ale určitě to nesestřelí službu.
Ještě se mi ve Windows nestalo, aby nenažraný program sestřelil službu na pozadí, to považuji za značnou chybu linuxové správy paměti. Protože když někdo narazí na nějakou chybu v démonu, tak přes jednoduché buffer overflow může takřka sestřelit celý server.
Spíš by mě zajímalo, jestli neexistuje v Linuxu nějaké rozumější řešení než každému programu nastavit ulimit, což je podle mě v praxi nerealizovatelné.
od llook
25.02.2006 #Nemáš náhodou aktivovaný overcommiting (viz http://www.abclinuxu.cz/...cirstvi/2005/5/25/88308 )? Jinak v diskuzi pod tím článkem co odkazuji je celkem užitečný odkaz - swapd: démon, který v případě nedostatku paměti sám přidá swap.
Cim to bude? od Mordae
25.02.2006 #> Windows, kde se toto opravdu nestane. Když pustím Adobe
> Photoshop a edituji obrázek o velikosti řekněme 400MB, tak
> možná spadne Photoshop, ale určitě to nesestřelí službu.
Mozna proto, ze pri alokaci 400M je docela slusna sance ze zrovna on bude na rane... :]
Ono to neni s ulimit tak zle :-) od Vaclav Stepan
26.02.2006 #Toz ale ono to pouziti ulimit neni az takovy problem - ta nastaveni se totiz dedi. Takze staci, kdyz vhodne nastaveny ulimit pridas do .bashrc uzivatele nebo neco tak - a jak se pousteji deti shellu pusteneho pri prihlaseni, uz maji tenhle limit zdedeny. Jedine se muzou samy omezit jeste vic, ale ne si ho zvednout.
Ze to normalne neni nastavene souvisi s tim, ze jak to dobre nastavit zalezi na tom, k cemu ten system normalne pouzivate.
Kdyz je to single-user workstation, je logicke mit ulimit skoro na hranici dostupne pameti. Kdyz to je ale server, kde pracuje tech uzivatelu desitky, tak to takhle jednoduse udelat nejde - a jak to konkretne bude optimalni...
A k tomu, co kernel zabije - on nezabiji nahodne.
Coz je celkove zcela smysluplne -- na Windows se mi pri podobnych pokusech celkem bezne stava, ze system dostanu do stavu, ze jenom swapuje, ale uz vubec nic jineho - treba ctvrt hodiny, nebo nez mne to prestane bavit. Ze Photoshop spadne jeste pred tim, nez dojde pamet systemu, je spis jeho problem
od Keff
26.02.2006 #btw, zrovna Photoshop problemy mit nebude - ma svou vlastni virtualni pamet, a proto nikdy nezabira ani o mega vic nez ma v nastaveni.
od Martin 'Bilbo' Petricek
28.02.2006 #Ulimit to resi, jen ho nastavit
)
, takze obcas odstreli i par veci co nema nez se trefi do toho "spravneho".
Jinak nekde v kernelu lze i nejak nastavovat strategie pro strileni procesu pri overcommiting.
Bohuzel kernel strili dost od boku (nevi ktery procesy jsou pro mne dulezity a ktery ne ... navic u kazdyho cloveka je to jiny
od Pihhan
01.03.2006 #1) nevim jak mate psanou tu dabatazi, ale myslim, ze prevod z jednoho formatu do druheho obvykle nepotrebuje 4GB. Nemam moc velke servery, ale na svych serverech jen jeste nedelal swap vetsi nez 512MB, a vzdycky mi to stacilo.
2) nepises, jestli jsi to pustil jako root. Pokud ano, tak si za to muzes ze 2 duvodu. Nemas poustet takove molochy jako root, protoze procesy roota kernel nezabiji tak casto jak ty ostatni. Ma se za to, ze pokud spravce se snazi vyresit problemy v systemu, tak neni dobre mu to v puli utnout. Proste root se nestrili ihned. To, ze riskujes cely systemu kvuli prevadeni jedne databaze je nedobry zvyk obvykly ve windows, kdy administrator je na vsechno. Toho zvyku je dobre se zbavit, bez ohledu na system.
3) jak ma kernel poznat,ze pri prave provadene operaci nema sestrelit oracle s 2G zabrane pameti, kdyz cely problem zpusobi nejaky program ktery zabira normalne 1M a ted nabobtnal na 300? To reseni neni trivialni a v nekterych pripadech se to hodi vic, nekdy min. Resenim je uspornejsi program na pamet, ktery na pretvoreni databaze nepochybne nepotrebuje mit celou databazi naraz v pameti.
Krom toho, je pravdu vytecne delat rychle zavery nad systemem, kteremu ne uplne rozumim po jedine udalosti.
Re: Linux: propadák ve správě paměti od Majkls
12.05.2006 #Řekl bych, že na správě paměti se dají utopit i jiné systémy. Pokud neznáte tuhle hlášku, tak si ji dobře pamatujte: unix je tak dobrý, jak je dobrý jeho root. Nic víc nic míň. Jinak zrovna o task schedulleru a dalších věcech by se dalo dlouho hovořit. Je jednoduché napsat, že něco stojí za houby, ale už horší je vědět proč. Systém ještě nikdy sám o sobě dobrého administrátora nevychoval
. A člověk se musí zajímat. Třeba forkbomb. Ten dokáže složit jakejkoli systém - i *BSD, pokud není nastavený maximum procesů. Nezkoušet na produkčním stroji 
Jinak byl jsem zvědav, když procesu nechám sežrat paměť. Udělal jsem si prográmek - lehce hamižnej.
#include
#include
int main(void){
while(1){
malloc(10000);
}
return 0;
}
a jak to dopadlo...?
majkls@majkls:~$ ./test2
Zabit (SIGKILL)
(po 5 minutách chrastění disku.)
Re: Linux: propadák ve správě paměti od merlyn
27.08.2007 #No, od té doby co používám BSD systémy, tak s pamětí problém nemám. Jen vždy posloucháv bratrance gentoočkaře, jak už zase nemá RAM