[sw raid] verklaring gezocht voor lage performance

[TD-er]

Het probleem:
Snelheid van/naar fileserver komt niet boven de 120-140 Mbit uit.
NetIO-snelheid ligt een stuk hoger, maar IO van/naar raid-device is een beetje erg moeilijk te meten. Deze laatste lijkt de oorzaak van het probleem, alleen hoe krijg ik die sneller?
Heeft het zin om de buffer van de software raid te vergroten en zo ja hoe doe ik dat?

Zou het snelheidsverschil van de 4 harde schijven de snelheid van het hele array naar beneden halen? (echte oplossing daarvoor heb ik niet, daar de 7200 rpm een vervanging is van een kapotte 5400 rpm, omdat 5400 rpms niet meer verkocht worden)

Ik zit eventueel te denken aan een echte Raid-controller, maar daar moet ik dan even voor sparen.

kortom hoe krijg ik mijn fileserver sneller?

(vragen over tweaken van netwerk-snelheid had ik al eens eerder gesteld, maar had ik geen werkend antwoord op gekregen)


Dit is wat ik heb staan en wat ik al geprobeerd heb:
-------------------------------------------------
Ik heb een linux machine met software raid5. Filesystem is Ext3
2 schijven (5400 en 7200 rpm) zitten op de prim- en sec.controller onboard en de overige 2 zitten op een ATA66 controllertje van Promise.
Er zit een MSI 6309 mainboard in (VIA 686b SB) met daarin een Tualatin(Celeron) 1200 MHz en 768 MB sdram.
Netwerk gaat via een Intel 82540EM Gigabit Ethernet.
Daar ik sinds kort een 2.6.4 kernel (en samba 3) draai ben ik maar weer eens meer op snelheden gaan letten.

Volgens NetIO zou deze 2.6 kernel een snellere afhandeling van het netwerk verkeer doen en dus, samen met Samba 3, een grotere netwerksnelheid beloven.

code:

                        2.4.18 kernel    2.6.4 kernel
Packet size  1 KByte:   24125 KByte/s    22739 KByte/s
Packet size  2 KByte:   20510 KByte/s    25345 KByte/s
Packet size  4 KByte:   24411 KByte/s    28282 KByte/s
Packet size  8 KByte:   32089 KByte/s    32432 KByte/s
Packet size 16 KByte:   42587 KByte/s    60417 KByte/s
Packet size 32 KByte:   48235 KByte/s    68360 KByte/s

Helaas scheelt het in de praktijk niets (orde van seconden sneller bij files van >4 GB)
Dus ben ik verder gaan zoeken.

Benchmark resultaten van Bonnie++ met 2.4 kernel:

code:

Version 1.02c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
fileserver_tuala 2G           28142  25 13380  12           52826  18 192.4   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   743  98 +++++ +++ +++++ +++   774  98 +++++ +++  2834  98

Benchmark resultaten van Bonnie++ met 2.6 kernel:

code:

Version 1.02c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
fileserver_tuala 2G           12813  11  7374   7           26630  16 225.4   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   692  98 +++++ +++ +++++ +++   685  96 +++++ +++  2451  98

oftewel een stuk lagere performance bij de 2.6 kernel, maar (de maximale waarde)alsnog een stuk sneller als wat ik haal over het netwerk. (max 120-140 Mbit/s)

aan de hand van het topic : XFS+RAID5 slechte performance ben ik eens gaan kijken naar de performance vergeleken met verschillende blokgroottes.
Dus heb ik een klein test programmatje geschreven, die een file van 500 MB schrijft met allemaal nullen, met een blocksize die als parameter meegegeven is:

code:

BSIZE=$1        # Te testen blocksize in kB, de eerste parameter
TESTSIZE=500    # Grootte van testfile in MB
#echo "simpele blocksize benchmark"
sync            # eventuele open files nog afsluiten
START=`cat /proc/uptime|cut -d ' ' -f1`
dd if=/dev/zero of=testfile bs=`echo $BSIZE"*1024"|bc` count=`echo $TESTSIZE"*1024/"$BSIZE|bc` 2> /dev/zero
sync
STOP=`cat /proc/uptime|cut -d ' ' -f1`
echo "blocksize: " $BSIZE "kB.  speed:" `echo $TESTSIZE"/("$STOP"-"$START")"|bc` "MB/s"

en dit programmatje aangeroepen met verschillende blokgroottes.

code:

blocksize:  1 kB.  speed: 25 MB/s
blocksize:  2 kB.  speed: 12 MB/s
blocksize:  3 kB.  speed: 24 MB/s
blocksize:  4 kB.  speed: 12 MB/s
blocksize:  8 kB.  speed: 26 MB/s
blocksize:  16 kB.  speed: 13 MB/s
blocksize:  32 kB.  speed: 26 MB/s
blocksize:  64 kB.  speed: 12 MB/s
blocksize:  128 kB.  speed: 27 MB/s
blocksize:  256 kB.  speed: 12 MB/s

Nu lijkt het dus dat er een verband is tussen blocksize en snelheid.
Dus ik een paar keer achter elkaar proberen met een blocksize van 4184 kB (in de dmesg staat: "raid5: allocated 4184kB for md0")

code:

[root@fileserver root]# ./hddbench 4184
blocksize:  4184 kB.  speed: 23 MB/s
[root@fileserver root]# ./hddbench 4184
blocksize:  4184 kB.  speed: 15 MB/s
[root@fileserver root]# ./hddbench 4184
blocksize:  4184 kB.  speed: 19 MB/s

Oftewel het wisselen in snelheid is hiermee niet goed te simuleren.
Een nieuwe testrun met dezelfde blocksizes als hierboven (1,2,3,4,8,.... kB) geeft dan ook precies de omgekeerde resultaten.
Een testrun op een andere machine (niet-raid) geeft wel telkens hetzelfde resultaat, ook met wisselende blokgroottes, evenals een machine met hardware RAID5 controller (Promise Sata met 4*160 GB)

code:

[gijs@butler /mnt/raid/postbus]$ ~gijs/hddtest 4
blocksize:  4 kB.  speed: 60 MB/s
[gijs@butler /mnt/raid/postbus]$ ~gijs/hddtest 4
blocksize:  4 kB.  speed: 59 MB/s
[gijs@butler /mnt/raid/postbus]$ ~gijs/hddtest 4
blocksize:  4 kB.  speed: 57 MB/s