swap_pager: indefinite wait buffer

[Miroslav Lachman]

Miroslav Lachman wrote:
[...]
> Napriklad spusteni prikazu gstat trva vic nez minutu.
[...]
> Vsimnete si, ze disky maji 111% busy (pri jednotlivych obnovenich 
> obrazovky se hodnoty pohybuji od 90 do 115), presto tps pouze 1 a datovy 
> tok temer nulovy.
> Ve vypisu gstat je videt problikavani velmi vysokych hodnot 
> procentualniho zatizeni (cisla od 150 az do 3000), ale jsou to jen velmi 
> kratke okamziky, rozhodne to nevypada, jako kdyz se na disk opravdu neco 
> systematicky zapisuje / cte. Zaroven jsou tam silene dlouhe casy pro 
> zapisy (ms/w).
> 
> dT: 0.501s  w: 0.500s
>   L(q) ops/s r/s kBps ms/r w/s kBps   ms/w   %busy Name
>     0    0    0    0  0.0   0    0    0.0    0.0| acd0
>     4    2    0    0  0.0   2    4 5110.3  164.6| ad5
>     5    2    0    0  0.0   2    4 5002.8  167.9| ad4
>     6    2    0    0  0.0   2    4 5002.9  167.9| mirror/gm0
>     0    0    0    0  0.0   0    0    0.0    0.0| ad4s1
>     0    0    0    0  0.0   0    0    0.0    0.0| ad4s2
>     0    0    0    0  0.0   0    0    0.0    0.0| ad5s1
>     0    0    0    0  0.0   0    0    0.0    0.0| ad5s2
>     1    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1
>     5    2    0    0  0.0   2    4 5003.0  167.9| mirror/gm0s2
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1a
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1b
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1c
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1d
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1e
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1f
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1g
>     1    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s1h
>     0    0    0    0  0.0   0    0    0.0    0.0| mirror/gm0s2c
>     5    2    0    0  0.0   2    4 5003.0  167.9| mirror/gm0s2d
> 
> Nejsem bohuzel nijak schopen zjistit, cim to muze byt.

Tak uz jsem v podstate nahodou zjistil, cim bylo to zpomaleni - muze za 
to extended self-test SMART monitoringu disku. Nevim, jestli self-test 
ridi smartmontools, nebo jen preda patricny prikaz disku a ten uz si 
test dela sam (rekl bych, ze plati druha varianta). Test jsem vcera 
vecer spustil prikazem smartctl -t long /dev/ad4 a mel trvat priblizne 
dve hodiny. Jenze kdyz jsem se rano prihlasoval na server (asi 10 hodin 
od spusteni self-testu), choval se opet velmi zpomalene (viz popis z 
puvodniho mailu) a vypis gstat vypadal jako vyse uvedeny. smartctl -X 
/dev/ad4 jsem abortnul test, ktery stale jeste bezel (podle zaznamu ve 
SMART logu byl v 90%, ale to same je tam zapsane z doby pred 2 dny). 
Zkratka test se nejak zasekne a naprosto zpomali disk.

Zkusil jsem stejny prikaz pustit na jinych strojich s jinymi disky a tam 
se to chova tak, jak bych ocekaval - disk neni testem nijak viditelne 
zpomalen, cist z neho jde az 60MB/s (dvojnasobek toho, co na zminenem 
"problemovem" stroji pri vypnutem selftestu!)

Vyznate se nekdo ve SMART disku natolik, abyste mi dokazal rict, jestli 
je problem ve smartmontools, nebo je to chyba disku? Nemuzu v serveru 
vyzkouset jiny disk, protoze server je pronajaty a poskytovatel ma k 
dispozici jen uplne stejne disky z jedne serie, ktere se patrne chovaji 
stejne :(

Miroslav Lachman