Out of memory - paměti na serveru je dost

[pakozdy]

overcommit je vypnuty  vid: sysctl.conf  vm.overcommit_memory = 2
oom_killer vypise problemovy proces, ale vzdy ide o rozne  mysql, apache, bash skript cron.

Ale každý proces stejně dokáže naadresovat — všimněte si, nepíšu naalokovat — pouze 3 GB viruálního adresního prostoru. Proces tak může mít naalokováno třeba jen 300 MB fyzické paměti, ale může havarovat na nedostatek virtuální paměti (přes 3 GB).

To ale přece nevyvolá OOM killer (který se navíc nevyvolává při alokacích, ale až když začneš namapované stránky špinit), ale malloc/sbrk mu prostě vrátí -1, ne?

Pro tazatele: můžeš vypnout memory overcommit? Teoreticky by se pak v logu mohl ukázat proces, který to _opravdu_ způsobil.

[Reklama]

[trubicoid2]

vymena jadra je trocha problem - je to proste konzerva do ktorej nikto nechce velmi sparat. navyse gentoo vidim prvy raz a s kernelmi som na tejto distribucii nerobil takze je tam vysoke riziko uplneho polamania.

na gentoo si kazdy jadro kompiluje sam  anebo genkernel, ale to je jen pro baby 

tak nekam dej .config a ja vyrobim 2.6.39, ten se mi tu zkompiluje gcc4.9.4 jen s jednou opravou, 2.6.27 tam tech problemu ma vic

[pakozdy]

dik za ponuku, ale musim pockat na vyjadrenie k zmene kernel-u, nezalezi to iba na mne.
v podstate by chceli aby to chodilo ale aby sa tam nic nezmenilo :-)

[trubicoid2]

v podstate by chceli aby to chodilo ale aby sa tam nic nezmenilo :-)

haha, no jo managori

vsak to muzete vyzkouset na necisto na jinym stroji, naklonujes, vsechno stejny, jen jadro 64b a kdyz to prestane delat, tak to pochopi i managori , snad teda

[trubicoid2]

jestli by teda chteli, aby se nic nemenilo, tak bych doporucil cron job, ktery kontroluje, co bylo zabito a pousti to znova 

[Reklama]

[Havis911]

Ja by som problem videl prave v tom, ze je vypnuty overcommit_memory, pretoze default overcommit_ratio=50 (t.j 50% (RAM + SWAP)) pri zapnutom heuristickom overcommite (overcommit_memory=0)
Ak je overcommit_memory vypnuty (tj. nastaveny na 2), overcommit_ratio by malo byt nastavene na hodnotu 100 (100% (RAM + SWAP))
echo 100 > /proc/sys/vm/overcommit_ratio

ak to nepomoze, skus nastavit defaultne hodnoty pre overcommit_memory a overcommit_ratio
echo 0 > /proc/sys/vm/overcommit_memory
echo 50 > /proc/sys/vm/overcommit_ratio

Este pozri ake je vytazenie swapu, podla vypisu z meminfo mas 64GB RAM a 16GB SWAP.
Ak sa ti spusta nejaky cron proces ktory cita vela suborov, je mozne ze defaultna hodnota swappiness=60 moze sposobovat problemy. (t.j. extremne sa zvacsi suborova cache, a aktivne procesy mozu byt odswapovane a potom nasledne zostrelene OOM)
Skus nastavit swappiness na nizsiu hodnotu (default je 60% RAM)
echo 10 > /proc/sys/vm/swappiness

Update kernelu by som videl ako poslednu moznost, a rozhodne by som najskor naklonoval system do virtualky a tam sa s tym pohral, a poriadne otestoval kombinaciu novy KERNEL + stare GCC & stare GLIBC.

[Havis911]

Az teraz som si vsimol, ze ste postli vas sysctl.conf

vase hodnoty:
# oom_kill zmeny
vm.overcommit_memory = 2
vm.overcommit_ratio = 75

Pri vypnutom memory_overcommit, by malo byt overcommit_ratio nastavene na hodnotu 100 (100% (RAM + SWAP):
vm.overcommit_memory = 2
vm.overcommit_ratio = 100

[Jenda]

Pri vypnutom memory_overcommit, by malo byt overcommit_ratio nastavene na hodnotu 100 (100% (RAM + SWAP):
vm.overcommit_memory = 2
vm.overcommit_ratio = 100

Z dokumentace jsem nabyl dojmu, že to znamená (100% RAM) + SWAP.

Anyway, i když má blbě overcommit_ratio, tak při overcommit_memory = 2 by se OOM killer neměl vyvolávat vůbec nikdy, ne? Nebo chápu fungování overcommitu úplně blbě?

[trubicoid2]

teoreticky by to melo OOM vypnout, ale prakticky se toto nastaveni na produkcnim serveru nedoporucuje:

http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

bych zkusil mozna overcomit vypnout a podle toho navodu zde ochranit pred oom proces, ktery chci aby nebyl zabit

stejne to dlouhodobe vidim na nutnost toho 64b kernelu

[Tuxik]

pane Linusi... můžeš prosím poslat výstup

Kód: [Vybrat]

uname -a a

Kód: [Vybrat]

cat /proc/cpuinfo(u cpuinfo stačí jedno jádro)
ať se tu případně neřeší blbosti?

[ByCzech]

stejne to dlouhodobe vidim na nutnost toho 64b kernelu

Prošel jsem celou diskuzi a nevšiml jsem si, že by tazatel dodal informaci o tom, jestli má 64 bit kernel nebo 32 bit s PAE. Pokud je to druhá možnost, platí co bylo napsáno výše o omezení virtuálního paměťového jednotlivých aplikací a 64 bit kernel to nezachrání, protože má podobné omezení pro 32 bit aplikace. I když to může pomoct a problém (na čas) vyřešit, protože u 32 bit kernelu má 32 bit binárka omezení na 3 GB, zatímco s 64 bit kernelem má omezení na 4 GB. Aby mohly aplikace využívat více, musejí být také 64 bit.

[Lol Phirae]

No, vidím, že stále "řešíme"... Prosímtě, pokud chceš skutečně něco řešit a ne "řešit", tak si nainstaluj normální aktuální stroj s amd64 architekturou, tam začni testovat a až to bude otestované a ready, tak to přepni "konzervu" zlikviduj.

Jako provozovat x86 instalaci s 32bitovým jádrem 2.6.x na stroji s 64GB RAM je prostě hyperkokotina, sorry jako. O strategii "konzerva" ani nemluvě, co to je proboha za nápad nic neaktulizovat? To ty hromady děr nevadí?

[Trident]

stejne to dlouhodobe vidim na nutnost toho 64b kernelu

Prošel jsem celou diskuzi a nevšiml jsem si, že by tazatel dodal informaci o tom, jestli má 64 bit kernel nebo 32 bit s PAE. Pokud je to druhá možnost, platí co bylo napsáno výše o omezení virtuálního paměťového jednotlivých aplikací a 64 bit kernel to nezachrání, protože má podobné omezení pro 32 bit aplikace. I když to může pomoct a problém (na čas) vyřešit, protože u 32 bit kernelu má 32 bit binárka omezení na 3 GB, zatímco s 64 bit kernelem má omezení na 4 GB. Aby mohly aplikace využívat více, musejí být také 64 bit.

Neomlouvam se. Co je to za hovadinu?
Nainstaluje 64bit kernel,64bit userspace binarky/libky, 64bit javu a mozna i ty dalsi kompotenty v 64bitu. Worst case si prehistoricky verze zkompiluje. Nema zadny nenahraditelny binarni blob az na ten java bytecode jehoz  spousteni vyresi instalaci 64bit javy. Co resis? Co furt resis za hypoteticky hovadiny ? Nepomahas.

[Homo Buzerantus]

Problém je v tom, že tam máš 32-bitový kernel (pozná se to podle "LowTotal: 387148 kB"). Celý počítač má sice 64GB paměti, ale v 32-bitovém módu je možno namapovat maximálně 4GB, z čehož 3GB jsou použity pro userspace a 1GB pro kernel. Ka každé stránce je potřeba mít alokovanou strukturu page (a někdy i další, např. buffer_head), tyto struktury se alokují z té zbylé 1GB - takže čím víc paměti v tom systému máš, tím větší část té přímo namapované 1GB je obsazena a tím větší je pravděpodobnost, že dojde k OOM. V té dolní paměti ti tam zbylo pouze 387MB, což moc není.

Řešení:
- použít 64-bitový kernel (klidně můžeš nechat existující 32-bit userspace), to ten problém definitivně vyřeší, protože 64-bitový kernel může přímo přistupovat k celé 64GB RAM.
Pokud procesor není 64-bitový, tak
- zvětšit množství paměti pro jádro a zmenšit množství paměti pro userspace - v konfiguraci kernelu v menu "General Setup" zaškrtneš "Configure standard kernel features (expert users)", pak se v menu"Processor type and features" objeví položka "Memory split" a tu nastavíš na 2G/2G. Můžeš tam nastavit i 1G/3G, ale to omezí velikost každého procesu na 1GB, takže je to použitelné pouze, pokud tam máš všechny procesy menší než 1G (zkontrolovat položku VIRT v příkazu top).
- pokud se ti nechce kompilovat kernel, tak je řešení jednoduché - ubrat tomu počítači pamět, dejme tomu na 4 nebo 8GB. Pak by se ta položka LowTotal měla zvětšit a pravděpodobnost vyvolání OOM killeru se tím zmenší.

[Trubicoid2]

- pokud se ti nechce kompilovat kernel, tak je řešení jednoduché - ubrat tomu počítači pamět, dejme tomu na 4 nebo 8GB. Pak by se ta položka LowTotal měla zvětšit a pravděpodobnost vyvolání OOM killeru se tím zmenší.

Ha, to je dobrý, méně je někdy více