Exact globe 2003 op SQL 2005 performance problemen.

[Verwijderd]

Hallo,

Ik heb een Exact globe 2003 draaien voor de complete boekhouding orderintake/flow. Nu hebben we volgende server konfig:

Compaq Proliant ML P4Xeon 2.0Ghz, 4Gb intern, Raid 5 systeem met Scsi disks.

Alleen de database van exact draait op deze server.

Probleem:

De performance van de server gaat zo rond de middag totaal onderuit. (op aanraden exact doen we elke nacht een reboot van de server) De database is nu 47,5Gigabyte (jawel gigabyte) groot. Ze draait op SQL2005 op een Windows 2000 server. We hebben 20 clients met W-XP Pro en niet ouder dan 3 jaar. Een 100mbit Cat5e netwerk.

De server begint te hikken als hij op 1.7Gb intern geheugen in use staat. Daaronder draait ie nog ok, erboven worden de performance problemen steeds groter wat t werken in de middag steeds frustrerender maakt.

Wat kan hier t probleem zijn. (Ok grote Database, maar wel 4Gb intern!!). Er zijn veel Exact kenners al geweest en ze kwamen er niet uit. Er is gemonitord, hardware getest etc etc.. dit was t allemaal niet. Maar wat wel???

Voor de Exact/SQL kenners onder ons denk ik een leuk probleemgeval.

[Dromer]

Mja... database van die grootte, dan is 4GB ineens niet zoveel geheugen hoor.
Ik zou het toch die kant is opzoeken.
Ook zou je nog iets met je logfiles e.d. kunnen doen door die op een andere raid te zetten.

[nightowl]

Mijn vermoeden zou uitgaan naar caching van de transacties. Het lijkt erop dat er veel 'pending' transacties zijn die niet direct naar de database geschreven worden. Dit zou dan een probleem kunnen geven ivm record locking. Is er naar de locking gekeken? Wordt er gebruik gemaakt van 'write-cache'? Dit wil ook nog wel eens problemen geven onder Exact. De grootte van de database zou mijns inziens het probleem niet mogen zijn.

Treedt er 'memory leak' op of wordt gealloceerd geheugen niet goed vrijgegeven? Dit zorgde in het verleden namelijk nog wel eens voor problemen.

Kortom: caching, write-cache, memory leakage?

[Abom]

Er is gemonitord, hardware getest etc etc.. dit was t allemaal niet. Maar wat wel???

Heb je de uitkomsten van dat monitoring? Misschien dat wij hier toch een andere conslusie trekken uit de uitkomsten.

Verder is het heel nuttig om de exacte configuratie van je schijven te geven, ik denk dat daar het probleem in zit, hoeveel disks per array, welke controller, hoeveel cache (met of zonder BBWC). Ik ben vooral benieuwd naar de average queue length van de verschillende logical disks.

Wanneer Exact op dezelfde server draait als SQL server, kan het belangrijk zijn om het te claimen geheugen voor SQL server te limiteren. SQL server gebruikt al het geheugen wat het kan krijgen (als het nodig is).

[ Voor 27% gewijzigd door Abom op 22-02-2006 18:37 ]

[wizl]

47.5 Gig voor een Exact database waar je met 20 clients in zit te werken? Vraagje! Hoeveel daarvan is data, en hoeveel log? Met andere woorden. Hoe groot zijn je .MDF en .LDF files op de schijf?

[edit] heeft iemand niet 'per ongeluk' het recovery model van die database op bulk logged gezet?

[ Voor 21% gewijzigd door wizl op 22-02-2006 23:52 ]

[Powermage]

eigenlijk is er verder niks zinnigs toe te voegen:
47 GB is een belachelijk grote db, maar als dat wel klopt controleer vooral je raid controler, zit er een smart array 64xx met accu erop waardoor hij een write cash heeft??, ik heb dit weekend (weliswaar een ander pakket) een server gemigreerd van een smart array 532 naar een 64xx met 256 MB bbu cash, ding ging zo snel dat de specialist van die software versteld stond hoe snel het ging.

[markjuh]

Ik ken een redelijk aantal exact installaties maar 47,5 GB is echt belachelijk. Luister naar wizl zegt over de logging. Dus hoe groot is het totaal aan log files? En hebt je bulk logging aan staan? Wij hebben klanten met echt behoorloorlijk intensief gebruik van SQL en gigantisch veel transacties en daar is bv de log van een DB van 35 GB hooguit 500 mb. Dit is dan wel geen Exact in dit geval maar principe is hetzelfde.

Verder, heb je op je raid write back cachce aan staan? aangezien je raid 5 draait met een DB. sowieso vind ik persoonlijk raid 5 niet een geweldige oplossing. iig niet zonder write-back caching.

Waarom heb je niet een Riad 1 array voor je os, een raid 10 voor je DB en raid 1 of raid 10 voor je logging? Als je zulke grote DB's host is dit echt geen overbodige luxe.

Doe eens een shrink database om te kijken of hij kleiner wordt.

[ Voor 6% gewijzigd door markjuh op 23-02-2006 09:33 ]

[_Arthur]

Verwijderd schreef op woensdag 22 februari 2006 @ 15:27:
Probleem:

De server begint te hikken als hij op 1.7Gb intern geheugen in use staat. Daaronder draait ie nog ok, erboven worden de performance problemen steeds groter wat t werken in de middag steeds frustrerender maakt.

Indien de Windows 2000 versie Advanced Server is: staat de /3gb switch in de boot.ini van de server? Hierdoor kunnen applicaties geheugen toewijzen over de standaard 2gb/applicatie grens heen. Zie ook: http://www.microsoft.com/...rm/server/PAE/PAEmem.mspx
Indien het Windows 2000 Standaard is: deze optie NIET gebruiken.

En wat is de max size van je pagefile?

[Verwijderd]

Dit probleem heb ik recent ook meegemaakt (wel met een wat kleinere database, 8 gb)..

De oplossing bij mij was om de database 's nachts te laten reorganiseren. In de SQL manager, onder Database management plans kan je dit instellen...

Na 1 run was de snelheid vertienvoudigd... Deze reorganisatie word nu wekelijks uitgevoerd ..

[Ralphie]

Markjuh schreef op donderdag 23 februari 2006 @ 09:32:
Ik ken een redelijk aantal exact installaties maar 47,5 GB is echt belachelijk. Luister naar wizl zegt over de logging. Dus hoe groot is het totaal aan log files? En hebt je bulk logging aan staan? Wij hebben klanten met echt behoorloorlijk intensief gebruik van SQL en gigantisch veel transacties en daar is bv de log van een DB van 35 GB hooguit 500 mb. Dit is dan wel geen Exact in dit geval maar principe is hetzelfde.

Verder, heb je op je raid write back cachce aan staan? aangezien je raid 5 draait met een DB. sowieso vind ik persoonlijk raid 5 niet een geweldige oplossing. iig niet zonder write-back caching.

Waarom heb je niet een Riad 1 array voor je os, een raid 10 voor je DB en raid 1 of raid 10 voor je logging? Als je zulke grote DB's host is dit echt geen overbodige luxe.

Doe eens een shrink database om te kijken of hij kleiner wordt.

Ik denk dat alle RAID controller settings wel goed staan, aangezien de TS de problemen pas heeft als het intern geheugen rond de 1,7GB komt.

Ts: waar staat je pagefile? Op een zelfde partitie als de logs of de database bestanden? En laat inderdaad die performance logs eens zien. Database op een RAID 5 is eigenlijk "not done", zeker niet als hij van die gigantische groottes heeft. En zoals Abom al zegt, vooraal de average disk queue length is er belangrijk. Dat is bij ons ook ooit een probleem geweest met een database server

[mbaltus]

Er zijn heel veel dingen waar je naar kunt kijken. Ik denk dat we met z'n alle wel honderden tips kunnen geven, maar je zult eerst de oorzaak van het probleem (traagheid) moeten achterhalen.
- tekort aan intern geheugen
- teveel diskactiviteit
- teveel processorkracht benodigd
- netwerkbelasting (lijkt me minder het geval)

Daarbij moet je rekening houden met een ketting van gevolgen. Als je OS/apps uit het geheugen worden gedrukt door de SQL Server (geswapt zeg maar), dan kan hierdoor de diskactiviteit enorm toenemen, maar het betreft dan toch een RAM probleem. Check bijvoorbeeld even hoeveel RAM er door SQL Server gebruikt mag worden. Check inderdaad ook even de /3GB switch van je boot.ini.

Wat me in ieder geval wel interesseert is dat je performance probleem gedurende de dag toeneemt. Of misschien vanaf 's middags erger is. Draait er misschien een batch-job of iets op de server. Of wat gebeurt er voor bijzonders dat het 's ochtends weer over is.

De vraag is ook of je database/logs 47GB groot zijn, of dat er 47GB gereserveerd is op je disks, maar aanzienlijk minder gebruikt wordt.

[TheRookie]

Op welke batch draaien jullie ?
Gebruiken jullie alleen Globe, of ook eSynergy ? (geintegreerd of niet)
Is de performance drop toevallig samengevallen met een upgrade van batch?

@mbaltus: server wordt 's nachts gereboot dus wordt er 's ochtends weer met een 'schone lei' begonnen ...