Perfomance issue

Didden

Ik heb een probleem met performance.

Sinds vorig weekend zijn wij navision gaan draaien op een HP 350 G5 met Dual Core 5130 Xeon 2.0 gHz met 2 gig geheugen (4 x 512).
Cache voor server staat op 756000 bytes en kan niet hoger.

Nu is de performance voor het importeren van orders en zoek functies wel drastisch verberterd echter met het boeken van de leveringen en facturen is de tijdwinst bijna 0 %.

Ik zie tijdens het (batch)boek process ook maar een gebruik van 0 tot 5 % van de processor.
De optimalisatie van het process uitzetten, een slaap functie tussen opdrachten, levert wel performance op maar blokkeerd andere gebruikers.

Onze oude server, een PIII 1 gig, dual processor met 1 gig geheugen deed net zo lang over het boekings process.

Waar kan dit aan liggen.
We draaien nu met W2k3 en Navision 3.6 op een 2.6E database.

kriki

-Staat de COMMITCACHE aan?
-Gebruik geen RAID5, maar RAID1

Marije_Brummel

De beste methode om bij C/SIDE databases performance metingen te doen is met de 'advanced' client monitor.

Deze kun je vinden op de tools cd.

Na het starten en stoppen van de gewone client monitor open je form 105020 vanuit de objectdesigner, deze 'flattened' de data naar 1 transactie per regel.

Deze kun je vervolgens exporteren naar excel en in een pivot table zetten, hiern zie je exact welke tabel en/of codeunit de vertraging veroorzaakt.

Voila; een tip van de meester.

Waldo

Let op dat een native server slechts 1 gig en 1 processor kan gebruiken. Een upgrade van server heeft dus het meeste zin als je de schijven onder handen neemt.
De database opsplitsen in meerdere files, en deze verspreiden over meerdere fysieke disks in RAID 1 (nooit RAID 5, zoals kriki reeds heeft aangegeven).

Didden

Bedankt Mark, ik zal dit eens gaan proberen.

Verder voor de schijf indeling hebben wij Raid1+0 (Stripe)
Het zijn S-ATAII schijven met 16mb cached 250 gig groot, 7200 rpm.
Er zijn 3 partities op 2 (virtuele) schijven, de data base is 2 x 70 gig die over de 2 schijven zijn verdeeld.
En natuurlijk staat CommitCache aan.

Ik merk dat navision wel sneller is met het opbouwen van lijsten en overzichten oproepen, het is gewoon het boekingsprocess waar de vertraging in zit.

Ik heb ons NSC al ingelicht en gevraagd of zij hier iets op kunnen vinden.

kriki

Ik vermoed dat er in de boekingsroutine ergens een record gezocht wordt waarbij er een verkeerde sleutel gebruikt wordt. In dat geval moet Navision de hele tabel scannen.
Dit kun je snel merken als er een de statusbar meldingen komen dat Navision een tabel aan het scannen is. En ook met de methode die Mark beschreven heeft.

Waldo

7200 rpm?? Dat is niet goed. dat is naar mijn mening je bottleneck.
Hoe groot is je database eigenlijk?
MIjn voorkeur gaat naar fysiek aparte schijven (2xraid1) en dus de files fysiek opsplitsen. Vergeet niet dat de volgorde van belangrijkheid van hardwaregebruik in geval van een native het volgende is:
1) HD config
2) geheugenconfig
3) CPU

De tip van kriki is nu des te belangrijker: zie dat je commitcache enabled hebt.

Didden

Waldo wrote:

Let op dat een native server slechts 1 gig en 1 processor kan gebruiken.

Dit vind ik raar, want toen ik op onze vorige server een 2e processor plaatste, kon ik in processmanager/taakbeheer op alle 2 de processoren actie zien, welke gelijk was op beide.
En de performance schoot toen ook omhoog.
En die server was puur een Navision server met een client geinstalleerd voor het boekings process.

Waldo

Trust me ... NAV gebruikt slechts 1 processor.
Dit wil natuurlijk niet zeggen dat het OS maar 1 processor gebruikt.

Didden

Waldo wrote:

7200 rpm?? Dat is niet goed. dat is naar mijn mening je bottleneck.
Hoe groot is je database eigenlijk?

Dit is dus 140 gig, waarvan 76 % ingebruik (107 gig)

Waldo wrote:

Mijn voorkeur gaat naar fysiek aparte schijven (2xraid1) en dus de files fysiek opsplitsen.

Hier zitten dus 4 schijven in op 2 fysieke partities, 1 voor c: voor windows en d: voor een stuk database, en dan 1 fysieke raid1+0 (e: ) voor de andere helft van de database.
Dit is dus precies wat jij zegt.
Behalve dat het in Stripe staat, 1 dus voor schrijven en 1 voor lezen.
Dit zou nog sneller moeten zijn.

Waldo wrote:

Vergeet niet dat de volgorde van belangrijkheid van hardwaregebruik in geval van een native het volgende is:
1) HD config
2) geheugenconfig
3) CPU

HD leek zo goed volgens ons, geheugen is 2 gig waarvan 756 mb voor Navision ( dit kon niet naar 1 gig, dan start de services niet op).
Hiervan is slechts 1 gig in gebruik.
Van de CPU zie ik slechts af en toe een spike naar 25-30% als Navision iets opstart, een zware maandlijst bijvoorbeeld.

Waldo

Als je maar 4 schijven in je server hebt, en je het die geconfigureerd in RAID1+0, dan kan je maar 1 logische schijf hebben, die je waarschijnlijk verdeeld hebt in meerdere partities. Voor 2 databasefiles kan je discussiëren wat nu eigenlijk het snelste is, wat we nu niet gaan doen.

Met 140 gig (??) zijn 2 database files in principe veel te weinig (vroeger werd er aangeraden om maximum 2Gb per databasefile te hebben - nu is dat natuurlijk anders).
Theoretisch zou je moeten overgaan naar de 16 files ... en als het budget er is, deze 16 files op logisch en fysiek verschillende schijven zetten. Dit kan RAID1: dan heb je 32 schijven nodig (is inderdaad redelijk moeilijk), of in RAID1+0: dan zou je er 64 nodig hebben (is inderdaad redelijk onmogelijk).
Bottom line: Zoveel mogelijk database files verdelen over zoveel mogelijk logische schijven (geen partities). En één logische schijf is 1 set in een raidconfig.

Ik ben me ervan bewust dat het praktisch moeilijk haalbaar is, daarom is het misschien ook aan te raden om over te stappen naar SQL Server, die beter kan omgaan met grote databases en veel concurrent gebruikers. Opgelet: indien deze weg wordt opgegaan, is er zeker nog heel wat SQL tuning nodig!

kriki

Didden wrote:

Waldo wrote:

Let op dat een native server slechts 1 gig en 1 processor kan gebruiken.

Dit vind ik raar, want toen ik op onze vorige server een 2e processor plaatste, kon ik in processmanager/taakbeheer op alle 2 de processoren actie zien, welke gelijk was op beide.
En de performance schoot toen ook omhoog.
En die server was puur een Navision server met een client geinstalleerd voor het boekings process.

Dus:
-1 processor die de DBserver bediende
-1 processor die de client bediende (vergeet niet dat all processing op de client gebeurt).

Waldo wrote:

Als je maar 4 schijven in je server hebt, en je het die geconfigureerd in RAID1+0, dan kan je maar 1 logische schijf hebben, die je waarschijnlijk verdeeld hebt in meerdere partities. Voor 2 databasefiles kan je discussiëren wat nu eigenlijk het snelste is, wat we nu niet gaan doen.

Met 140 gig (??) zijn 2 database files in principe veel te weinig (vroeger werd er aangeraden om maximum 2Gb per databasefile te hebben - nu is dat natuurlijk anders).
Theoretisch zou je moeten overgaan naar de 16 files ... en als het budget er is, deze 16 files op logisch en fysiek verschillende schijven zetten. Dit kan RAID1: dan heb je 32 schijven nodig (is inderdaad redelijk moeilijk), of in RAID1+0: dan zou je er 64 nodig hebben (is inderdaad redelijk onmogelijk).
Bottom line: Zoveel mogelijk database files verdelen over zoveel mogelijk logische schijven (geen partities). En één logische schijf is 1 set in een raidconfig.

Ik ben me ervan bewust dat het praktisch moeilijk haalbaar is, daarom is het misschien ook aan te raden om over te stappen naar SQL Server, die beter kan omgaan met grote databases en veel concurrent gebruikers. Opgelet: indien deze weg wordt opgegaan, is er zeker nog heel wat SQL tuning nodig!

Dit voor de algemene performantie te verbeteren. Maar het verklaart niet dat het boeken zo traag is en al de rest redelijk snel is. Ook al is het schrijven naar disk traag, met een Navision DB MET COMMITCACHE is dat niet echt een probleem. Alles wordt in het geheugen bijgehouden tot de server tijd heeft om het weg te schrijven.
Ik zou dus zeker eerst kijken naar het gebruik van de juiste indexen tijdens het boeken.

Waldo wrote:

Opgelet: indien deze weg wordt opgegaan, is er zeker nog heel wat SQL tuning nodig!

Specialiteit van Mark!

Didden

Gisteren een Introductie sessie Performance training gehad van Mark Brummel.

Heel interessant, kan hier nog wat dingen aanpassen, maar ga Mark zeker uitnodigen via onze NSP om hier een performance check te komen doen.

Bedankt voor de hulp.

Marije_Brummel

Bedankt voor de reactie. O:)

Het was ook voor mij een interessante dag.

Ik zie de uitnodiging wel tegemoet.

Voor eventuele geinteresseerden, de sessie over performance wordt vanwege grote aanvraag een aantal keren herhaald. Neem voor meer informatie contact op met het secretariaat van de Navision gebruikersvereniging.

www.gvnavision.nl

jbeemster

Mark,

Ik ben op zoek naar deze tool: " 'advanced' client monitor."
Je schrijft "Deze kun je vinden op de tools cd. / form 105020 "
Ik heb wat performance problemen op een native database.

Is deze ook te downloaden ergens?

Jeroen Beemster

tinoruijs

Download the Tools CD from partnersource: https://mbs.microsoft.com/partnersource ... page=false

It contains a "Client Monitor.fob" which shows more information than the standard Client Monitor.

Marije_Brummel

Ha Jeroen.

Alleen voor partners.

Als je de client monitor in je licentie hebt kun je de tool omnummeren naar een klantlicentie.

Stuur anders maar even een mailtje dan lossen we het samen op.

Waldo

Ik weet niet hoe up-to-date de tool is, maar deze zal vermoedelijk wel werken:
http://www.mibuso.com/dlinfo.asp?FileID=561.

Je kan 'm uiteraard ook van de partnersource halen:
https://mbs.microsoft.com/partnersource/downloads/supplements/databaseresourcekit.htm?printpage=false

Waldo

Iedereen tegelijk bezig

Marije_Brummel

En dat terwijl er Mark stond en ik Jeroen ken.

Anyway... goed bezig...

Waldo

Daar kijk ik niet naar - dit is een forum .

jbeemster

Thanks to all. this is what I need. (and more, so I've got Homework)

garak

der advanced clientmonitor sollte auch mit der nativen Datenbank arbeiten.

garak

oh, forgotton to write in dutch #-o