Dan Lukes wrote on 2018/11/02 07:41:
Krome chyby (nejspis v kodu ovladace (S)ATA disku) muze jit o zmenu
logiky - sync mozna nyni skonci az v okamziku, kdy jsou vsechny
"spinave" buffer zapsane, coz v okamziku, kdy neustale prichazeji dalsi
a dalsi pozadavky an zapisy nemusi nastat hodne dlouho.
Asi to cele vic souvisi s tim, co konkretne se deje na tomhle stroji,
nez s tim, ze se neco tak moc zmenilo mezi 10.4 a 11.2, protoze stejny
skript bezi na vetsine stroju a nektere jsou vytizenejsi nez tenhle, ale
stejny problem na nich nepozoruju.
CPU: 14.1% user, 0.0% nice, 85.7% system, 0.1% interrupt, 0.1% idle
Pomer casu procesoru pro obsluhu in-kernel zalezitosti je pomerne velky
- ale nevede me to k zadnemu jasnemu a jednoznacnemu poznani o tom, co
se uvnitr presne deje. Zapis bufferu na disk by mel vytezovat spis IO
subsystem nez procesor.
Ano, tohle je divne i me a jak to tak vypada, ten sync je jen priznakem
nejakeho jineho problemu. Disky jsou tu ted vytizene na 100%, ale
prevazne ctenim. A to i pres to, ze jsem ten sync ve skriptu
zakomentoval a rsync backup zastavil.
Da se nejak zjistit, na cem se na tak dlouho zasekne?
Zacnes tim, ze nektery z tech syncu zastrelis tak, aby se vytvoril
coredump. Tim zjistis co proces delal z uzivatelskeho hlediska. Ja si
ale myslim, ze tim zjistis, ze proces proste ceka na navrat z volani
kernelove funkce. A debugovat co se deje uvnitr kernelu bude o poznani
slozitejsi.
Jak jsem psal vyse, asi jsem zacal resit problem ze spatneho konce, nebo
se mi tu sesly problemy dva a ted, misto toho, "na co ceka sync" musim
najit, proc "node.js" zere tolik IOPS
159 processes: 6 running, 148 sleeping, 3 zombie, 2 lock
CPU: 18.5% user, 0.0% nice, 17.6% system, 0.1% interrupt, 63.8% idle
Mem: 2169M Active, 14G Inact, 3492M Laundry, 2685M Wired, 1498M Buf,
1666M Free
Swap: 16G Total, 79M Used, 16G Free
PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
7178 www 369 7 367 0 0 367 16.86% node
7202 www 268 47 219 0 0 219 10.06% node
7191 www 372 22 60 0 159 219 10.06% php
7206 www 520 73 175 0 0 175 8.04% node
7210 www 347 34 152 0 0 152 6.98% node
7204 www 531 55 135 0 0 135 6.20% node
7208 www 318 39 132 0 0 132 6.06% node
7212 www 238 27 108 0 1 109 5.01% node
6853 www 218 37 101 0 0 101 4.64% httpd
7104 www 217 20 90 0 0 90 4.13% httpd
7214 www 214 37 69 0 1 70 3.22% node
6643 www 172 23 58 0 0 58 2.66% httpd
6670 www 68 3 41 0 0 41 1.88% httpd
# iostat -x -w 20 ada0 ada1
extended device statistics
device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b
ada0 551 73 2888.9 2876.7 12 1 0 11 7 100
ada1 561 73 2961.6 2876.7 11 1 0 10 3 100
extended device statistics
device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b
ada0 552 25 2871.5 1168.4 12 1 0 12 9 100
ada1 546 25 2825.1 1168.4 12 1 0 11 6 100
extended device statistics
device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b
ada0 437 59 2275.8 2329.1 13 0 0 12 2 99
ada1 435 59 2280.0 2329.1 14 0 0 12 1 99
Pro zacatek bych se ale opatrne pokusil vratit k jednoduche byt ne uplne
patricne otazce - proc ten sync vubec volas ...
To bude nejaky pozustatek z davne minulosti, kdy jsem se chtel ujistit,
ze tyhle zmeny v souboru budou skutecne zapsane na disk a nestane se, ze
rebootem serveru v nevhodny okamzik (panic atd.) o ne prijdu... ale
stejne to byl nejspis dost naivni pristup :)
Mirek
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
