dlouho trvajici sync po upgrade na 11.2

[Miroslav Lachman]

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