[vpsFree.cz: community-list] Sprava pameti na vpsAdminOS

Fri Aug 14 14:32:36 CEST 2020

Jen tak mimo, jak by se to chovalo s EXT4? Tím netvrdím, že to chci, spíše
je otázka jaký je tam ten vztah cgroups & mmap & filesystem?

pá 14. 8. 2020 v 14:29 odesílatel zd nex <zdnexnet at gmail.com> napsal:

> Já jsem právě měl za to, že je spíše kvůli tomu, že se cgroups začalo
> právě více používat a že tam některé takové situace právě nebyly dořešené.
> Tzn, že se to sice týká LXC, ale spíše jádra a cgroups jako takových a že
> se to spíše ukázalo přímo na LXC, jelikož se začíná pro tyto situace
> používat více. V minulosti to bylo KVM a teď se lidem líbí více tohle.
> Možná to ale pouze špatně chápu :)
> Zdenek.
>
> pá 14. 8. 2020 v 14:06 odesílatel Petr Žitný <petr at zitny.net> napsal:
>
>> 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 at gmail.com>
>> >> napsal:
>> >>
>> >>> Poutave vysvetleni, dobra prace diky.
>> >>>
>> >>> čt 13. 8. 2020 v 13:02 odesílatel Pavel Snajdr <snajpa at 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 at lists.vpsfree.cz
>> >>>> http://lists.vpsfree.cz/listinfo/community-list [4]
>> >>> _______________________________________________
>> >>> Community-list mailing list
>> >>> Community-list at 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 at lists.vpsfree.cz
>> >> http://lists.vpsfree.cz/listinfo/community-list
>> > _______________________________________________
>> > Community-list mailing list
>> > Community-list at lists.vpsfree.cz
>> > http://lists.vpsfree.cz/listinfo/community-list
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20200814/a4eceb82/attachment-0001.html>