[Exchange2k] Trager wordende mail store

[Verwijderd]

Situatie schets:

1e server: P3 1,1 GHz, 512MB (40% vrij) RAID1 36 GB.
2e server: P4 xeon 1,8 GHz, 2048MB (25% vrij) RAID5 100GB.
Beide w2k SP3.

De 1e server wordt gebruikt als SQL2k server.
De 2e server wordt gebruikt als Exchange2k, OWA en file server.
De exchange server bevat een 50-tal mailboxen met in totaal 200000 mails.
De Information Store is nu zo'n 8 GB.

Probleem:
Na een paar dagen tot een week lijkt het alsof de Information Store dicht slibt.
Alle clients kunnen zich nog wel aanmelden op de Exchange server, krijgen in Outlook ook al hun mail subjects ed. te zien, maar zodra iemand een mailtje opent (dus als de body cq attachments opgehaald worden) krijg je een melding met progress bar dat Outlook gegevens aan het ophalen is van de Exchange server. Dit blijft een minuut of 5 staan, waarna Outlook het opgeeft.

Zodra ik in dit geval de Information Store probeer te stoppen krijg ik een melding als "service did not react to stop command in given time period" oid. Iig, de service probeert te stoppen maar het lukt niet binnen de tijd die de service manager ervoor over heeft.

Dit heb ik al gedaan:
De databases worden dagelijks met een full backup naar tape geschreven, wat altijd goed gaat. De gehele Information Store is dus goed te lezen.
Ook met een offline defragmentatie met eseutil kwamen geen foutmeldingen naar boven.

De 1e server is laatst benoemd tot Global Catalog en dit is bij de Exchange server uitgezet. Hierdoor moeten alle searches op het adresboek nu door de 1e server afgehandeld worden, wat ook gebeurd. Dit was bedoeld als load vermindering voor de Exchange server.

Verder kan ik geen fout- of errormeldingen vinden in mijn Eventlog.

De enige oplossing die wel werkt is het compleet restarten van de Exchange server.

Iemand nog enig idee waar ik naar zou kunnen kijken?

[intert0y]

Ik heb deze problemen ook bij bepaald soort e-mailtjes. Het lijkt dan net ofdat het aan alleen dat ene meeltje ligt. Ik heb meerdere oplossingen hiervoor (maar wel omslachtig en het probleem komt zo nu en dan terug)


1) Inloggen via outlook webaccess en het brakke e-mailtje opzoekn (Wat doorgaans niks braks aan is, geen virus lijkt te bevatten of wat dan ook). en trashen.

2) En als dat niet werkt. Gewoon vanuit je outlook de boel exporteren naar .pst dan de hele mailbox trashen. Nieuwe aanmaken en de boel weer inmporteren. Dit werkt vaak.

Maar het zijn en blijven klote oplossingen. Ik kan ook maar niet vinden waar het nu ECHT door komt, dat opeens een e-mailtje de hele boel in de war schopt. Het lijkt er ECHT op dat het 1 bepaalde e-mail is die het probleem veroorzaakt.

[Jazzy]

Heb je op Technet gezocht?

[mutsje]

Heb je performance monitor al eens geopend en een logging gemaakt met de Exchange counters / pagefile counters / cpu / mem counters... en dit een tijdje laten lopen zodat je een analyse kunt maken waar jou bottleneck zit. Ook de counter van je NIC erin zetten. Meestal is niet de server de bottleneck maar het netwerk.

[Arno]

Jazzy schreef op 10 April 2003 @ 12:26:
Heb je op Technet gezocht?

Zeg dan niets

TS: heb je de laatste SP en alle hotfixes draaien? Er zijn wat known issues met store.exe in Exchange

[mutsje]

Men mag toch aannemen dat TS de laatste service pack en dergelijke geinstalleerd heeft..

[Verwijderd]

Op dit moment staat SP3 geinstalleerd. Op 24 maart is er een Security Rollup uitgekomen voor SP3, die zal ik vanavond installeren.
Er staan idd een aantal fixes in voor de Information Store, misschien dat deze melding er ook door opgelost wordt.

Performance monitor heb ik ook aangezet, alleen weet ik niet of ik de juiste Exchange counters gekozen heb. Ik had MSExchangeIS\Read Bytes RPC Clients/sec & MSExchangeIS\Write Bytes RPC Clients/sec gekozen. Verder nog Memory, CPU, Disk & Pagefile. Zijn dit de counters die je bedoelde?

[Arno]

mutsje schreef op 10 april 2003 @ 14:41:
Men mag toch aannemen dat TS de laatste service pack en dergelijke geinstalleerd heeft..

True, maar helaas komen er ook hobby figuren in PNS die net koud Exchange hebben geinstalleerd

[mutsje]

tragisch maar waar... en zelf niet lopen troubleshooten maar een kant en klare oplossing verwachten maar we gaan lekker offtopic op deze manier

[Verwijderd]

De post-SP3 rollup is geinstalleerd zonder problemen.
Ik ga het nu de komende paar dagen even aankijken met de performance monitor, en hopelijk is het probleem nu verholpen.

[Brahiewahiewa]

Verwijderd schreef op 10 April 2003 @ 12:18:
[...]
2e server: P4 xeon 1,8 GHz, 2048MB (25% vrij) RAID5 100GB.
[...]

Wil je hiermee zeggen dat je één groot RAID5 volume hebt, waar je zowel je Exchange databases als je Transactielogfiles op hebt staan? Dan is het niet zo vreemd dattie performancegewijs instort. Voor een beetje een serieuze Exchange 2000 server wil je het liefts een stuk of zes fysiek gescheiden schijven:

System C: -> RAID1
Pagefile D: -> RAID0
Databases E: -> RAID5
Transactielogs F: -> RAID1
SMTP queues G: -> RAID1
Fulltext indexes -> H: RAID0

En dan, omdattie ook file server is, nog aparte schijven voor je file shares.
Dit is de ideale situatie. Je kunt, met geringe impact op je performance, de C:, D:, G: en H: drives op hetzelfde volume hebben, maar je databases en je transactielogfiles moeten ècht elk op een dedicated spindle.

[Taigu]

IMHO is bovenstaande licht overdreven, het is een ideale situatie, maar in dit geval geen ralistische situatie. Een exchange server met 50 mailboxen zou prima moeten draaien op een RAID-5 schijvensetje.

[Bartjo]

Als het feit dat de logs en database op 1 volume staan de performance zou doen crashen, zou dat dagelijks, nadat de full backup heeft plaatsgevonden, weer moeten zijn verholpen.

Alle logs worden immers gecommit en getrashed bij een full backup.

[Brahiewahiewa]

Bartjo schreef op 13 april 2003 @ 17:53:
Als het feit dat de logs en database op 1 volume staan de performance zou doen crashen, zou dat dagelijks, nadat de full backup heeft plaatsgevonden, weer moeten zijn verholpen.

Alle logs worden immers gecommit en getrashed bij een full backup.

Je begrijpt er niks van: transacties naar de exchange databases worden eerst naar de transactielogs geschreven, pas daarna naar de database files. Da's ook het enige wat er met die transactielogs gebeurt: er wordt naar geschreven; ze worden vrijwel nooit meer gelezen, alleen maar tijdens het backuppen en tijdens het restoren van een backup.
Maar als dat schrijven niet opschiet, wegens er op de schijven gezocht moet worden naar van alles en nog wat, gaan die transacties in RAM gebuffered worden. Na een paar dagen tot een week past die buffer niet meer in RAM en gaat gepaged worden naar schijf en dan stort de performance in

[Verwijderd]

Ik begrijp je argumenten, en ben het er op zich wel mee eens.
Echter:
Er wordt elke nacht een full backup gedraait. Hierdoor staat er op z'n max logfiles van 1 dag.
Ook komt volgens de performance counters de Disk Usage niet boven de 50-60% uit.
Ik dacht dat disk performance pas vanaf 80% instortte.

De machine komt eigelijk nooit boven de 75% memory gebruik, waarvan Store.exe dan weer max 1Gb van inneemt. Hierdoor lijkt het me ook onwaarschijnlijk dat paging een oorzaak kan zijn. Volgens de performance counters blijft Pagefile Usage op 3% schommelen.

Maw. het zou heel goed kunnen dat het wel de oorzaak is, maar het lijkt er eigenlijk niet op.
En met alleen denken dat het zou kunnen, krijg ik geen twee losse disks besteld voor de transactie logs.

Is er misschien bepaalde software bekend die conflicteerd met Exchange? Met google komt helaas niet echt iets bruikbaars naar boven.

[paulhekje]

wat voor virusscanner draai je? en is M: exclude?

[mutsje]

zoals Brahiewahiewa al vermeld moet je de logfiles en dergelijke niet allemaal op 1 partitie proppen. Ook niet in een kleine organistatie. Zelfs thuis 10 mailboxen heb ik apparte partities aangemaakt vanwege de performance. Was me nog niet eens opgevallen hoe jij de boel ingedeeld hebt.

[Verwijderd]

We draaien hier Symantec AntiVirus, zowel voor de exchange als voor de lokale files. En Drive M: en de directories waarin Exchange zijn data en logfiles wegschrijft zijn ge-exclude.

[mutsje]

logfiles en databases moeten sowieso niet op zelfde partities draaien.

[Arno]

mutsje schreef op 14 April 2003 @ 12:03:
logfiles en databases moeten sowieso niet op zelfde partities draaien.

Partities maakt niets uit, andere DISK zou wel veel schelen.

[MADSMILE]

Andere Disk maakt ook weer nix uit, als je een Hware matige RAID controller gebruikt tenminste . Die verdeeld het al netjes over alle schijven in de array/diskgroup .

store.exe vreet altijd veel cpu en memory . Hoe lang duurt het voordat een intern mailtje van de verzender bij de ontvanger arriveerd ( met en zonder attachment ) ??

Mocht de attachment de boel erg vertragen, gooi dan als test de virusmail scanner ff uit , uit ervaring vind ik Norton producten over het algemeen erg gammel/vertragend werken. Voor Exchange is TM Scanmail beste .

Excludes van de file virusscanner niet vergeten .

Wat je ook zo kunnen doen is de algehele netwerkperformance richting de server ( en onderling tussen de GC en de EXCH ) meten . Met een simple ftp sessie ofzo . Mocht het 100 Mb FDuplex zijn zal je makkelijk 12 - 15 Mb / Sec moeten halen , mocht dit niet zo zijn is je netwerkkaart een vertragende factor . ( automatic sense , rotte kabel , slecht perf. driver , irq sharing, geen nutteloze protocollen geinstalleerd etc . )

Voor om het netwerk gedeelte uit te sluiten als bottleneck kan je ook gewoon op de server zelf ( lokaal )met outlook ( exp ) mailbox openen en mails verzenden . Mocht dit ook heel erg traag en lang duren , zit het toch echt in je Exchange config . misschien multiple storage groups aanmaken .

[ Voor 87% gewijzigd door MADSMILE op 14-04-2003 20:53 ]

[Zwelgje]

Verwijderd schreef op 14 april 2003 @ 11:41:
We draaien hier Symantec AntiVirus, zowel voor de exchange als voor de lokale files. En Drive M: en de directories waarin Exchange zijn data en logfiles wegschrijft zijn ge-exclude.

la maar, domme opmerking van me... (ik moet beter leren lezen..)

[ Voor 20% gewijzigd door Zwelgje op 14-04-2003 21:15 ]

[Brahiewahiewa]

Als je nou zeker wil weten of je disk systeem de bottleneck wel of niet is, moet je effe volgens Using Diskperf in Windows 2000 de performance counters op je schijven aanzetten (reboot required) en dan kijken naar de counters voor de disk queue length. Als die counters in het begin laag staan en op het moment dat de performance van je server afneemt gaan stijgen, is de kans groot dat je met een aparte schijf voor de log files het probleem kunt oplossen. Als je geen verschil ziet in die queue length, moet je het probleem elders zoeken.

[correctie] Je hebt die diskperf tool niet nodig om de counter Physical Disk | Average Disk Queue Length uit te lezen. Je kun gewoon op de server zelf of op een workstation PerfMon opstarten en die counter in het grafiekje zetten. Als je het update interval dan op 1800 sec. zet en je ziet het grafiekje aanmerkelijk stijgen, kun je er veilig van uitgaan dat je schijfsysteem de bottleneck is. [/correctie]

[ Voor 26% gewijzigd door Brahiewahiewa op 15-04-2003 10:52 ]

[Verwijderd]

Ik heb de counters aangezet, en zal over een paar dagen de resultaten posten.

[mutsje]

ok. ben erg benieuwd.

[heuveltje]

is er nou een oplossing gevonden ?

[Verwijderd]

Na een weekje performance logs loggen komen er een paar pieken naar boven op bepaalde onderdelen.

Piek een gebeurd van 6:45 tot 8:00 s'ochtends.
Piek twee gebeurd van 9:15 tot 10:00 s'ochtends.

Tijdens deze pieken gaat cpu usage naar 70% en disk write time gaat naar 55%.
Verder Pagefile Usage 3%, Free Memory 540MB. Beide constant over meerdere dagen.

Virusscan gebeurd een keer per week om 23:00 s'avonds. Exchange database management gebeurd van 19:00 tot 0:00. Backup Gebeurd van 0:00 tot rond 6:00. Er zijn verder geen andere processen ge-scheduled.

Ik kan geen reden bedenken waarom het systeem rond deze tijden spontaan aan de slag gaat. Iemand anders wel?

[Brahiewahiewa]

Verwijderd schreef op 22 april 2003 @ 23:36:
[...]Ik kan geen reden bedenken waarom het systeem rond deze tijden spontaan aan de slag gaat. Iemand anders wel?

Genereren van full text indices?

[Taigu]

06:45: Misschien verify van de backup ?
09:15: aanmelden gebruikers ?

[Verwijderd]

06:45: Backup is inclusief verify afgerond om 06:00.
09:15: Gebruikers... Tsja, het kan. Maar de meeste mensen hier komen rond 9:45 tot 10:00 binnen.

Full text indexes, bedoel je de search catalogs van win2k zelf, of iets specifieks van Exchange? Zouden die niet met de database maintenance meegaan?

Blijkbaar zijn sommige mensen het probleem zat, want er is spontaan budget voor een aantal extra disks.
Nu is mijn idee om het systeem als volgt in te delen:
2x18GB -> 15GB OS & 3GB swap
2x36GB -> 36GB User files
2x36GB -> 36GB Exchange database
2x18GB -> 18GB Exchange logs

Na alles wat ik gelezen heb lijkt dit me een redelijk ideale indeling.
Iemand het hier wel/niet mee eens?

[heuveltje]

staat dat toevallig op hoog bij jouw ?

(kan zelf ff niet vinden waar het gescheduled word )

ok kun je en/dis ablen en schedulen per storage group
maar dat moet specifiek aangezet worden, dus dat zal het wel niet zijn

BTW als jij degene bent die verantwoordelijk is voor exchange. en je weet niet wat full-text indexing is ? beetje vreemd imho ?

PS
50-tal mailboxen met in totaal 200000 mails
is dat een tikfout ?
ik kan me namelijk niet voorstellen dat a:
50 users een fatsoenlijke raid-array kunenn volkrijgen (kwa performance)
50 users gemiddeld elk 4000 mailtjes in hun archief hebben ?

ik heb zo'n vermoeden dat je die diskgebruik-pieken wel eens bij de file-server konden zitten ?

[ Voor 76% gewijzigd door heuveltje op 24-04-2003 17:16 ]

[Verwijderd]

Full text indexing stond idd op high. Heb dit naar low gezet, misschien dat het uitmaakt.

Aantallen kloppen wel. De grootste mailbox hier bevat bijna 800 MB aan data, en de hoogste Total Items Count is 30.285.
Het bedrijf heeft veel medewerkers buiten de deur (450), en bijna al het contact daarmee verloopt via email. En omdat mensen bij een beoordelingsgesprek willen kunnen terugvallen op vorige mailtjes moet alles bewaard blijven...

Het is een RAID5 array van 4 36GB 10.000rpm disks met 128MB cache op de controller. Ook ik kon me niet echt voorstellen dat deze aan de grens zat, vandaar dat ik hier ben gaan navragen.

En dat ik full-text indexing niet ken.... Tsja, het is nooit te laat om wat te leren.