Re: podivné problémy s alokací paměti / CentOS 6.2 na VPS

[Pavel Kankovsky]

On Wed, 29 Feb 2012, Tomas Vondra wrote:

> Dnes večer to opět vyhodilo pár OOM hlášek - nejdříve mezi 17:22 a
> 17:30, pak kolem 19:15. Přitom podle "sar -r" byla situace takováhle:

U první události se nic poznat nedá, kromě toho, že to asi celé chcípnulo.

U druhé události je vidět, že se tam něco neobvyklého dělo (vyhodil jsem 
sloupec %commit, který je podle toho, co píšete, stejně spíš zavádějící)

18:00:01    kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit
19:00:01       187992    314736     62,61     17068    138264    358120
19:10:01       172836    329892     65,62     18176    158256    354640
19:20:01        74268    428460     85,23      5912    261548    364168
19:30:02       275624    227104     45,17      6152     66876    362896

Mezi 19:10 a 19:20 musela proběhnout nějaká dost značná aktivita, která 
způsobila nárůst kbcached a mezi 19:20 a 19:30 zase něco jiného kbcached 
srazilo dolů.

Změnu mezi 19:20 a 19:30 by mohlo být možno vysvětlit tak, že něco 
alokovalo cca 200 MB RAM a vzápětí skončilo a zase jí uvolnilo.

Změna mezi 19:10 a 19:20 je méně jasná. Je ale evidentní, že se to muselo
v určitém okamžiku ocitnout v situaci, kdy bylo volné paměti hodně málo, 
protože měl potřebu redukovat buffery.

Problém saru v takových situacích je nedostatečné rozlišení a to jak
z hlediska času tak z hlediska rozlišení jednotlivých procesů. Pomoci 
může process accounting, ale ten má zase slepou skvrnu u dlouho běžících 
procesů. Možná by se něco lepšího dalo postavit nad taskstats, nevím, 
jestli už někdo něco takového udělal.

> Jediné co mne napadá je že se do toho commit limitu možná nějak divně 
> počítá paměť sdílená více procesy (např. shared segmenty ...).

Možné je leccos, ale toto asi není správné vysvětlení.

A propos, ještě jedna věc, kterou jsem si předtím úplně neuvědomil a
ukryl jí za frázi "rozumná rezerva":

Veškerá práce se soubory, což zahrnuje i kód spuštěných programů (!) spadá 
tedy do kategorií buffers a cached a musí se vejít do prostoru, který
v RAM zůstane po odečtení commited z jedné strany a toho, co spotřebuje 
jádro pro vlastní potřeby z druhé strany.

Pokud nastavíte overcommit_ratio tak, že pro kbcached může zůstat méně než 
je velikost adekvátní části pracovní množiny spuštěných procesů, tak si 
koledujete o brutální thrashing. (Nepopisujete, k čemu došlo mezi 17:20
a 17:30, ale moc bych se nedivil, kdyby chcípnul právě takto.)

Upřímně řečeno si myslím, že nikdo nikdy neočekával, že 
overcommit_memory=2 bude někdo někdy chtít použít bez swapu.

Také jsem asi ze spotřeby jádra v původním popisu vynechal VmallocUsed 
(ono se to bere z virtuální paměti, ale bez swapu je to fakticky RAM). A 
asi by se tam měla zohlednit i hodnota min_free_kbytes. Ono je to obojí 
obvykle jen pár mega, ale pokud necháváte rezervu o velikosti 10 MB, tak 
už to může být chyba dost významná.

-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /