XFS+RAID5 slechte performance

[PenguinPower]

Ik heb het hele weekend mijn servertje opnieuw zitten te configuren. Ik vond het wel leuk om weer gentoo ipv debian erop te zetten. En met de 3 nieuwe schijven in een RAID 5 voor / en RAID 1+hotspare voor /boot was het voor mij een echte uitdaging.

Nu zit ik echter met 2 problemen:

1. Er is een schijf die een andere geometrie heeft... terwijl het 3 dezelfde Maxtor Maxline II 250GB zouden moeten zijn:

code:

server2 root # fdisk -l /dev/hda

Disk /dev/hda: 251.0 GB, 251000193024 bytes
16 heads, 63 sectors/track, 486344 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          16        8032+  fd  Linux raid autodetect
/dev/hda2              17        1992      995904   82  Linux swap
/dev/hda3            1993      486344   244113408   fd  Linux raid autodetect
server2 root # fdisk -l /dev/hdb

Disk /dev/hdb: 251.0 GB, 251000193024 bytes
16 heads, 63 sectors/track, 486344 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1   *           1          16        8032+  fd  Linux raid autodetect
/dev/hdb2              17        1992      995904   82  Linux swap
/dev/hdb3            1993      486344   244113408   fd  Linux raid autodetect
server2 root # fdisk -l /dev/hdc

Disk /dev/hdc: 251.0 GB, 251000193024 bytes
255 heads, 63 sectors/track, 30515 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdc1   *           1           1        8001   fd  Linux raid autodetect
/dev/hdc2               2         125      996030   82  Linux swap
/dev/hdc3             126       30515   244107675   fd  Linux raid autodetect

Zie de cylinders van hdc... daarom is mijn parities ook anders. Hoe verhelp ik dit? Of is dit een geval van een vreemde eend in de bijt en moet ik de iComputers bellen of ze ik de schijf kan ruilen voor eentje met de zelfde cylinders?

2. Ik heb nogal last van een performance probleem. Is een 4k block size heb in xfs en een chunk-size van 32 niet goed? Hoe moet het dan?..:

code:

server2 root # cat /etc/raidtab
# / (RAID 5)
raiddev                 /dev/md0
raid-level              5
nr-raid-disks           3
persistent-superblock   1
chunk-size              32
parity-algorithm        right-symmetric
device                  /dev/hda3
raid-disk               0
device                  /dev/hdc3
raid-disk               1
device                  /dev/hdb3
raid-disk               2

# /boot (RAID 1)
raiddev                 /dev/md1
raid-level              1
nr-raid-disks           2
nr-spare-disks          1
chunk-size              32
persistent-superblock   1
device                  /dev/hda1
raid-disk               0
device                  /dev/hdc1
raid-disk               1
device                  /dev/hdb1
spare-disk              0
server2 root # xfs_info /
meta-data=/                      isize=256    agcount=117, agsize=1048568 blks
         =                       sectsz=512
data     =                       bsize=4096   blocks=122053792, imaxpct=25
         =                       sunit=8      swidth=16 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=8192, version=1
         =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0
server2 root # hdparm -tT /dev/md0

/dev/md0:
 Timing buffer-cache reads:   508 MB in  2.01 seconds = 252.74 MB/sec
 Timing buffered disk reads:   98 MB in  3.04 seconds =  32.24 MB/sec
server2 root # hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   508 MB in  2.00 seconds = 254.00 MB/sec
 Timing buffered disk reads:  166 MB in  3.00 seconds =  55.33 MB/sec
server2 root # hdparm -tT /dev/hdb

/dev/hdb:
 Timing buffer-cache reads:   508 MB in  2.00 seconds = 254.00 MB/sec
 Timing buffered disk reads:  166 MB in  3.01 seconds =  55.15 MB/sec
server2 root # hdparm -tT /dev/hdc

/dev/hdc:
 Timing buffer-cache reads:   504 MB in  2.01 seconds = 250.75 MB/sec
 Timing buffered disk reads:  162 MB in  3.02 seconds =  53.64 MB/sec

[_JGC_]

Mja, of je nou XFS, reiser, ext2 of NTFS zou nemen, je meet met hdparm de raw performance van je RAID array zonder filesystem erbij.

Let wel dat je hier met software RAID bezig bent, en RAID-5 is nogal een aanslag op je systeem.

Edit:
Ik zie ook dat je right-symetric gebruik voor je parity algoritme, terwijl left-symetric sneller zou moeten zijn volgens de manpage. Dit is wat ik haal met een hp pa-risc D370 met 6 SCSI disks en 1 in spare:

code:

/dev/sdb:
 Timing buffer-cache reads:   128 MB in  5.53 seconds = 23.15 MB/sec
 Timing buffered disk reads:  64 MB in  8.21 seconds =  7.80 MB/sec
hp-uxje:~# hdparm -tT /dev/md0
 
/dev/md0:
 Timing buffer-cache reads:   128 MB in  6.20 seconds = 20.65 MB/sec
 Timing buffered disk reads:  64 MB in  4.32 seconds = 14.81 MB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.
hp-uxje:~# hdparm -tT /dev/md0
 
/dev/md0:
 Timing buffer-cache reads:   128 MB in  5.50 seconds = 23.27 MB/sec
 Timing buffered disk reads:  64 MB in  4.28 seconds = 14.95 MB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.

[ Voor 67% gewijzigd door _JGC_ op 15-03-2004 09:29 ]

[Jelmer]

DMA? umask irq?

Verder heb ik zelf een chunksize van 64KB en als parity algoritme 'left-symetric'. Heb je er zelf bewust voor gekozen om het right-symetric te doen?

--
wacht, google:

http://www.google.nl/sear...algorithm&hl=nl&ie=UTF-8:

>==========================================================
>
>This seems to be an area of constant confusion. Let me describe why
>XFS sucks on Linux software RAID5. It has nothing to do with
>controllers, physical disk layout, or anything like that.
>
>RAID5 works by saving a N-1 chunks of data followed by a chunk of
>parity information (the location of the checksum chunk is actually
>interleaved between devices with RAID5, but whatever). These N-1 data
>chunks + the parity blob make out a stripe.
>
>Every time you update any chunk of data you need to read in the rest
>of the data chunks in that stripe, calculate the parity, and then
>write out the modified data chunk + parity.
>
>This sucks performance-wise because a write could worst case end up
>causing N-2 reads (at this point you have your updated chunk in
>memory) followed by 2 writes. The Linux RAID5 personality isn't quite
>that stupid and actually uses a slightly different algorithm involving
>reading old data + parity off disk, masking, and then writing the new
>data + parity back.
>
>In any case Linux software RAID keeps a stripe cache around to cut
>down on the disk I/Os caused by parity updates. And this cache really
>improves performance.
>
>Now. Unlike the other Linux filesystems, XFS does not stick to one
>I/O size. The filesystem data blocks are 4K (on PC anyway), but log
>entries will be written in 512 byte chunks.
>
>Unfortunately these 512 byte I/Os will cause the RAID5 code to flush
>its entire stripe cache and reconfigure it for 512 byte I/O sizes.
>Then, a few ms later, we come back and do a 4K data write, causing the
>damn thing to be flushed again. And so on.
>
>IOW, Linux software RAID5 code was written for filesystems like ext2
>that only do fixed size I/Os.
>
>So the real problem is that because XFS keeps switching the I/O size,
>the RAID5 code effectively runs without a stripe cache. And that's
>what's making the huge sucking sound. This will be fixed -
>eventually...
>
>By moving the XFS journal to a different device (like a software RAID1
>as we suggest in the FAQ), you can work around this problem.
>
>And finally - All the hardware RAID controllers I have worked with
>stick to one I/O size internally and don't have this problem. They do
>read-modify-write on their own preferred size I/Os anyway.
>
>======================================================================

Dit is trouwens wat ik haal:

code:

hdparm -tT /dev/md0

/dev/md0:
 Timing buffer-cache reads:   128 MB in  0.97 seconds =131.96 MB/sec
 Timing buffered disk reads:  64 MB in  0.99 seconds = 64.65 MB/sec

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.00 seconds =128.00 MB/sec
 Timing buffered disk reads:  64 MB in  1.25 seconds = 51.20 MB/sec

/dev/hde: & /dev/hdg:
 Timing buffer-cache reads:   128 MB in  0.99 seconds =129.29 MB/sec
 Timing buffered disk reads:  64 MB in  1.82 seconds = 35.16 MB/sec

(ext3 op raid5 met 3 ide-schijven: Maxtor 6E040L0 40GB en 2 IBM 307030 GXP-75 30GB. Kernel 2.4.25, Athlon 900, 133Mhz memory bus, via686b + promise 20268r2)

[ Voor 33% gewijzigd door Jelmer op 15-03-2004 09:46 ]

[PenguinPower]

code:

server2 root # hdparm /dev/hda

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 64 (on)
 geometry     = 30515/255/63, sectors = 490234752, start = 0
server2 root # hdparm /dev/hdb

/dev/hdb:
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 64 (on)
 geometry     = 30515/255/63, sectors = 490234752, start = 0
server2 root # hdparm /dev/hdc

/dev/hdc:
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 64 (on)
 geometry     = 30515/255/63, sectors = 490234752, start = 0

Ik ben trouwens uitgegaan van de howto van de gentoo fora.

De waardes van jelmer begrijp ik wel. Die zijn namelijk meer dan een individueele schijf. Bij mij is een indivdiduele schijf ongeveer 50% sneller.

De raid5d verbruikt trouwens niet echt veel CPU en geheugen, ook niet bij lees/schijf acties.

Dat XFS vs RAID5 verhaal ben ik inderdaad eerder tegengekomen. daarom dat ik het ook in titel heb gezet.

> LVM manages to trigger the "raid5: switching cache buffer size" printk
> quiet voluminously when using a snapshot device. The following patch
> disables it by placing it under the debugging PRINTK macro.

This is there as a 'printk' deliberately. It warns you that what you
are doing isn't really supported and will cause a substantial
performance hit (as all IO to the array is completely serialised
around one of these messages).

If you want to make it PRITNK for yourself, that is fine. But I would
rather it stayed as printk in the mainstream kernel untill the root
problem is fixed (and I have seen patches that possibly fix the
problem, but I haven't had a chance to look at them).

NeilBrown

Hier had ik ook last van. en heb printk in de raid5.c verwijderd, zodat ik een beetje meer performance zou krijgen.

die printk regel gaf idd het probleem dan jelmer aangaf aan.

Het probleem is dus XFS vs RAID 5.

Ik denk dat ik volgend weekend maar eens ga kijken of ik alles kan omzetten naar ext3. Ik weet alleen niet hoe ik dat het handigst kan doen.
Is dit wat:?
1 schijf uit de raid halen, die partitioneren en de hele boel daarop zetten. vervolgens md0 formateren als ext3 en de boel weer terug copyeren? en natuurlijk de schijf weer terughangen in de raid?

Of is er een conversie programma?

[ Voor 47% gewijzigd door PenguinPower op 15-03-2004 10:18 ]

[voodooless]

Gebruik als je RAID hebt GEEN hdparm! Dat is naarmelijk in het geval van RAID een waardeloze benchmark! Probeer bonnie++ ofzo, daar heb je meer aan en je neemt ook nog eens het filesysteem mee!

Voor de lol zal ik ook nog ff mijn resultaten posten:

code:

/dev/md1:
 Timing buffer-cache reads:   128 MB in  0.54 seconds =237.95 MB/sec
 Timing buffered disk reads:  64 MB in  0.95 seconds = 67.38 MB/sec

4 Disk RAID 5 met 2x maxtor 10K4, 1x 10K3 en 1x 10K1 (op een Dual U320 controller ) Rest van de specs staan in de sig. Ik wil ook wel een bonnie benchmark doen (4G test file), gebruik zelf reiserfs:

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
defaint.deepspac 4G 18542  91 58470  39 25864  18 19375  93 65565  32 265.6   3
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 22283  99 +++++ +++ 18502  99 19852  97 +++++ +++ 15413  97

Is toch niet zo'n heel slecht resultaat als je nagaat dat de 10K1 de beperkende factor is.