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

Fri Aug 14 14:29:22 CEST 2020

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/c623d805/attachment-0001.html>