We hebben een Intel SRCS16 controller in onze servers laten zetten omdat we dachten dat we daar wel op konden vertrouwen. Ook onder Linux, wist onze reseller te vertellen.
De waarheid blijkt anders. De server is weliswaar stabiel, maar performance is niet om over naar huis te schrijven. Het ergste is nog wel de %iowait die disk writes genereert. Op onze dual Xeon met HTT enabled brengt die %iowait met 25% de hele server naar de grond - de I/O thread consumeert een volledige CPU en laat de andere 3 spinnen.
Cijfers op een compleet idle server:
/dev/sda:
Timing cached reads: 3140 MB in 2.00 seconds = 1570.00 MB/sec
Timing buffered disk reads: 174 MB in 3.02 seconds = 57.62 MB/sec
Configuratie:
RAID level: 1 (2x 160 GB Samsung SP1614C + 1 hot-spare)
Cache write policy: Write-through (geen BBU)
Cache read policy: Cached I/O
Read ahead: Adaptive
Slice size: 64 KB
Memory: 64 MB
Disk write caching: Disabled (dataintegriteit is een absolute vereiste en ik vertrouw die UPS van onze colocation provider niet)
Geen kernel preemption, 100 Hz timeslices. I/O scheduler veranderen van anticipatory naar deadline heeft geen effect. Bovenstaande cijfers zijn met Linux 2.6.14 en MegaRAID driver 2.20.2.6 op een XFS partitie. Een andere identieke server draait 2.6.11 met iets oudere firmware en heeft exact dezelfde problemen.
De performance is zo onacceptabel, maar Intel verschuilt zich achter regeltjes. Zo zijn de Samsungs niet gevalideerd en Gentoo toch al niet (terwijl gebruikers op het Red Hat forum over hetzelfde klagen). Hebben jullie hier ervaringen mee of beter nog: oplossingen voor?
De waarheid blijkt anders. De server is weliswaar stabiel, maar performance is niet om over naar huis te schrijven. Het ergste is nog wel de %iowait die disk writes genereert. Op onze dual Xeon met HTT enabled brengt die %iowait met 25% de hele server naar de grond - de I/O thread consumeert een volledige CPU en laat de andere 3 spinnen.
Cijfers op een compleet idle server:
/dev/sda:
Timing cached reads: 3140 MB in 2.00 seconds = 1570.00 MB/sec
Timing buffered disk reads: 174 MB in 3.02 seconds = 57.62 MB/sec
Version 1.93c ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -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
emperor 2G 510 85 4722 0 4006 1 973 99 42702 5 153.0 1
Latency 13494us 78742ms 3060ms 18589us 93865us 2569ms
Version 1.93c ------Sequential Create------ --------Random Create--------
emperor -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 270 1 +++++ +++ 323 9 257 1 +++++ +++ 136 0
Latency 536ms 132us 392ms 621ms 48us 2045ms
1.93c,1.93c,emperor,1,1140611531,2G,,510,85,4722,0,4006,1,973,99,42702,5,153.0,1,16,,,,,270,1,+++++,+++,323,9,257,1,+++++,+++,136,0,13494us,78742ms,3060ms,18589us,93865us,2569ms,536ms,132us,392ms,621ms,48us,2045msConfiguratie:
RAID level: 1 (2x 160 GB Samsung SP1614C + 1 hot-spare)
Cache write policy: Write-through (geen BBU)
Cache read policy: Cached I/O
Read ahead: Adaptive
Slice size: 64 KB
Memory: 64 MB
Disk write caching: Disabled (dataintegriteit is een absolute vereiste en ik vertrouw die UPS van onze colocation provider niet)
Geen kernel preemption, 100 Hz timeslices. I/O scheduler veranderen van anticipatory naar deadline heeft geen effect. Bovenstaande cijfers zijn met Linux 2.6.14 en MegaRAID driver 2.20.2.6 op een XFS partitie. Een andere identieke server draait 2.6.11 met iets oudere firmware en heeft exact dezelfde problemen.
De performance is zo onacceptabel, maar Intel verschuilt zich achter regeltjes. Zo zijn de Samsungs niet gevalideerd en Gentoo toch al niet (terwijl gebruikers op het Red Hat forum over hetzelfde klagen). Hebben jullie hier ervaringen mee of beter nog: oplossingen voor?