update/bdflush problem

[Alexandr Malusek]

Egon Eckert <egon na www.capitol.cz> writes:
> A k tomuhle se taky chystam, myslim, ze to opravdu bude to cteni - ono to
> prechazi do vytrvaleho chrochtani v situaci, kdy ta aplikace ma VM size pres
> 10 MB, bezi mi k tomu X-y, gdb, ddd, mam 32 MB pameti a soubor po kterem to
> beha (a cte) ma 20 MB. Asi se pomalu s problemem presunu jinam - totiz do
> optimalizace datovych struktur...

Jednou jsem resil stiznost, ze system nepouziva diskove buffery, a
proto ze je aplikace nesmirne pomala, protoze data vzdy musi cist z
disku. Pres truss (obdoba strace) jsem ziskal parametry systemoveho
volani lseek a ty jsem potom analyzoval. Ukazalo se, ze pristupovy
vzor pro cteni z onoho temer 1 GB velkeho souboru byl vicemene
"nahodny". Mate-li v tomto pripade 1000 MB velky soubor a 100 MB
pameti pro buffery, pak pravdepodobnost, ze cteni bude z bufferu, je
1/10. Vlastni urychleni aplikace diky pritomnosti diskovych bufferu je
pak take priblizne o 1/10 - tedy temer zanedbatelne. Zaver byl, ze
diskove buffery funguji OK, ale ze je potreba predelat algoritmy (nebo
koupit ten 1GB pameti :-) ).

> Posledni otazka: existuje neco jako
> page-locking - tedy to, ze aplikace oznaci nejake casti sveho prostoru jako
> 'neswapovatelne' ?

Ano. mlock() zabrani odswapovani oblasti pameti a mlockall() zabrani
odswapovani temer vseho co souvisi s danym procesem (i stranek
namapovanych do pameti pres mmap()). Znam to ze SVR4, kde scheduler
implementuje i tridu pro real-time procesy - jejich stranky by nemely
byt odswapovany na disk. No a jak tak koukam (man sched_setscheduler),
tak Linuxi scheduler ty real-time procesy umi take.

> Pri behu jsem pomoci 'ps -m' sledoval ostatni aplikace, a
> prestoze byly zjevne idle (sleep), nektere ne a ne postupne mizet z pameti
> do swapu - prestoze by se tim uvolnovalo drahocenne misto pro diskovou
> cache.

Ono to chvilku trva. Zkusil jsem pres
dd if=/dev/hda2 of=/dev/null bs=32768
cist z disku a vypisovalo se mi:

$ vmstat 5
 procs                  memory    swap        io    system         cpu
 r b w  swpd  free  buff cache  si  so   bi   bo   in   cs  us  sy  id
 2 0 0 11320   252  1516  4612   0   0 3245    0 6592  206  96   4   0
 2 0 0 11320   252  1548  4580   5   0 2927    0 5963  198  93   7   0
... 
 2 0 0 13744   268  7272  1656   0   3 1881    1 3871  124  73  27   0
 2 0 0 13744   228  7348  1604   6   2 3159    0 6433  210  98   2   0
                    ^^^^  ^^^^
Je videt, ze na zacatku bylo pro diskove buffery vyhrazeno 1516 KB a
pro swapovatelnou virtualni pamet (cache) 4612 KB, zatimco na konci
se tento pomer obratil.

Zaroven jsem si ujasnil, ze Linux nepouziva spravu virtualni pameti
jakou ma SVR4. SVR4 klasicke diskove buffery neimplementuje, vse resi
pres virtualni pamet. Linux implementuje klasicke diskove buffery, ale
jejich mnozstvi se dynamicky meni podle potreby - ubira se ze
swapovatelne virtualni pameti pro procesy a jejich data. Je to celkem
zajimave reseni.

-- 
Alexandr Malusek (malusek na ujf.cas.cz)
UJF AV CR