Cus,

me to u jednoho klienta taky trapi, narazime presne na to co cca
popisujes. Zejmena u DEV stroju, kde se to dost toci a zaroven je tam
dost velky overcommit na vsech prostredkach. A ano, taky se to deje
nekdy od tak 60 do 120dne uptime, pak uz to vetsinou nevydrzime a
otocime :-)

Nicmene tenhle problem v LXC je tak 2+roky a trapi nas to teda na LXC &
BTRFS & cgroups.

--

Petr Zitny

Dne 14.08.2020 v 9:12 Pavel Snajdr napsal(a):
> Pokud vim, tak u Proxmoxu celou tu kontejnerovou cast dost utlumili
> prave s tim, jak umrelo OpenVZ jadro - ted to proste nemaji, jak
> navarit lip, nez vsichni ostatni se standardnim Linuxem.
>
> Tj. bude je to trapit :)
>
> Otazka je, kdo vlastne kde ma potrebu na tech serverech i realne neco
> poustet.
>
> Ve spouste firemnich prostredi se nakoupi hromada HW a pak se z toho
> nevyuziva realne ani 1%... takze, ono to "v malem" bude vzdycky jak
> uchodit. Proste prinejhorsim shodis pametove limity uplne, zejo...
>
> Kdyz to ma stejne jenom jednoho admina, nebo jeden adminsky tym, co se
> o to stara...
>
> /snajpa
>
> On 2020-08-14 07:37, zd nex wrote:
>> Dobrá práce, máš můj obdiv.
>>
>> Zeptám se myslíš, že v Proxmoxu narazili na podobný problém?
>>
>> Přeci jen je to LXC & ZFS a cgroups? Určitě jsou tam aplikace,
>> které také používají mmap, ne? Několikrát jsem četl, že
>> hodně lidí mmap doporučuje ideálně pro velké soubory.
>> např.
>>
>> tady https://blog.askesis.pl/post/2019/02/mmap.html [5]
>> https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-access/2895799
>>
>> [6]
>>
>> Zdenek pripravto
>>
>> čt 13. 8. 2020 v 14:22 odesílatel Ondrej Beranek <rainbof@gmail.com>
>> napsal:
>>
>>> Poutave vysvetleni, dobra prace diky.
>>>
>>> čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr <snajpa@snajpa.net>
>>> napsal:
>>>
>>>> Ahojte,
>>>>
>>>> sliboval jsem (vetsinou off-list), ze shnu pak resenici s pameti
>>>> na
>>>> vpsAdminOS, tak tady to je :)
>>>>
>>>> Kdyz chce programator dneska z aplikace pracovat s velkym
>>>> souborem, je
>>>> docela rozsirenym pristupem, si takovy soubor namapovat do pameti
>>>> pomoci
>>>> mmap(2) syscallu.
>>>>
>>>> To zpusobi, ze se soubor ocitne ve virtualnim pametovem prostoru
>>>> procesu, tj. ten program si pak muze sahat do toho souboru
>>>> prostym
>>>> pristupovanim do pameti (nabizi se teda snadny ukladani napr.
>>>> Cckovych
>>>> structu do souboru, pristup pres pointerovou aritmetiku, atd.).
>>>>
>>>> Linux cachuje takovy napamovany soubor po strankach, protoze
>>>> samotnou
>>>> pamet spravuje po strankach (1 stranka pameti je na x64 velka 4
>>>> kB, huge
>>>> pages jsou potom dalsi extra story na jindy...). Jakmile aplikace
>>>> chce
>>>> precist nejaka data, Linux na pozadi, pokud uz to neudelal, pro
>>>> ta data
>>>> alokuje stranku fyzicke pameti, aby ta data mela realne, kde
>>>> sedet,
>>>> precte je do te stranky z disku (nebo kde ten soubor je) a pak tu
>>>>
>>>> stranku namapuje do prislusneho mista virtualniho pametoveho
>>>> prostoru
>>>> naseho procesu, ktery ta data cte.
>>>>
>>>> Jadro vede mapovane stranky v evidenci pomoci LRU listu, coz je
>>>> datova
>>>> struktura, seznam, ktery se vyznacuje tim, ze vede v evidenci,
>>>> ktera
>>>> polozka byla pouzita naposled (tak, ze se meni pri jejim pouziti
>>>> jeji
>>>> poradi na zacatek seznamu).
>>>>
>>>> Kdyz vsechno funguje jak ma, v realne fyzicke pameti jsou
>>>> pouzivana
>>>> ctena data a jeste nezapsane "pospinene" (dirty) stranky, do
>>>> kterych se
>>>> psalo, tj. je u nich naplanovano, aby se co nejrychleji dostaly
>>>> na disk
>>>> (pokud teda cely soubor nebyl otevreny s flagem O_SYNC, nebo
>>>> podobne, co
>>>> by vynutilo kazdou zmenu zapsat na disk ihned, nez Linux vrati
>>>> kontrolu
>>>> aplikaci pri tom zapisu do mapovaneho souboru; to neni tak caste
>>>> a to je
>>>> nam ted "jedno").
>>>>
>>>> Zapis je nastesti vyreseny dobre, Linux ma na to mechanismus,
>>>> kteremu
>>>> rika "writeback throttle"; kdyz detekuje, ze se zacina RAM plnit
>>>> vic,
>>>> nez je zdravo, zacne aplikaci ty zapisujici pristupy adekvatne
>>>> zpomalovat. Tohle "impedancni prizpusobeni" funguje vcelku dobre,
>>>> navic
>>>> funguje dostatecne dobre i pod memory cgroup.
>>>>
>>>> Memory cgroup je mechanismus, kterym omezujeme pridelenou pamet
>>>> kontejnerum pod Linuxem - je to volitelna sada dalsich pocitadel
>>>> vyuziti
>>>> pameti, nad zakladni systemove, plus vydeleni ukazatelu na LRU,
>>>> writeback a dalsi cache, aby se dalo pekne vest takovehle seznamy
>>>>
>>>> stranek v oddelene, mimojine aby bylo jasne, co komu patri, kdyz
>>>> dojde
>>>> cas tu pamet jednou odklidit. Ale taky, aby se dalo hlidat
>>>> maximalni
>>>> vyuziti pameti na ruzne caches - zdaleka nejen - kvuli prave
>>>> mapovanym
>>>> souborum.
>>>>
>>>> Potud vsechno dobre.
>>>>
>>>> To nam tak system nabehne, pospousti se na nem stovka VPSek,
>>>> vsechny
>>>> aplikace se krasne rozbehnou, nektere si namapujou soubory,
>>>> nektere do
>>>> nich vesele zapisuji data...
>>>>
>>>> System muze bezet klidne mesice bez problemu, vsechno stiha, v
>>>> pohode.
>>>> Ty seznamy jsou bezne docela kratke, takze sbirka jadernych
>>>> threadu
>>>> "kswapd" je na pozadi pekne stiha prochazet a odklizet, jak se
>>>> postupne
>>>> nektere memory cgroupy dostavaji s pameti do uzkych.
>>>>
>>>> Koneckoncu, 4 GB RAM (na jeden kontejner) prelozeno na 4 kB
>>>> stranky
>>>> znamena teoretickou maximalni delku jednoho seznamu 1M polozek.
>>>> To se na
>>>> 2+ gigahertzovych CPU preci stihne projit rychle, ze.
>>>>
>>>> No a pak se stane, ze po treba dvou mesicich behu systemu
>>>> najednou
>>>> zoufaly clen pise, ze mu v kontejneru dochazi pamet, pritom at
>>>> pocita,
>>>> jak pocita, nemuze se dopocitat, ze by to zabiraly aplikace - je
>>>> videt,
>>>> ze je to tim, ze caches nechteji odcouvavat.
>>>>
>>>> Hm, docela spatenka, jak to mame opravit, kdyz to trva tak
>>>> dlouho, nez
>>>> se problem projevi? :-D
>>>>
>>>> Tady nekde bych mel podotknout, ze abych byl schopny to takhle
>>>> pekne
>>>> vysvetlit, musel jsem doprojit celou cestu do vyresena, takze ted
>>>> se to
>>>> jevi zpetne jako trivka, ale nez jsem prisel na to, z ktere
>>>> strany ten
>>>> problem pujde aspon nejak resit...
>>>>
>>>> Kdyz se clovek na takovy trpici system prihlasi, vidi tam
>>>> zpravidla
>>>> kswapd0 na 100% a kdyz ma ta masina dva fyzicke CPU, tak tam vidi
>>>>
>>>> vetsinou i kswapd1 v tom samem stavu.
>>>>
>>>> V dmesgu jsou videt out of memory hlasky z jednotlivych
>>>> kontejneru, jak
>>>> narazeji na neodkliditelne caches a jadro zoufale zabiji stare
>>>> procesy,
>>>> aby udelalo misto pro dalsi.
>>>>
>>>> V tech OOM hlaskach je videt pokazde i stack trace, odkud ta OOM
>>>> udalost
>>>> z jadra prisla - vetsina z nich byla vyvolana kvuli cteni do
>>>> mmaped
>>>> souboru, coz se pozna tak, ze v tom stacku jsou videt funkce
>>>> pridavajici
>>>> LRU stranky na seznam te memory cgroupe.
>>>>
>>>> Tak si rikam, hm, to ma preci snadne reseni, nebudeme uctovat
>>>> mapovanou
>>>> pamet do memory cgroup clenu, ale nechame ji v root memory
>>>> cgroup...
>>>>
>>>> Okay, to by mohlo fungovat, ze?
>>>>
>>>> ..a zase, kswapd0/1 na 100%...
>>>>
>>>> To uz jsem se zacal seriozneji zajimat, co se to vlastne deje, co
>>>> delaji
>>>> tak dlouho a jak to cele funguje, kdyz to neslo smaznout "izy
>>>> hackem".
>>>>
>>>> Napad to byl dobry, fungoval by, nebyt mensi drobnosti:
>>>>
>>>> kswapd, kdyz odklizeji caches na pozadi, prohledavaji memory
>>>> cgroupy
>>>> stylem "dej mi takovou, ktera zere nejvic a tu odklidime, kdyz to
>>>> nebude
>>>> stacit, pujdem na dalsi".
>>>>
>>>> Tj. pokud se objevi jedna cgroup, ktera je vetsi a ma toho
>>>> vzdycky vic k
>>>> odklizeni, muze se vzdycky kswapd zahojit na ni a k dalsim se ani
>>>>
>>>> nedostat.
>>>>
>>>> Jedine, kdy se odklizi pamet uplne primo z te memory cgroupy, je
>>>> tzv.
>>>> "direct reclaim", cesta kodu primo v momente, kdy je potreba
>>>> alokovat -
>>>> ale v tu chvili neni tolik casu na uklizeni, tak se jadro zas tak
>>>>
>>>> nesnazi a nekdy to muze vzdat predcasne a rict, ze pamet nenaslo
>>>> a
>>>> vyvola OOM situaci v postizene memory cgroupe.
>>>>
>>>> Hmm... okay, takhle by to neslo, tak zkusme mmaped pamet
>>>> neuctovat
>>>> cgroupam vubec a nechme ji v zakladnich systemovych seznamech...
>>>>
>>>> A po trochu zapaseni, bo se v jadre s memory cgroup nepocita, ze
>>>> by
>>>> nahodou mmaped pamet nebyla uctovana zadne memory cgroupe, je
>>>> vyreseno,
>>>> odchod na parek!
>>>>
>>>> ...do chvile, nez tim posleme celou masinu out-of-memory a OOM
>>>> chyby
>>>> zacnou prichazet odkudkoliv, ne jen z mmaped readu odzpod z
>>>> mem-cgroup...
>>>>
>>>> Totiz kdyz byly mmaped soubory uctovany na jeden seznam, ktery
>>>> neni v
>>>> memory cgroupe, myslelo si jadro, ze ma hodne volnou ruku v tom,
>>>> co si
>>>> muze dovolit nechat nacachovane - ale v tom je potom mensi caveat
>>>> se
>>>> ZFS... postupny nahodny random access pattern k datum mmaped
>>>> souboru
>>>> nadela z ARC slab caches fragmentovane reseto, jeste kdyz se drzi
>>>> ty
>>>> kousky z tech puvodne nactenych dat pri zivote "pripinovanim" na
>>>> jeden
>>>> velky seznam, ktery nema duvod couvat, protoze host ma preci
>>>> vsechnu
>>>> pamet k dispozici bez limitu :D
>>>>
>>>> No pak a chudaci kswapd, kdyz si s tim bordelem maji nejak
>>>> poradit a
>>>> odklidit to, *obzvlast* kdyz jsou jen dva a kdyz pod nima mame
>>>> (konecne
>>>> spravne nastavene se spravnym ashiftem) NVMe pole... na te
>>>> staging node
>>>> (nyni node1.stg) se tak darilo zaplnit RAM az skoro do mrtva.
>>>>
>>>> Takze co s tim? :)
>>>>
>>>> Snadna reseni dosla, bude potreba odklizet ty seznamy
>>>> per-limitovana-memory-cgroup.
>>>>
>>>> Na nekolik iteraci jsem nakonec dospel k patchi, ktery spusti
>>>> per-NUMA-node "ksoftlimd" thready, pro kazdou memory cgroupu,
>>>> ktera ma
>>>> nastaveny soft_limit.
>>>>
>>>> Ksoftlimd pak dela presne toto - prochazi seznamy svoji memory
>>>> cgroupy a
>>>> drzi si je okolo soft_limitu.
>>>>
>>>> Kswapd maji o praci s memory cgroupama min, pokud je jadro
>>>> nastavene v
>>>> rezimu, ze ma ksoftlimd poustet automaticky (da se tez spoustet
>>>> jen
>>>> rucne).
>>>>
>>>> My jsme zatim defaultne zvolili soft_limit jako watermark, nad
>>>> ktery se
>>>> ma ksoftlimd snazit vic odklizet, nastavujeme ho na 80% pameti
>>>> kontejneru - ale do budoucna mozna tohle jeste predelam na
>>>> nejakou vetsi
>>>> automatiku, podle toho, jak kde se ukazou pripadne nedostatky.
>>>>
>>>> Tedy, vysledna situace je, ze pokud aplikace zerou min, jak 80%
>>>> pameti,
>>>> ale je co drzet v RAM jako cache, bude mit kontejner vyuzito
>>>> okolo tech
>>>> 80% - bude to videt normalne jako aplikacni pamet a zbytek jako
>>>> caches.
>>>> Uz by se nemelo stat, ze vyuziti stoupne az ke 100% kvuli caches
>>>> a ze
>>>> dojde k OOM a zabijeni procesu.
>>>>
>>>> Zaverem bych jeste zminil ty patche:
>>>>
>>>> Pokus mmaped soubory nauctovat root mem cgroupe:
>>>>
>>>> https://github.com/vpsfreecz/linux/commit/d42232f89795 [1]
>>>>
>>>> Pokus mmaped soubory mem cgroupam neuctovat vubec (popis commitu
>>>> je blbe
>>>> a celkove je nedocisteny, nebyl jsem s tim spokojeny a nechtel
>>>> jsem tim
>>>> travit vic casu, radsi jsem koumal, co dal, at the time...) ->
>>>>
>>>> https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95 [2]
>>>>
>>>> A finalne, aktualne nasazena verze ksoftlimd patche:
>>>>
>>>> https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d [3]
>>>>
>>>> A uplne-uplne zaverem: linux kernel neni advanced black magic. Je
>>>> to jen
>>>> strasne velka a nekdy dost neforemna kupa C kodu, ktery potrebuje
>>>>
>>>> schopne a ochotne instalatery.
>>>>
>>>> V koncinach memory cgroup + memory managementu je teda hodne, co
>>>> zlepsovat, a vubec to neni raketova veda... Teda obecne, na
>>>> kontejnerizace v Linuxu je dost co resit.
>>>>
>>>> Takze kdybyste s tim jadernym vyvojem nekdo chtel pomoct, stavte
>>>> se na
>>>> IRC, nebo v Base48 v Brne pokecat, neco vymyslime, bude to
>>>> zabava, trust
>>>> me ;)
>>>>
>>>> /snajpa
>>>> _______________________________________________
>>>> Community-list mailing list
>>>> Community-list@lists.vpsfree.cz
>>>> http://lists.vpsfree.cz/listinfo/community-list [4]
>>> _______________________________________________
>>> Community-list mailing list
>>> Community-list@lists.vpsfree.cz
>>> http://lists.vpsfree.cz/listinfo/community-list [4]
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/vpsfreecz/linux/commit/d42232f89795
>> [2] https://github.com/vpsfreecz/linux/commit/c10ae4a7ef95
>> [3] https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d
>> [4] http://lists.vpsfree.cz/listinfo/community-list
>> [5] https://blog.askesis.pl/post/2019/02/mmap.html
>> [6]
>> https://stackoverflow.com/questions/258091/when-should-i-use-mmap-for-file-access/2895799
>>
>>
>> _______________________________________________
>> Community-list mailing list
>> Community-list@lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
> _______________________________________________
> Community-list mailing list
> Community-list@lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list