Ik ben al een tijdje aan het zoeken waarom ons serverpark zo megatraag is.

Wij maken sinds een half jaar gebruik van 2 esx servers die gekoppeld zijn via qlogic hba's een SB1404 fc switch aan een ibm 3400 san.

Na lang zoeken en testen lijkt het er op dat de schrijfsnelheid niet voldoende is.

Nu heb ik weinig tot geen ervaring met performance tuning en ben nog geen ster in een esx omgeving. Ik heb al wel contact met ibm maar die geven aan dat ze eigenlijk alleen verstand hebben van het san en wijzen me richting een redbook van de ds4000.

Ik heb een printscreen bijgevoegd van een esxtop scherm tijdens slechte performance van de exchange (EX1) server.

Graag hoor ik hoe ik deze waarde moet interpreteren, als ik het goed snap zou de QAVG/cmd waarde 0 moeten blijven om een normale performance te houden.

Mijn eerste post hier dus niet te hard schelden als ik meer info had moeten posten.
Ik hoop dat jullie me op weg kunnen helpen dit probleem te tackelen.

Hallo Marco,

Nog niet zo lang geleden is een pracht document geschreven over ESXtop en de interpretatie daarvan.

http://communities.vmware.com/docs/DOC-9279

Daarnaast heeft ook VMware een paar dagen geleden een pdf gereleased over Exchange op VMware esx. Wellicht dat dit je opweg kan helpen.

Tomas

Had ik inderdaad ook gevonden en geeft erg veel informatie.

maar

* QAVG

The average queue latency. QAVG is part of KAVG.

Response time is the sum of the time spent in queues in the storage stack and the service time spent by each resource in servicing the request. The largest component of the service time is the time spent in retrieving data from physical storage. If QAVG is high, another line of investigation is to examine the queue depths at each level in the storage stack.

na deze verklaring weet ik bijvoorbeeld niet zo goed waar dan verder te zoeken

En wanneer is bv de DAVG waarde te hoog voor een normale response ?
bij 10, 20 ,50 of 100ms

Ben zelf samen met IBM een behoorlijke stap verder gekomen.

Na wat speurwerk zijn we er achter gekomen dat alleen de read cache op het SAN aan stond en de write cache niet...

Dit staat inmiddels aan en nu zijn de write latenty tijden gezakt van constant 10+ms naar 0ms met zo nu en dan piekjes tot 3-4ms

Wat nu nog rest zijn de inlogtijden van clients op de terminal servers maar daar heb ik voldoende leesvoer en uitleg voor gevonden.

Dat maakt idd heel wat uit