Amikor a Linux kifogy a memóriából

Kernel

A LinuxDevCenter oldalon Mulyadi Santosa arról értekezik, hogy mi történik olyankor, ha a Linux kernel kifogy a rendelkezésre álló szabad memóriából. Ha ez bekövetkezik, akkor előáll az Out Of Memory (OOM) helyzet. A Linux kernel védekezni fog, és az Out Of Memory Killer-t fogja segítségül hívni. Az OOM Killer feladata, hogy megpróbáljon "rendet tenni". Az érdekes cikk itt.

( ggergely (nem ellenőrzött) | 2006. 12. 01., p – 20:25 )

múltkor így jártam. azóta sem tudom miért. és azóta sem volt ilyen. 2GB swap és 0.5GB mem telt be. pedig én csak egy scp-t indítottam el...

Nálam az Opera szokott bevadulni napi egy-két alkalommal. Kinyitok 10-15 tabot, elmegyek teáért, és mire visszajövök már nincs böngészőm... Teljesen random oldalakra csinálja, pl ha rákeresek a gugliban arra hogy "foobar", akkor meghülyül. Ha arra, hogy "Foobar", akkor meg nem. Pár nappal később új szavakat talál ki, amiket meg majd akkor nem fog szeretni. :)

( saxus | 2006. 12. 01., p – 23:16 )

Egyszer már én is szívtam meg ezzel. Nem tudtam, hogy az mc nézőkéje olyan süsü, hogy először berántja az egész fájlt a memóriába. Volt a gépben, 512 SD és 512 swap, volt egy 2 gigás fájlom, F3 rá, fél perc mulva haverom rámszól, hogy mi a f*szt csináltam, amiért esett minden (ssh, irc, web, semmi válasz). Elmegyünk helyszini kiszálásra a géphez, nézzük elvan magával. login még csak-csak ment, egyszer még a bash is bejött, de a ps -re már kiadta, hogy out of memory és ki is vágott. Nagy öröm volt.

Hmm, érdekes. Most fogtam egy Uhu 2-s gépet, 1.5 gigás fájlt rendesen megnyitott F3-mmal. (128/512 ram) GNU MC 4.6.1-ként mutatkozik be. Majd ha egyszer megint tudok szórakozni azzal a géppel, amin történt megnézem, hogy ott mi van, működik-e még.

Szerk.: Slackware 10.1, MC 4.6.0. Majd egyszer megint kipróbálom, csak most nem szeretném megkockáztatni, hogy összeomlasszam azt a gépet.

igen, az mcview csinal ilyen baromsagokat. ha megnezel egy nagy file-t, vagy ma'r nezes kozben ne'zetet va'ltaz (wrap/unwrap vagy hex/ascii), akkor is bego"zo"lhet. ilyenkor sajnos tenyleg csak az a jo megoldas, hogy masik shell megnyit, es az mc-nek kuldunk egy 9-est... de azert az relative sok ido", mig annyira behal a rendszer, hogy nehezkes lesz shell-t nyitni, legalabbis sajat tapasztalatok alapja'n.

Mint írtam, kb fél perc kellett ahhoz, hogy ledobjon mindent a netről. Lehet, hogy fél giga ram volt benne, de abból 3-400 általában foglalt szokott lenni a top szerint. Mire átballagtunk a szomszéd utcába, addig eltelt kb 6-8 perc, és vagy jó 7-8 percig próbálkoztunk vele, mire rájött, hogy jé, megnyomtuk a varázshármast is. (Haverom már resetet akart nyomni).

( dawe | 2006. 12. 02., szo – 15:56 )

Nálam az UHU 1.0 "gyári" mplayerét ölte meg mindig az OOM Killer, ha filmet néztem egy 64MB ramos gépen :). Valószínű valami memory leak volt benne, kb 50 perc után jött a biztos halál. Egy újabb verzióval már nem csinálta ezt.

Egyébként mielőtt a cikkbeli B programot kinyírná a Killer, előtte már kb. fél perccel használhatatlanná válik a gép, még az egérkurzor is akadozik. Ez egy multitask / multiuser környezetben szvsz nem túl szerencsés. Talán úgy lehetne ilyen probléma ellen védekezni, ha az OOM Killer számolna valami biztonsági tartalékkal.

( jzola v | 2006. 12. 02., szo – 21:20 )

nekem 1x apache 2.0.x csinált ilyet, gépen már csak crtl+alt+del re válaszolt, elötte az üzenet hogy kernel megprobálja apachet megölni.
utána rájöttünk hogy egy rosszul beállított rewrite miatt történt ilyen(1.5 GB ramot evett meg)
persze azóta sok ujabb 2.0.x verzió jött ki..

( turul16 v | 2006. 12. 02., szo – 22:06 )

#include < sys/types.h>
#include < unistd.h>

int main()
{
while (1)
{
fork();
}
return 0;
}

Akinek van kedve ezzel szivassa a gepet.

A memoria killerel az a baj, hogy nem a megfelelo processt oli meg mindig. Es nem is lehet igazan mindig jol mukodo szabalyt talalni ra.

Mer' mi a "megfelelő processz"? Azt egy gép hogyan tudná "megfelelően" eldönteni? Egy bonyolult algoritus alapján választ, a cél, az operációs rendszer működőképességének megőrzése. Valószínűleg a legnagyobb memóriazabálókat fogja elsősorban kinyírni. Mondjuk ha választani kellene, hogy egy tőlem 400km-re levő szerveren álljon le a MySQL vagy pusztuljon a gép teljesen, akkor jobban örülnék az első esetnek. Nyilván teljesen jó algoritmust (ami mindenkinek jó) nem lehet írni.

--
trey @ gépház

( BlinTux v | 2006. 12. 03., v – 23:49 )

En a process kilovest egy egyszeru killelo scriptel megoldotam az en OS-emnek megfeleloen. Ha kevesa memoriam, csak nyomok egy ctrl+alt+c -t es ami a listaban van azt kilovi.
Persze ezzel nem szabadul fel annyi memoria, amenyni felszabadulhatna. Mert mindig maradnak bent olyan dolgok, amik csak vannak...
Nekem valami olyan megoldas kellene, ami nem a processeket lovi ki, mert azt en is megoldotam, hanem ami tenylegessen memoriat tisztit! Ilyenrol tud valaki?

Van egy jó kis shellscript erre. Fogja a és b állományokat, melyek mérete pont fele a teljes memóriának és összediffeli őket. Asszem megmondhatod neki, hogy hányszor csinálja meg ezt a diffelést. Mondjuk már elsőre mindent kilök a memóriából, tehát fölösleges azt mondani neki, hogy csináld meg nyolcszor. :)