Sql performance met axapta

[Verwijderd]

Wij hebben een probleem met onze performance met sql server 2000

We beschikken over een server met 2 fysieke proccors (dual core) dus er worden 4 processors gezien. Sql is zo geconfigureerd om te werken met 3 van de 4 "processors"
nu doet het fenomeen zich voor dat alle queries etc allemaal worden op uitgevoerd op 1 processor. Dit is een wllekeurige processor dit wisselt continu. (over alle 4 de processors)
Als er een zware querie wordt uitgevoerd loopt de cpu use op naar 25% (1 processor 100 % dus)
De hele sql omgeving is dan traag. En eigenlijk niet meer werkbaar
ALs die opdracht komt is er geen schiijfactiviteit (thans, niet veel) en er zijn ook niet veel memory pages ingbruik

Opzich zou dit niet echt een probleem zijn laat het nou zijn dat die querie soms 10 minuten of meer duurt. dit komt omdat de gehele database z'n 70 gb groot is.
Ik zou graag willen en volgens mij moet het ook zo zijn dat alle aangegeven processors worden gebruikt voor deze opdracht.

Mijn vraag is heeft iemand het eerder meegemaakt? En weet iemand toevallig hier een oplossing voor?
Overigens is er wel een licentie voor de processors.

[Abom]

Vreemd. Wanneer het om een enkele query zou gaan, dan is het wel begrijpbaar. Dat SQL-server multi-threaded is, wil nog niet zeggen dat elke query ook in meerdere threads gesplitst kan worden.

Aangezien je gehele systeem traag wordt en de rest van je resources normaal zijn, vind ik het heel vreemd. Wat is de indeling van je schijven, hoeveel schijven, watvoor type raid etc?

Om eerlijk te zijn, denk ik toch dat je naar je schijven (indeling) moet kijken voor de bottleneck.

[ Voor 12% gewijzigd door Abom op 21-04-2006 11:18 ]

[Verwijderd]

Het is een snelle raid 5. Zoals ik aangaf, op de schijven is geen activiteit af te lezen in logging, Ook vind er geen locking van tabellen plaats terwijl hij het normaal gesproken wel doet maar op momenten dat het traag is niet.

Het is echt dat de cpu naar max gaat. Er zijn geen transacties gaande etc het is puur de processor die naar 100% schiet (de ene processor)
Ook als de Aos (object server) gestopt wordt blijft de sql server nog z'n 5 minuten druk.

Edit: normal gezien als de schijven de bottleneck zijn dan is de cpu minder dan 100% belst toch? dan schommelt het wat en zie je veel memory pages etc Dat is hier dus echt niet het geval.

[ Voor 18% gewijzigd door Verwijderd op 21-04-2006 11:21 ]

[Abom]

Wanneer je ervan overtuigd bent dat het de CPU is, zou ik uit gaan zoeken wat nog meer op die ene processor toe kan grijpen. Misschien is er wel een andere crusiaal process wat niet multi-threaded is en de affinity op dezelfde core heeft staan als SQL-server.

Moeilijk iets om te troubleshooten... het kan ook nog altijd de query zijn, die inefficient is.

[Verwijderd]

als ik naar de processes list ga, dan zie ik sqlsrv 24-26% pakken van de cpu use (dus 100% op een van de cpu's naar keuze)

Die querie analyzer ga ik zeker even gebruiken dat is ook het plan. Het is mij inderdaad bekend dat dit een combinatie van 2 dingen is.
1. Querie is niet helemaal lekker
2. Multi threathing werkt niet naar behoren.

Ik wil graag weten waarom probleem 2 zich voordoet en niet normaal functioneerd Bij andere klanten van ons werkt deze config wel normaal. Dit is overigens ook zo als er geen performance problemen zijn Dan zie ik ook continu pieken op een van de processors. Deze wisselen elkaar om de minuut af ongeveer.

[Abom]

Wij hebben ook een dual-CPU dual-core als SQL-Server (2k). 8/10 queries trekken max 25% (1 core) aan rekenkracht, dus het is vrij normaal. Wat niet normaal is, is dat de machine dan niet meer reageerd en voor de rest van de gebruikers traag wordt.

Spikes zie ik verder bijna nooit, vreemd probleem.

[ Voor 12% gewijzigd door Abom op 21-04-2006 11:55 ]

[Verwijderd]

Inmiddels het probleem gevonden. Het is een combinatie van dingen

1 query doet een table scan, deze levert locks op (Deathlocks)
2 de query komt alleen over 1 processor deze is dus 100% door de table scan
Door de locks kunnen dus de andere gebruikers niet verder en blijven de rest van de cpu's op 0% staan.

Schijf activiteit was niet te zien omdat alles in de memory cache stond. Daardwoor was het ook moeilijk om lock wait time te zien. en lock request p/s te zien

Nou hopelijk heeft de volgende hier ook nog wat aan