Bekijk Volledige Versie : Performance issue 3Ware 9650 icm 4x 3TB Raid 5
Hi,
Ik heb een nieuwe storage bak voor backups. De 2 oude zijn te klein geworden dus hebben we een chassis gekocht wat we kunnen uitbreiden met max 16 disks.
Nu heb ik echt verschrikkelijk belabberde performance op het Raid array, en snap niet waar dit vandaan komt.
De setup is het volgende:
2x L5420 met 8GB DDR2
4x 3TB Toshiba (uit de categorie veel voor weinig, nieuw)
3Ware 9650SE-16ML
Performance is 22MB/s, terwijl ik toch 100+ had verwacht
dd if=/dev/zero of=test bs=1048576 count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 101.332 s, 21.2 MB/s
Raid config:
tw_cli /c2 show
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-5 OK - - 256K 8381.87 Ri ON
Waar denken jullie dat het mis gaat?
Alvast bedankt!
Met 1GB data verstouwen is ie zo klaar, maar met 2GB verslikt ie zich compleet.
root@fs01:~# dd bs=1M count=1024 if=/dev/zero of=test
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 2.02702 s, 530 MB/s
2GB
root@fs01:~# dd bs=1M count=2048 if=/dev/zero of=test
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 115.713 s, 18.6 MB/s
Ik neem aan dat er geen BBU opzit, staat je write cache wel aan?
Daarboven is het wel een erg oude kaart, die normaal geen support heeft denk ik voor +2tb disks en ondertussen zelfs al end-of-life is. Maar misschien toch eens proberen met een firmware update?
Er zit geen BBU op en daarom staat de write cache ook uit. Kaart heeft de laatste firmware en ondersteunt 3TB.
Het vreemde is dat de 1GB test 530MB/s meet, en 2GB 18.6MB.
Doe dezelfde test eens met write cache forced aan? ( ter test )
Yourwebhoster
25/11/13, 18:38
Plak eens conv=fdatasync bij je dd commando. Voor meer informatie zie https://romanrm.net/dd-benchmark.
Heb je ook al de disks los van de RAID controller getest (en met RAID controller in JBOD)?
Moet je in een 3ware niet ergens een profiel instellen en deze op performance oid zetten.
Solutionsource
25/11/13, 21:37
Ik heb geen ervaring met die 3Ware controller, maar ik heb op onze backuplocatie met software-raid hetzelfde gedrag gezien (wij gebruiken voor backups ook consumenten disks).
Allereerst; die 1GB die wel snel gaat zal, zoals Yourwebhoster al zegt, komen door het niet syncen van je schrijfacties. Die writes die DD doet zijn simpelweg nog "in flight".
Echter, de beroerde performance komt waarschijnlijk door een disk die brak is. De snelheid van onze backups stortte op een gegeven ogenblik in. Dit bleek te liggen aan twee disken die spontaan last kregen van bad sectors.
Consumenten-disks proberen vrij lang om een sector te lezen en/of te herstellen, voordat ze een fout rapporteren aan de controller, waardoor bij media-errors op één disk je hele array traag wordt.
Ik zou de SMART waardes van je disken eens uitlezen en eventueel vergelijken met de SMART waardes na het wegschrijven van een paarhonderd GB. Als bijvoorbeeld je reallocated sector count oploopt, weet je dat die disk niet in orde is / veel tijd spendeert aan het lezen en schrijven naar rotte media.
Ik wat zitten testen, en zoals Yourwebhoster opmerkt vertekenen de eerdere metingen inderdaad doordat de disk sync niet geforceerd werd:
Zonder fdatasync
root@fs01:~# dd bs=1M count=256 if=/dev/zero of=test
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.554979 s, 484 MB/s
Met fdatasync
root@fs01:~# dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 23.8393 s, 11.3 MB/s
Met fdatasync, groter blok
root@fs01:~# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 45.1191 s, 11.9 MB/s
root@fs01:~#
Nu is het in indergeval consistent... ruk. :(
Net de SMART statussen uitgelezen, en Reallocated_Sector_Ct is overal 0.
Los van Spin-up time, die tussen de 380 en 412 ligt, zijn alle stats vrijwel identiek:
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0005 143 143 054 Pre-fail Offline - 86
3 Spin_Up_Time 0x0007 139 139 024 Pre-fail Always - 380 (Average 407)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 15
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 138 138 020 Pre-fail Offline - 33
9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 116
10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 15
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 16
193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 16
194 Temperature_Celsius 0x0002 230 230 000 Old_age Always - 26 (Min/Max 18/29)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
Iemand suggesties?
Volgens mij heb ik het gevonden, en het was nav de post van Ahead-IT....
Omdat ik geen BBU erop heb zitten had ik de write cache uit staan. Maar, als ik de write cache aanzet (wat heel makkelijk via de CLI kan) met dit regeltje:
tw_cli set cache c0 u0 on
Dan is dit mn performance op 2GB data:
root@fs01:~# dd bs=1M count=2048 if=/dev/zero of=test conv=fdatasync
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 9.50052 s, 226 MB/s
Dat lijkt me een logischere waarde :)
Zo, opgelost ;)
De BBU's zijn normaal nog te vinden trouwens, mocht er kritieke backups opstaan die niet corrupt mogen raken.
Zo, opgelost ;)
De BBU's zijn normaal nog te vinden trouwens, mocht er kritieke backups opstaan die niet corrupt mogen raken.
Wat kost een BBU-tje heden ten dagen?
Een 100 euro + transport.