Disk performance problemen Proliant server

[krietjur]

De situatie:

HP Proliant ML570
Processor: 4x XEON 3.0 Ghz
Geheugen: 4GB
OS: Red Hat Enterprise 3
Kernel: 2.4.21
Raidcontroller: Compaq Smart Array 64xx

Aan de RAID-controller hangen in totaal 12 schijven, 6 per kanaal. Er zijn in totaal 5 raid-arrays geconfigureerd:

1: raid 1, over 2 schijven van 36GB die elk op een apart kanaal hangen. Deze is weer onderverdeeld in verschillende partities waaronder /boot, /usr, /opt, /tmp, / en var. Tevens is er een swap partitie en een partitie die gebruikt wordt voor een later te noemen software raid.
2: raid 1, over 2 schijven van 72 GB die elk op een apart kanaal hangen. Deze is onderverdeeld in 3 partities, voor /home, een swap partitie en een partitie voor de later te noemen software raid.
3: raid 1+0, over 4 schijven van 36GB, 2 schijven per kanaal. Onderverdeeld in 3 partities, voor /db, een swap partitie en wederom een partitie voor de software raid.
4: raid 1, over 2 schijven van 36GB, elk op een apart kanaal. Onderverdeeld in 4 partities. Hier geen swap partitie en geen partitie voor software raid.
5: raid 1, over 2 schijven van 36GB, elk op een apart kanaal. Onderverdeeld in 6 partities, waaronder weer een swap partitie en een partitie voor software raid.

En dan nog de eerder genoemde software raid, dit is een raid 0 over de eerder genoemde partities.

Het probleem:

Wanneer er veel lees-activiteiten zijn dan schiet de IO-wait torenhoog de lucht in. Vooral op de 3e raid-array (de raid 1+0) vindt erg veel leesactiviteit plaats. Het iostat commando geeft voor deze partitie ook erg grote getallen aan:

code:

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d2p3    224.52 14348993180298.83       150.88 18446744071655006876  193970362

Regelmatig (en in de toekomst nog steeds meer) vindt er meer lees-activiteit plaats dan normaal. Het is dus belangrijk dat de performance wordt verbeterd.

Wat me verder opvalt met het iostat commando, is dat de swap partities op de arrays 1, 2 en 5 vrijwel niet gebruikt worden. De swap partitie op array 3 (natuurlijk weer de drukste array..) wel:

code:

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d2p2      3.36        12.15        15.40   15625968   19803552

Wat nu..?

Wat zou ik kunnen doen om de performance te verbeteren? Zou de software raid een oorzaak kunnen zijn? Is de raid configuratie uberhaupt wel slim aangepakt? Wellicht zou de drukste array een eigen controller moeten krijgen? Tijdens mijn zoektocht kwam ik op linuxquestions.org nog tegen dat er problemen zouden zijn bij Red Hat Enterprise 3 in combinatie met XEON processoren, maar heb er verder niet echt wat over kunnen vinden. Zijn er mensen die hier ervaringen mee hebben?

Ter aanvullende informatie nog wat output van /proc/scsi/aic7xxx/0, Target 3 valt me hierbij op.. is hier iets raars mee aan de hand?

code:

Adaptec AIC7xxx driver version: 6.2.36
Adaptec (Compaq OEM) 3960D Ultra160 SCSI adapter
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Allocated SCBs: 6, SG List Length: 85

Serial EEPROM:
0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a
0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a
0x08f4 0x605d 0x2807 0x0010 0x0301 0xffff 0xffff 0xffff
0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x0250 0x4a50

Target 0 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 1 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 2 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 3 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
        Goal: 40.000MB/s transfers (20.000MHz, offset 32, 16bit)
        Curr: 40.000MB/s transfers (20.000MHz, offset 32, 16bit)
        Channel A Target 3 Lun 0 Settings
                Commands Queued 11289875
                Commands Active 0
                Command Openings 1
                Max Tagged Openings 0
                Device Queue Frozen Count 0
Target 4 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 5 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 6 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 7 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 8 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 9 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 10 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 11 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 12 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 13 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 14 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 15 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)

/proc/scsi/aic7xxx/1, hier ziet target 3 er wel gewoon zo uit als de rest

code:

Adaptec AIC7xxx driver version: 6.2.36
Adaptec (Compaq OEM) 3960D Ultra160 SCSI adapter
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Allocated SCBs: 6, SG List Length: 85

Serial EEPROM:
0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a
0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a 0xcb3a
0x08f4 0x605d 0x2807 0x0010 0x0301 0xffff 0xffff 0xffff
0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x0250 0x4a50

Target 0 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 1 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 2 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 3 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 4 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 5 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 6 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 7 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 8 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 9 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 10 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 11 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 12 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 13 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 14 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Target 15 Negotiation Settings
        User: 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)

[asing]

Beats me, maar Target 3 lijkt me niet fris meer. Het eerste dat opvalt is dat een antieke SCSI snelheid wordt gebruikt (40MB/s) terwijl de rest op ultra160 werkt. Ook staan er een zooi commando's in de queue......

Het zou me niks verbazen als nummer 3 gewoon defect is.

[Asteroid9]

Idd ja, met 40MB/s is er zeker wel iets verkeerd.
Ik neem aan dat je niet de optie hebt om de machine makkelijk down te brengen, dan zou je de disks voor de zekerheid nog eens onderling kunnen wisselen.

Staat er niks in de hardware event logs? Geen idee of een Proliant via IPMI of zo uit te lezen is maar er zal denk ik wel ergens iets gelogd worden.

[Verwijderd]

Schijf 1/3 ziet er inderdaad slecht uit. Die zou ik testenderwijs eens vervangen.

Uit blinde nieuwsgierigheid wil ik wel eens weten waarom je het leven voor jezelf zo complex maakt met al die RAIDs, en dan nog over je RAID-1 volumes heen partities jatten voor software RAID-0.
Niet dat ik nu al weet dat dat de reden is ofzo maar gewoon, in welke categorie spannende groeistuipen mogen we dit plaatsen? Want het lijkt me eerlijk gezegd een klein wonder dat je niet veel gekkere ellende op je dak krijgt met deze setup. Ik kan me namelijk eigenlijk geen gangbare configuratie van een server indenken waar je zoveel partities in een redelijk gangbaar type server gebruiken wilt.

[Kippenijzer]

Ehm, die aic7xxx is de on-board scsi, niet je Raid, en daarop zit hoogstwaarschijnlijk gewoon iets van een tape apparaat? Toegegeven, hij is redelijk "slecht" aangesloten als hij slechts UW ondersteund (meeste huidige tape-drives ondersteunen iig *een* LVD variant).

[Rolfie]

Heb je de laatste BIOS / Drivers geinstalleerd? Er zitten nog al een aantal bugs in de array controller firmware. Laatste drivers scheelt ook nog vaak een hoop performance, Laatst zijn er nog al wat verbeteringen aangebracht in de drivers.

[krietjur]

Ben er inmiddels ook achter gekomen dat die aic7xxx de scsi-controller van de tape-streamer is
Er hangt een HP Dat72 streamer aan.

Blijf ik natuurlijk nog wel met de performance van de raid-arrays zitten. Kan ik daarvan nergens iets vinden in /proc? Als ik /proc/scsi/scsi cat dan krijg ik alleen de tapestreamer te zien, behalve de aic7xxx staat er ook niks meer onder /proc/scsi.

In de logfiles heb ik nog niets kunnen vinden. De server is niet door mij opgezet, en ik vond de setup met een software raid over de hardware ook vrij apart. Dit ga ik vandaag even veranderen, kijken of dat iets verandert. De machine down gooien of "zomaar ;)" dingen proberen is geen optie. Nieuwste drivers zitten er zeker niet op, de machine wordt niet up-to-date gehouden omdat dingen installeren etc min of meer verboden is op de machine ...

Ik speur nog weer even verder..

edit:

Firmware versie van de raidcontroller is 2.32 ben ik achter gekomen via /proc/driver/cciss/cciss0, volgens de HP site is 2.58 de nieuwste versie. Versie van de driver zelf heb ik nog niet gevonden.

Als ik de drivers ga upgraden, moet ook de kernel geupgrade worden.. dat wordt nog wat Even een identieke testmachine bestellen zal er niet bij zijn vrees ik

[ Voor 20% gewijzigd door krietjur op 21-02-2006 11:34 ]

[Verwijderd]

Wij hebben zelf ook zo'n server met precies dezelfde controller. Hiermee zijn een aantal problemen bekend betreffende de accu's die op deze controller zitten. Normaal kun je deze fout ontdekken via de array control manager van HP onder windows. Ik weet niet of HP een linux versie hiervan heeft.

Het gekende probleem is dat de accu's door een fout in de firmware worden overladen en vervolgens kapot gaan. Het cache geheugen op je controller zal hierdoor uitgeschakeld worden, waardoor de prestaties aanzienlijk omlaag gaan. Reden waarom het cache geheugen uitgeschakeld wordt bij een kapotte accu is simpel: als er bestanden in je cache zitten en je server valt uit dan ben je deze kwijt. De accu's houden normaal gezien dan de data vast.


Dus wat moet je doen:

Eerst je firmware upgraden naar de laatste versie: zoek even op de website van HP. Hier kun je een cd downloaden voor deze firmware offline te installeren. Daarnaast moet je de firmware appart downloaden en op een diskette zetten. Vervolgens boot je van de cdrom, en geef je aan dat je de firmware wilt laden van een alternatieve bron. Insert de diskette en upgrade de firmware.

Vervolgens wacht je minimaal 24 uur: als de accus nog niet rot genoeg zijn heb je kans dat ze vanzelf weer gaan opladen. Als het probleem blijft bel je HP op en leg je het verhaal van hierboven uit. Indien je een goed onderhoudscontract hebt zullen ze dit komen vervangen. Vraag dan wel of ze allebij de accu's willen vervangen. Bij ons hadden ze dat eerst niet gedaan.

Als de accu's vervangen zijn moet je nog eens 24 uur wachten voordat de accu's opgeladen zijn, daarna schakelt het cache geheugen weer in waardoor je prestaties van je controller weer optimaal zijn.


Groeten,

[krietjur]

Bedankt voor je reactie! Ik zag op de HP site dat ze een Array Diagnostic Utility for Linux beschikbaar hebben, wellicht dat dat de Linux variant is van het programma waar je over schrijft. Upgrade van de firmware moet dan toch maar gaan gebeuren, moet dan echter ook de drivers upgraden en een iets recentere kernel gaan gebruiken. Geen gigantisch probleem opzich, alleen niet iets dat ik op korte termijn kan doen, of ik moet wellicht een keer in het weekend ermee aan de slag gaan. Hoe dan ook, ik ben weer een stukje verder, bedankt! Ik zal ook zeker de afloop nog posten

HP provides an ADU to help you quickly identify such problems as the following:
An incorrect version of firmware
Drives installed in the wrong order
Inappropriate error rates
A failed battery on the array accelerator board

In elk geval het goede tooltje dus.. wellicht dat het ook beschikbaar is vanaf de smartstart cd zonder iets te installeren, dat zou nog mooier zijn..

[ Voor 26% gewijzigd door krietjur op 22-02-2006 09:15 ]

[Rolfie]

In elk geval het goede tooltje dus.. wellicht dat het ook beschikbaar is vanaf de smartstart cd zonder iets te installeren, dat zou nog mooier zijn..

Als het goed is wel, Let echter wel even op of de array controller drivers update zijn, voodat je de BIOS update. Anders kan het zijn dat je problem gaat krijgen.

[krietjur]

Ja dat had ik gelezen, maar ik wil eerst maar eens kijken met dat ADU tooltje of dit inderdaad het probleem is. Als dat zo is wordt het kernel updaten (huidige kan de nieuwste drivers nog niet aan), driver updaten en dan de firmware updaten. Moet ik alleen wel even een gunstig moment uitzoeken om de server plat te gooien en dat ADU tooltje te gaan draaien..

[krietjur]

Nou, de server is inmiddels een keer gereboot en heb vanaf de Smart Start cd de ADU tool gedraaid. Het is (helaas ) geen defecte batterij in de controller, dus de oorzaak van de performance problemen heb ik nog niet gevonden. Ik ga wel binnenkort de firmware en de drivers van de raidcontroller updaten, wellicht dat dat het probleem wel oplost.

edit:

Ook nog even de software raid weggehaald, omdat dat een beetje een rare configuratie was.. heeft het probleem overigens niet opgelost

[ Voor 18% gewijzigd door krietjur op 06-03-2006 13:41 ]