Dotaz: Centos 7 (1708) "laguje"

[hw]

Po aktualizaci CentOS 7.3.1611 na 7.4.1708 na ThinkPadu T530 mi začal systém občas na chvilku zatuhávat. Po pár jednotkách až desítkách minut vždycky na okamžik (určitě pod 1 s) zatuhne celé GUI včetně kurzoru myši. V logu nic zvláštního. Říkal jsem si, že blbne novější Gnome. Teď jsem ale nabootoval starší jádro ještě z 7.3.1611 a vypadá to, že systém běží plynule.

Zatím jsem jenom zvýšil počet installonly_limit v /etc/yum.conf, abych při aktualizaci nepřišel o starší jádra a čekám, jestli se problém s nějakou aktualizací vyřeší. Můžete mi někdo poradit jakým způsobem bych mohl zjistit co způsobuje chvilkové zatuhnutí celého systému? Jaké nástroje k tomu použít a jak? Díky.

Odpovědi

[NN]

Logovat gui, xorg nebo jak se to jmenuje?

[hw]

Tak se starším jádrem to byl přehnaný optimismus. Děje se to taky. Něco v systému na chvíli sežere všechny prostředky.

[lertimir]

mohl by to odlogovat atop, ale pod sekundu je dost málo, to zachytit nemusí.

[trubicoid2]

nekopiruje se neco? nedojde pamet a neswapuje? load je kolik?

nejlip koukej na htop a iotop

kolik je pameti a kolik je v /proc/sys/vm/dirty_background_bytes, /proc/sys/vm/dirty_bytes a /proc/sys/vm/swappiness

[hw]

Děje se to i když se nic nekopíruje. Paměti je celkem dost. Swap je vypnutý. Load minimální. Přesto se občas všechno na chvilku zasekne.

[root@t530 ~]# uptime
 13:05:18 up  5:59,  3 users,  load average: 0.12, 0.80, 1.31

[root@t530 ~]# free
              total        used        free      shared  buff/cache   available
Mem:       16122596     2585424     7227156      264100     6310016    12794444
Swap:             0           0           0

[root@t530 ~]# cat /proc/sys/vm/dirty_background_bytes 
0

[root@t530 ~]# cat /proc/sys/vm/dirty_bytes 
0

[root@t530 ~]# cat /proc/sys/vm/swappiness 
60

V htop a iotop jsem zatím nic zvláštního nechytil. Ale ty dotazy na kopírování a IO mě ještě nasměrovaly na další věc. Pracovní filesystémy mám namountované ze serveru přes NFS. Zkusím sledovat co se bude dít, když NFS nebude připojené.

[trubicoid2]

kdyz ty _bytes jsou vypnuty, tak mas nastaveny odpoviadjici _ratio a to dela pri hodne RAM kontraproduktivne moc, lespi je dat treba

echo 33554432 > /proc/sys/vm/dirty_background_bytes #32MB = 3% z 1GB; mohlo by bejt 100MB = 10% z 1GB

echo 66554432 > /proc/sys/vm/dirty_bytes #64MB = 6% z 1GB; mohlo by bejt 200MB = 20% z 1GB

nfs mi delalo problemy s defaultnim hard, musel jsem dat soft, ale uz je to dlouho a ted nfs nemam

jaky mas ty mount options pro to nfs?

[hw]

Ratio je implicitně takhle:

[root@t530 ~]$ cat /proc/sys/vm/dirty_background_ratio 
10
[root@t530 ~]$ cat /proc/sys/vm/dirty_ratio 
20

NFS mountuju pořád s parametry, které jsem používal před více než deseti lety na RHEL 6, takže je dost možný, že v dnešní době tam mám blbosti:

auto,rw,noatime,nodiratime,nodev,async,_netdev,proto=tcp,retry=5,rsize=32768,wsize=32768,soft,intr

To chvilkové zatuhávání celého systému se mi ale stává i když nic z NFS nepoužívám. Pouze mám ty NFS filesystémy připojené, ale nic na nich nedělám.

[Trubicoid2]

Jo, to máš staré defaultní hodnoty. Pro mraky RAM je to moc a brzdí to systém. Zkus ty hodnoty, co jsem psal.

Soft máš, tím to asi nebude. NFS vyloučíš, když ho odmountuješ a bude to tuhnout stejně. Když je mountlé a nic s nim neděláš ještě nutně nemusí nic znamenat.

[hw]

Tak po nastavení dirty_background_bytes na 32MB a dirty_bytes na 64MB se to snad zlepšilo. Funguju s tím dneska celý den a těch zadrhnutí bylo jenom pár. Teď ještě jak se dostat do stavu jako před aktualizací, kdy se to nestávalo vůbec.

[Trubicoid2]

Tak dobrý. Před aktualizací jedině bys nabootoval starý jádro?

Já si myslím, že těch pár zadrhnutí předtím třeba taky možná bylo, ale teď se na to víc soustředíš. Není to možný?

Další možnost jak zlepšit interaktivitu je snížit swapinness z 60 (default) na 10. Ale ty swap nemáš. Možná ho pokusně zapni třeba do souboru (pomalejší než parice, ale na vyzkoušení stačí) a swapinness dej 10.

A NFS bych taky zkušebně odmountoval, jestli to bude taky zatuhávat. U NFS je těch kombinací moc, dobrý by bylo to vyloučit

[hw]

Staré jádro samo o sobě nepomohlo. S velkou aktualizací tam musela být ještě nějaká další změna.

Zadrhnutí myši bych si moc dobře všiml, protože třeba při několikahodinové práci na schématech/layoutu je každé zadrhnutí k vzteku.

Na NFS se ještě mrknu. To ale nejde v pracovní dny, kdy na NFS filesystému potřebuji pracovat. Někdy si na to udělám čas.

Zatím díky všem za pomoc. Vypadá to, že dirty pages byly hlavní zdroj problémů.

[Josef Kufner]

Já se potýkám s asi stejným problémem. Teď jsem přešel na RT jádro a pokud ti pomohlo snížit dirty pages, mohlo by pomoci i použití RT jádra:

$ uname -a
Linux 4.9.0-4-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux

Mám ho tu teprve druhý den, ale vypadá to nadějně. Zdá se, že i když jedna aplikace maká, tak zbytek desktopu má mnohem lepší odezvy a práce je plynulejší. Ale nemám naměřené žádné hodnoty a nevím, jak přesně se RT jádro chová k běžným aplikací, které nemají RT prioritu, takže to možná bude jen placebo efekt v kombinaci s rebootem

[lertimir]

Tak jak píše trubicoid. Je to pravděpodobně tento problém, jen místo flashky máš data na NFS. Hodnoty máš 0 protože jsou aktivní údaje v "_ratio" a ne "_bytes".

[hw]

Zaměřím se na to. Zajímavé je, že to chvilkové zatuhnutí sytému (skutečně zamrzne i Gnome a kurzor myši na <<1 s) se děje i když na těch NFS filesystémech vůbec nic nedělám a jsou pouze přimountované.

[vencour]

Nebylo by něco vidět přes latencytop?

[hw]

S distribučním jádrem ne, protože není zkompilované s CONFIG_LATENCYTOP.

[karlik]

Nevím jestli je to od verze Centos 7 1708, já to pozoruji u Centos 7 od začátku.

Stačí provést yum update nebo zálohování s více daty a systém jde do swapu.

Nastavení dirty_background_bytes pomohlo. Zajímavé je, že na Debianu to nepozoruji.

[hw]

Mě až do upgradu na 1708 všechno funguvalo naprosto v pořádku a stabilně. Žádné zadrhnutí jsem do té doby nikdy neviděl. Po aktualizaci na 1708 bez jakékoliv další změny v systému se to najednou začalo dít. Navíc nemůžu úplně potvrdit, že by to nějak víc zamrzávalo při diskových operacích.

[Trubicoid2]

Jaký má debian jádro? Oni ty defaultní 10 a 20% v některém vydání změnili na rozumější hodnoty.

[pushkin]

Nemáš něco zajímavého v syslogu?

[hw]

V logu nic.

[Aleš Kapica]

Nemáš v tom náhodou SSD disk? A když tak – jaký? A jaký používáš FS? Mě něco podobného dělaly dříve OCZ Vertex3 disky. Od té doby co jsem se vyměnil za Samsungy s ten problém nemám.

[Josef Kufner]

Pokud tomu tak je, nemělo by pomoct vypnout swap?

[hw]

Systém je na Samsung SSD 850 EVO mSATA 500GB (EMT41B6Q). Pak tam mám ještě klasický 2.5" SATA 500GB 7200rpm HITACHI HTS725050A7E630 (GH2ZB390), ale ten je pouze pro data na práci offline třeba u zákazníka.

Na obou mám XFS. Swap vůbec nemám. Root FS připojovaný pouze s noatime. TRIM přes fstrim.timer.

[hw]

Tak aktualizace stavu. Momentálně sedím v servisu a čekám na přezutí auta. NFS filesystémy tedy nejsou připojené, notebook není v doku s externím monitorem a běží z baterky. Žádný zádrhel, vše běží naprosto plynule. Musím vyzkoušet postupně jednotlivé věci samostatně, ale vypadá to na problém s jednou z těchto věcí (napájení, dok, externí monitor, NFS).

[Johanka]

Nevím jestli to k něčemu bude, ale u ThinkPadu X220 jsem svého času bojovala s latencemi na JACKu v okamžiku, kdy počítač komunikoval přes síťovou kartu v docking station. Při připojení přes síťovku přímo v notebooku nebo přes wifinu problém nebyl, ale aktivní LAN karta v dockině prostě způsobovala drobné lagy, na které jackd reagoval v lepším případě lupáním, v horším případě pádem. Stačilo vytáhnout kabel a problémy přestaly (takže jsem při práci se zvukem nakonec většinu času jela přes bezdrát).

Mohlo by to být něco podobného...?