sslug-teknik team mailing list archive

["Henrik Kj�Nielsen" <hkn@xxxxxxxxxxxxxxxxxx>]

Jeg er begyndt at se på, hvilke muligheder der er for at optimere Samba på 
Linux med henblik på at opnå bedst mulig performance som audio/video server. 
Dermed mener jeg en server, som udelukkende anvendes til sekventiel læsning 
af store filer (megabyte og gigabyte størrelse). På sigt kunne jeg tænke mig 
at anvende et Raid-0 baseret på SATA diske.

Jeg kæmper på to fronter: Dels er jeg helt ny på Linux platformen (men det 
vokser jeg vel fra på et tidspunkt) og desuden er jeg klar over, at der 
findes utallige muligheder for at tweake snart sagt alting og at ingen 
sandsynligvis kan pege på det helt rigtige setup. Derfor tager jeg én ting 
ad gangen og eksperimenterer lige nu med tuning af filsystemet. P.t. 
anvender jeg ikke Raid og SATA men blot en ordinær ATA IDE hard disk.

Jeg planlægger at anvende en stor read-ahead, fx. i størrelsesordenen 1 MB, 
for at mindske den tid der anvendes til søgning på disk-systemet når mange 
brugere samtidigt anvender serveren.
Som udgangspunkt har jeg anvendt benchmark-programmer som fx. bonnie++ 
(http://www.coker.com.au/bonnie++) og iozone (http://www.iozone.org) for at 
vurdere systemets umiddelbare performance og betydningen af forskellige 
indstillinger. Lige nu undres jeg over følgende ting:

1.
iostat fortæller mig, at der anvendes 128 kByte readahead (rkB/s divideret 
med r/s).
Selvom jeg ændrer readahead vha hdparm (fx. hdparm -a 1024 /dev/hda), så 
viser iostat ikke, at read-ahead er ændret. Benchmarks viser heller ingen 
ændring.

2.
Når jeg anvender iozone (iozone -s 512m -r 64k -a), så er write performance 
lige så god som read performance.
Vælger jeg en throughput test med flere processer (iozone -s 512m -r 64k -t 
2), så falder write performance lidt men read performance falder drastisk.

Anvendes iostat (iostat -x 2) i sidstnævnte situation afsløres det, at IO 
read requests tager længere tid (2-3 gange) så snart iozone køres med 2 i 
stedet for 1 process. Write requests ændrer sig derimod ikke så meget.

Noget kunne altså tyde på, at read-ahead mekanismen virker dårligt, og 
betydeligt dårligere end write behind mekanismen.


Mine spørgsmål er:

Hvordan ændrer jeg på read-ahead parameteren, og hvordan verficerer jeg 
denne ændring?
Findes der gode forklaringer på, at write er hurtigere end read?

Jeg anvender Fedora Core 3 med kernel 2.6.11-1.27_FC3

Venlig hilsen
Henrik