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

[Tomas Vondra]

On 29.2.2012 02:14, Tomas Vondra wrote:
> On 28.2.2012 23:56, Pavel Kankovsky wrote:
>> On Tue, 28 Feb 2012, Tomas Vondra wrote:
>>
>>> Aktuálně jsem tam nastavil
>>>  vm.overcommit_memory = 2
>>>  vm.overcommit_ratio = 100
>>>  vm.swappiness = 0
>>>
>>> od čehož si slibuji že bude povoleno alokovat paměť odpovídající 100%
>>> fyzické RAM. Swap tam není, takže swappiness je tam spíš pro okrasu.
>>
>> Nejsem si úplně jistý, zda je to rozumné nastavení.
>>
>> vm.overcommit_memory má smysl nastavit na dvojku, pokud chcete
>> minimalizovat riziko, že paměť dojde neočekávaně v situaci, kdy to nelze
>> ošetřit jinak než vypuštěním OOM killera. Jádro se tedy snaží hned při
>> alokaci paměti (mmap(), brk()...) rezervovat potřebný prostor tak, aby
>> při výpadku stránky byl vždy k dispozici (to pochříchu nefunguje moc
>> dobře pro zásobník, který se může automaticky zvětšovat).
>>
>> Ovšem jádro samo také potřebuje nějaký životní prostor pro své datové
>> struktury. Pokud nastavíte vm.overcommit_ratio na 100, tak už nenecháte
>> v RAM žádný prostor vyhrazený pro jádro a pravděpodobně vytváříte opět
>> podmínky pro vznik situace, které se mělo nastavením
>> vm.overcommit_memory předejít, protože -- jestli to dobře chápu --
>> alokace paměti prováděné jádrem se tím, jaký prostor je rezervován pro
>> userland, nenechávají moc omezovat.
> 
> Ano, to zní rozumně. Neuvědomil jsem si že vm.overcommit_memory se týká
> jenom userspace procesů a nikoliv samotného jádra.
> 
>> Imho je v případě vm.overcommit_memory=2 nejlepší mít přiměřeně velký
>> swap (byť by se skoro vůbec nepoužíval) a vm.overcommit_ratio nastavit
>> na co nejmenší hodnotu postačující k bootu a shutdownu. Pokud z nějakého
>> důvodu nechce mít ani kilobajt swapu, pak by bylo vhodné aspoň udělat
>> nějaký odhad toho, kolik zabírá jádro (afaik Slab + PageTables v
>> /proc/meminfo),
>> a vm.overcommit_ratio nastavit tak, aby se součet držel s rozumnou
>> rezervou pod 100 % RAM.
> 
> Hmmm, podle meminfo zabírají Slab a PageTables 54444 kB. Podle free je v
> systému k dispozici 502728 kB, takže jádro potřebuje ~ 11%. Nastavil jsem
> 
>    vm.overcommit_ratio = 87
> 
> což dává ~ 2% (10MB) rezervu pro jádro což je myslím tak akorát.
> 
> S tím swapem nevím - já ho tam pokud možno nechci, pokud to nebude
> nutné. Uvažuji ho tam sice udělat ale jenom 64MB a nastavit
> overcommit_ratio=76, což odpovídá 382MB (resp. 446MB při započtení
> toho swapu). Takže pro jádro zůstává ~50MB fyzické RAM a ještě 64MB
> na swapu pro případ nouze. To je možná výhoda oproti tomu řešení bez
> swapu, ta větší rezerva ...

Tak bohužel, stále se to (asi) nechová tak jak bych očekával :-(

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:

  http://pastebin.com/2zUZTwE8

a běželo to s tím overcommit_ratio=87, tj. podle /proc/meminfo bylo

  CommitLimit:      437372 kB
  Committed_AS:     361404 kB

což odpovídá těm výpočtům. Když se podívám na ten sar (bohužel jen s
granularitou 10 minut) tak se nezdá že by se nějak zásadně čerpala
paměť. Dobrých 200MB je většinou v page cache, což by ale jádro myslím
mělo v případě potřeby uvolnit (není tam žádná výrazná write aktivita,
takže většina cache je čistá a lze ji zahodit).

Teoreticky je sice možné že si tam něco najednou začalo alokovat paměť,
ale není mi jasné co. Vidíte v tom někdo něco co já ne? 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 ...).

T.

PS: Po těch OOM v 19:15 jsem tam přidal swap, takže ta procenta v
posledních dvou řádcích se počítají jinak.