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

[Tomas Vondra]

On 1 Březen 2012, 11:30, Pavel Kankovsky wrote:
> 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.

Ano, tou dobou jsem vytvářel ten 256MB swap což samozřejmě souvisí s page
cache. Hmmmm, přemýšlím jestli zatížení page cache může způsobit OOM.
Vždycky jsem cache vnímal stylem "pokud bude málo paměti tak se uvolní"
ale je možné že pro dirty cache se to bude chovat jinak.

> 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á.

Nakonec jsem to uděla tak že jsem mu 512MB swap a (pokud si pamatuju
dobře) commit_ratio=50, což mu commit limit dá cca 750MB a jádru zbyde
dalších 256MB. Budu sledovat jak se to bude chovat ohledně swapování apod.

T.