update/bdflush problem

[Alexandr Malusek]

> potreboval bych poradit: Mam aplikaci, ktera pri behu pomerne divoce
> zapisuje do pomerne velkeho souboru (rekneme 4 MB). Chvili po jejim startu
> uz se kontrolka disku nezastavi, nejaky write-ahead jako by neexistoval. Jak
> je to mozne ? Myslel jsem, ze bdflush zajisti flushnuti dirty bufferu
> uplyne-li urcita doba od zapisu.

Zapisy mohou byt:
- synchronni
- asynchronni

V pripade asynchronnich zapisu se plni diskove buffery a ty se potom
"flushuji" na disk. V pripade synchronnich zapisu aplikace po vydani
pozadavku na zapis ceka, dokud nedostane potvrzeni od disku, ze
operace probehla. Vypada to, ze vase aplikace pouziva synchronni
zapisy.

Jak se to da poznat?
Ve zdrojaku se podivat na parametry funkce open (O_SYNC), pripadne
fcntl (F_SETFL). Myslim, ze to vypsuje i strace, ale neoveroval jsem
to. Da se to odhadnout i u bezici aplikace, ale potrebujete na to
vhodne nastroje na monitorovani zateze systemu. U Solarisu se mi
osvedcil program iostat.

$ iostat -xtc 5 2
                       extended disk statistics       tty         cpu
disk r/s  w/s Kr/s Kw/s wait actv svc_t  %w  %b  tin tout us sy wt id
sd0   6.2 0.0 21.5  0.0 0.0  0.1  24.1   0   15   0   84  4  94  2 0
sd1   1.8 0.0 14.3  0.0 0.0  0.1  41.6   0    7
sd2   0.0 0.0  0.0  0.0 0.0  0.0   0.0   0    0
sd3   5.6 0.2 25.7  0.2 0.0  0.1  22.5   0   13

Dulezite parametry v tomto pripade jsou:

svc_t - Prumerny cas pro vyrizeni jedne transakce (ms)
%b    - Procentualni zastoupeni casu, kdy disk je aktivni (kdy probihaji
        transakce)

Pri synchronnich zapisech je hodnota svc_t kolem 11 ms (neprimo to
souvisi i se stredni pristupovou dobou disku), protoze ve fronte muze
byt nejvyse jeden pozadavek, pricemz hodnota %b byva vysoka, rekneme
nad 50%, muzete tam videt i treba 90% ...

Pri asynchronnich zapisech je hodnota svc_t obvykle nekolikanasobkem
11 ms, nebot ve fronte na zapis ceka vice pozadavku. Hodnota %b byva
nizsi. (Mimochodem, je-li tato hodnota nad 65% v dlouhodobem prumeru, pak
se disk povazuje za pretizeny).

Muze se to zdat jako alchymie, ale na zaklade techto cisel (a
nekterych dalsich) se skutecne dela performance tuning u velkych
serveru se Solarisem (aspon ja jsem to takhle dva roky pro Sun
delal)

Celkem me mrzi, ze tyto monitorovaci nastroje (iostat, vmstat, nfsstat,
sar, ...) na Linuxu nejsou. V pripade desktopu to tolik nevadi, ale
v pripade vetsiho serveru jsou velmi zadouci.

Prikladem aplikaci, ktere pouzivaji synchronni zapisy, jsou NIS+ a
vsechny modifikace adresaru v Solarisim ufs filesystemu. (Adresarove
operace, ktere v ufs filesystemu trvaji hodne pres minutu, probehnou
na ext2fs za 5s).

Rada stiznosti zakazniku na pomalost diskoveho systemu obvykle koncila
konstatovanim, ze za to mohou synchronni zapisy. Trochu v tomto pripade
pomahaji filesystemy s transakcnim logem, ale ty pro Linux nejsou.


S pozdravem,
Alexandr Malusek (malusek na ujf.cas.cz)
UJF AV CR