Performance Exchange op Proliant ML350

[Jazzy]

Hardware
Server:	Compaq Proliant ML350
Processor:	Pentium III 733 MHz
Geheugen:	1280 MB ECC PC133
NIC:	HP NC3161 10/100
Controller:	Compaq Integrated Dual Channel Wide Ultra2 SCSI
Disks:	Compaq BB00912301 (7200 rpm 9.1 GB Ultra2 SCSI)
	Compaq BB00913466 (7200 rpm 9.2 GB Ultra2 SCSI)

Software
OS:	MS Windows 2000 Server SP4
Appz:	MS Exchange 2000 SP3
	Symantec AntiVirus/Filtering for Exchange 2000

Probleem
Wanneer gebruikers overdag in Outlook een mailtje aanklikken waar een attachment aan zitr dan zien ze steeds vaker het schermpje waarin gevraagd wordt om even te wacht op Outlook. Bezig de gevraagde gegevens van de server op te halen oid. (zul je net zien, ik kan hem nu even niet reproduceren )

Dit gebeurt met name bij attachments van > 3 MB maar ook steeds vaker bij andere acties.

Onderzoek
Om te onderzoeken wat het probleem kon zijn heb ik Troubleshooting Exchange 2000 Performance gebruikt. Zo heb ik met de Performance-monitor o.a gemeten:

Disk Transfers/sec (_Total)	Gemiddeld 120-160
Avg. Disk Queue Length (0 C:)	Gemiddeld 1,5 tot 2,5
Avg. Disk Queue Length (1 D:)	Gemiddeld 0,6 tot 1,2

Van de eerste waarde zegt MS dat hij niet boven de 50 uit zou mogen komen, anders kan de schijf de bottleneck zijn. Ook de bij andere 2 waarden staat de streep bijna continu bovenin de grafiek.

Omdat ik nog wel eens wat hoor over performanceproblemen met Symantec AV heb ik een tijdje Filemon gedraait op de volgende processen:
- cqmghost.exe
- Rtvscan.exe
- SMSESJM.exe
- SMSESp.exe
- SMSESp.exe

Nu weet ik niet precies hoe ik het gevondene moet interpreteren, als ik de tijd van alle records per proces optel dan komt dit er uit:

cqmghost.exe	0,25297475
Rtvscan.exe	0,01013426
SMSESJM.exe	19,52320538
SMSESp.exe	5,49772223
STORE.exe	65,0098117

Oplossing
Nu probeer ik de vinger op de zere plek te leggen maar dat is nog niet zo makkelijk. Uit de meetgegevens maak ik op dat de doorvoersnelheid van de schijven niet hoog genoeg is zodat de software op de hardware staat te wachten.

Nu kan ik natuurlijk 2 extra Ultra SCSI2 schijven bijplaatsen en een RAID controller. Dan kan ik RAID 0 draaien en ben ik voor pakweg € 500,- klaar.

Maar...
Het probleem is alleen dat ik niet zeker weet of dit de beste oplossing is, wie zegt me dat ik na deze investering geen problemen meer heb?

Zou het misschien beter zijn om de hele server te vervangen door een nieuwe? Dat kost me pakweg € 5000,- maar dan kan ik weer een tijdje vooruit?

Of meet ik verkeerd en trek ik de verkeerde conclusie? Graag jullie advies.

[paulhekje]

wat is je diskconfig? heb je nu een software mirror of 2 losse schijven?
Misschien kun je nog wat proberen door je logfiles op een andere fysieke disk te plaatsen.
Hoeveel gelijktijdige gebruikers?

[A_De2]

Hmm, als ik het goed heb, draait Exchange voornamelijk op geheugen en Disk I/O. De vraag is dus ook, hoeveel gebruikers je tegelijkertijd hebt ingelogd op Exchange.

Een single disk is dus al gauw te krap :-P

[A_De2]

Btw:
- heb je Exchange Optimizer al gedraaid?
- kan je nic niet de bottleneck zijn? (100/full-duplex?)

[Jazzy]

paulhekje schreef op 23 maart 2004 @ 13:43:
wat is je diskconfig? heb je nu een software mirror of 2 losse schijven?
Misschien kun je nog wat proberen door je logfiles op een andere fysieke disk te plaatsen.
Hoeveel gelijktijdige gebruikers?

Inderdaad, toch nog info vergeten.

Nu zijn het gewoon 2 losse schijven, 1 C en 1 D-schijf. De logfiles staan op samen met de database op de D: schijf, die wordt al minder belast dan de C-schijf. Pakweg 60 gebruikers doe hun Outlook open hebben staan.

[A_De2]

60 users? Hmm, hoeveel geheugen gebruikt de Store.exe? Heb het probleem gehad dat er te weinig geheugen was en de server gaat dan swappen. Is niet best voor de performance.

[mutsje]

Jazzy schreef op 23 maart 2004 @ 13:48:
[...]
Inderdaad, toch nog info vergeten.

Nu zijn het gewoon 2 losse schijven, 1 C en 1 D-schijf. De logfiles staan op samen met de database op de D: schijf, die wordt al minder belast dan de C-schijf. Pakweg 60 gebruikers doe hun Outlook open hebben staan.

Grote kans dat het gewoon een netwerk bottleneck is. Ik heb zelf Exchange5.5 op een proliant 3000 draaien raid5 weliswaar maar met 256mb geheugen en +100 users.. geen probleem what so ever. In het verleden hadden we vaak zelfde error als jij last van hebt en bleek gewoon een network bottleneck te zijn..(lang leve hp openview)

[Brahiewahiewa]

Als het probleem vooral speelt bij (grote) attachments, zou ik gaan zeggen dat de virus scanner de oorzaak is. heb je al eens op de support site van Symantec gekeken of ze een fix hebben voor dit probleem?

Daarnaast kan je schijf configuratie bijna niet optimaal zijn, omdat je maar twee fysieke schijven hebt. Je wilt minimaal 3 fysieke schijven: 1 voor je databases, 1 voor je transactie log files en 1 voor system, pagefile en smtp queues. Ga je ècht serieus bezig, dan doe je die laatste schijf ook door drie fysieke vervangen: 1 voor system, 1 voor je page file en 1 voor je smtp queues

[Jazzy]

A_De2 schreef op 23 maart 2004 @ 13:50:
60 users? Hmm, hoeveel geheugen gebruikt de Store.exe? Heb het probleem gehad dat er te weinig geheugen was en de server gaat dan swappen. Is niet best voor de performance.

Store.exe gebruik ongeveer 800 MB en ik heb niet de indruk dat hij swapt.

mutsje schreef op 23 maart 2004 @ 13:55:
Grote kans dat het gewoon een netwerk bottleneck is. Ik heb zelf Exchange5.5 op een proliant 3000 draaien raid5 weliswaar maar met 256mb geheugen en +100 users.. geen probleem what so ever. In het verleden hadden we vaak zelfde error als jij last van hebt en bleek gewoon een network bottleneck te zijn..(lang leve hp openview)

Dat blijkt dus niet het geval te zijn, ik heb de doorvoer gemeten met de performance monitor. Bovendien verklaart dat niet waarom de Avg. Disk Queue Length op schijf C: voortdurend te hoog staat. Volgens MS mag die maximaal 0,5 zijn maar bij mij is het geregeld 3,5. Dat is een overschrijding van 600%!

Brahiewahiewa schreef op 23 maart 2004 @ 14:33:
Als het probleem vooral speelt bij (grote) attachments, zou ik gaan zeggen dat de virus scanner de oorzaak is. heb je al eens op de support site van Symantec gekeken of ze een fix hebben voor dit probleem?

Ik snap je suggestie maar ik wil dus graag weten wat het probleem is zodat ik gericht kan gaan oplossen. Wanneer de virusscanner de oorzaak is dan wil ik dat uit mijn meetgegevens kunnen aflezen, uit het tabbelletje met schijfacties van de processen komt store.exe als de meest aktieve uit de bus.

Overigens heb ik wel gekeken bij Symantec en niet concreets gevonden.

[Brahiewahiewa]

'k Zou beginnen met het toevoegen van een schijf tbv de transactie log files van je Exchange databases. Er zijn namelijk 2 redenen waarom je dat op een dedicated spindle wilt:

1. performance
2. disaster recovery

Ander vraagje: die SMSESJM.exe en SMSESp.exe zijn dat niet de executables van de Norton file based virusscanner? Ben je niet ontzettend bezig om je database en transactie logs op file niveau op virii te scannen? Of heb je al die files keurig in het lijstje met exclusions opgevoerd?

[Jazzy]

Brahiewahiewa schreef op 06 april 2004 @ 11:09:
'k Zou beginnen met het toevoegen van een schijf tbv de transactie log files van je Exchange databases.

De logs staan al op de 2e schijf, de D:-schijf. Het performance probleem treed op op de C: schijf.

Ander vraagje: die SMSESJM.exe en SMSESp.exe zijn dat niet de executables van de Norton file based virusscanner? Ben je niet ontzettend bezig om je database en transactie logs op file niveau op virii te scannen? Of heb je al die files keurig in het lijstje met exclusions opgevoerd?

Die processen zitten voornamelijk aan tijdelijke bestanden in C:\WINNT\temp en C:\Program Files\Symantec\SAVFMSE\Temp.

Bijvoorbeeld:
C:\WINNT\TEMP\tmp6731.tmp
C:\Program Files\Symantec\SAVFMSE\Temp\SJM6732.tmp

Als je denkt meer info uit het log te kunnen halen dan wil ik hem wel even online zetten.

[Spoooky]

Het kan handig zijn om de database te defragmenteren... Hoe lang draait die server al?

[Arfman]

Jazzy schreef op 23 maart 2004 @ 13:24:
Probleem
Wanneer gebruikers overdag in Outlook een mailtje aanklikken waar een attachment aan zitr dan zien ze steeds vaker het schermpje waarin gevraagd wordt om even te wacht op Outlook. Bezig de gevraagde gegevens van de server op te halen oid. (zul je net zien, ik kan hem nu even niet reproduceren )

Dit gebeurt met name bij attachments van > 3 MB maar ook steeds vaker bij andere acties.

Ergo: het heeft ooit goed gedraaid met dezelfde server em hetzelfde aantal users, right ? Dan kunnen we het netwerkverhaal en antivirusmeuk overboord gooien, en is het dus iets wat misschien fysiek in die server niet lekker zit (heb je Insight Manager draaien ? Dan kun je het wellicht zien) of iets dergeljiks als een gefragmenteerde database.

[Verwijderd]

De server zóú goed genoeg moeten zijn.
ik heb op een zelfde proliant ml350 maar met maar 768 MB geheugen ex5.5 draaien met 50 users, en daar worden écht wel grote filetjes verkast van user naar user (denk unrestricted mailbox size) plus er staat nog een MSSQL database naast die volcontinue gebruikt wordt door twee databases op andere servers en weer die 50 gebruikers. Hiernaast draait nog McAfee Netshield, Groupshield Exchange en natuurlijk is deze server ook nog de opslag server voor alle userdata (small business - the ultimate stresstest for your server)
Hierbij wil ik nog even het ellende beeld schetsen dat de server 2 disks heeft, C/D en F, waar disk C/D alles bevat, de SQL db, exchange, een deel van de userdata en de foto collectie van de directeur, en de F drive is een losse bijgeprikte disk waar nog meer userdata op staat plus alle installatie files die ik vaak nodig heb.

Exchange is niet traag hierop, alleen als je een attachment van zeg 50 mb of meer wilt hebben moet je even wachten (maar OK, 50 MB attachments moeten ook niet tot je normale bedrijfsbezigheid horen)
Misschien helpt deze mededeling je wel niet zo veel, maar ik wil alleen maar aangeven - je server is zwaar zát. Het moet dus volgens mij zonder investering (in hardware dan) opgelost kunnen worden.