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
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
A finalne, aktualne nasazena verze ksoftlimd patche:
https://github.com/vpsfreecz/linux/commit/e04b3f9cda1d
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
Ahoj,
mám na jedné VPS nixops a zkouším přes to deploynout nixos na jinou VPS.
Opakovaně jsem narazil na problém, že se začne kompilovat nějaká derivace, a
po chvíli to sestřelí OOM killer. Typicky se těsně předtím naspawnuje spoustu
(desítky) procesů. Všiml jsem si toho u ripgrepu (rustc), tam to ještě prošlo.
Teď mi spadne GitLab resp. webpack při kompilaci assetů:
/tmp/nix-build-gitlab-assets-13.0.9.drv-1/source/node_modules/.bin/webpack --config /tmp/nix-build-gitlab-assets-13.0.9.drv-1/source/config/webpack.config.js --bail
Deploy spouštím na node256 takto:
nixops deploy -d simple --max-jobs 1 --cores 1
VPS má 4 GB, běží na node15.prg. V dmesg vidím, že tam při spuštění OOM
killeru bylo 32 procesů node15
32 je podezřelé kulaté číslo. Myslím si, že buildovací tooly odněkud přečtou
informaci, že mají pustit 32 instancí, nastartují podle toho a vzápětí je
systém po setkání s realitou sestřelí.
Chystám se zreprodukovat build webpacku ručně a zjistit, podle čeho to spawnuje.
Nemá už to někdo projité? Zní to jako něco, na co už mohl narazit někdo jiný.
zdravím
Tomáš Kuča
Ahoj,
u VPSky co mám ve správě - caara.cz, vidím divně obsazenou RAM. Graf
ukazuje 2,3 TB obsazené RAM, ale hlavní žrouti jsou mysql - 158 GB a
journald - 142 GB a pak už tam jsou jenom malé procesy. Odkud se teda bere
těch 2.3 TB, které postupně narůstají?
Ahoj,
Filip Bartmann
Ahoj,
pokud někdo používáte Arch, doporučuji na vpsfree _NEprovádět_ upgrade
systemd na 249-1. netctl, co je použit, zapisuje při bootu pro
konfiguraci sítě systemd unitu netctl(a)venet0.service:
> .include /usr/lib/systemd/system/netctl@.service
>
> [Unit]
> Description=osctl network configuration for venet0
Po rebootu již nenastartujete, protože je to pro systemd unita s "bad
syntax", pomůže restore přes admina.
Těžko k tomu něco říci; já osobně se zbavím oné šílenosti netctl/osctld
a přejdu na čisté řešení se systemd-networkd, ale nechci si tím nyní
kazit víkend.
Petr
Ahoj,
pokouším se spustit OpenVPN na Ubuntu 18.04:
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
TUN/TAP mám povolený.
Konfigurační soubor, je mírně upravený podle (hlavní změna jsou
certifikáty):
https://kb.vpsfree.cz/navody/server/openvpn
(https://kb.vpsfree.cz/navody/server/openvpn)
Přesto mi OpenVPN neustále padá:
Sat Jul 25 22:02:16 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)]
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Sat Jul 25 22:02:16 2020 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO
2.08
Sat Jul 25 22:02:16 2020 Diffie-Hellman initialized with 2048 bit key
Sat Jul 25 22:02:16 2020 TUN/TAP device tap0 opened
Sat Jul 25 22:02:16 2020 Note: Cannot set tx queue length on tap0: Operation
not permitted (errno=1)
Sat Jul 25 22:02:16 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Jul 25 22:02:16 2020 /sbin/ip link set dev tap0 up mtu 1500
Sat Jul 25 22:02:16 2020 openvpn_execve: unable to fork: Resource
temporarily unavailable (errno=11)
Sat Jul 25 22:02:16 2020 Exiting due to fatal error
Nevíte někdo jak to vyřešit?
H
Ahojte,
mám VPS, ale z ničeho nic se mi k němu nijak nedaří připojit. Ani přes
HTTP(S), ani přes SSH, přes web-konzoli jsem se díval, porty 443,80,22
jsou normálně povolené. Zkoušel jsem to i přes více sítí z více zařízení.
VPS běží na node1.prg, Ubuntu 20.04.
Co mám zkontrolovat případně opravit? Nebo je to chyba někde jinde?
Ještě dodám, v tu dobu jsem neprovedl na VPS žádné změny, jednoduše
jeden HTTPS požadavek fungoval, další už byl timed out, SSH poté stejná
chyba. Zkoušel jsem i restart, nepomohlo. Server má vytížení normální,
síťová aktivita je také v pohodě (resp. žádná není, jako většinu času
:)), takže DDoS/DOS to být nemůže.
Děkuji za pomoc :)
Ahoj,
zjistil jsem, že se mi na VPSce s CentOS 8 divně chová htop, konkrétně jak
zobrazuje
využitou ram. Když dám v konzoli free -m tak mám:
----------------------------------------------------------------
total used free shared buff/cache
available
Mem: 4096 140 93 3838 3861
3955
----------------------------------------------------------------
V htopu mi ale ukazuje RAM skoro celou použitou RAM - viz přiložený
obrázek, konkrétně mi jde o hodnotu buff/cache, v htopu se mi
nezobrazuje žlutě jako jinde, tak nevím jestli RAM je plná, bo ne.
Ahoj,
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně
převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná
více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz
mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery
a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny.
- Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker
- Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos
- Používám Arch, Podman v rootless režimu (z mnoha důvodů).
- Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP.
- Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění,
výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`,
nedaří se mi:
> Error:
> container_linux.go:367: starting container process caused:
> process_linux.go:459: container init caused:
> process_linux.go:382: setting rlimits for ready process caused:
> error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne
nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení
nějak specifické?
Díky, Petr
Ahoj,
V kontextu clenske schuze dnes padlo tema zalohovani na pasky. Nedavno jsem k tomu cetl super clanek (v cestine), ve kterem autor popisuje fungovani technologie zalohovani na pasky LTO, rozdily mezi verzemi a pod.
Pokud o zalohovani na pasky uvazujete, je to super zdroj informaci.
Zapisek najdete na https://www.fangfactory.net/2020/01/05/linear-tape-open-lto/
Radek Zajic
