.Net Anwendung nutz nur eine logische CPU pro Querry?

[substyle 20]

Hallo zusammen,

 

ich habe eine .net Anwendung die mit einem SQL 2000 SP4 zusammen arbeiten soll. Die Maschiene hat 2 Xeons 3,0 GHZ, die mit HT laufen. 2GB RAM sind verbaut. Der SQLService nimmt sich davon ca. 1,7GB.

 

Die Anwenung ist closed Source und setzt sehr stark auf Stored Procedures am Server.

 

Wenn die Anwedung gestartet wird, hakt sie oft. Es hat sich gezeigt. das die Auslastung am Server ist aber recht gering. Die I/Os auf dem Raidcontroller sind fast nicht zu messen, nur die CPU last hängt auf einer logischen CPU bei 25%. Der SQL Prozess nutz in diesem Fall nie mehr als 25% der CPU.

 

Wenn ich einen Stresstest auf einer Datenbank ausführe schaffe ich es allerdings locker 80% auf allen vier Kernen, also deutlich mehr als 25% Auslastung.

 

Meine Frage ist nun, wie kann ich sozusagen "Reverse Engineering" betreiben? Am liebsten würde ich gerne "sehen" welche Abfrage gerade läuft und wie sich das auf die CPU Last auswirkt.

 

Ich fürchte einfach das die Anwendung schlecht oder schlapig geschrieben ist :(

 

Vielleicht kann mir jemand helfen?

 

subby

[koenig_knuddel 10]

Upgrade-Prüfungen sind nur für Feiglinge !

MCSE 2K3 Pass: 70-270 70-290 70-291 next 70-292

OT: Äh, wie jetzt? Feigling oder nicht? Ist die 70-292 nicht retired?

[LukasB 10]

Redest du jetzt vom App-Server oder vom SQL-Server?

 

Der SQL-Server kann zum einen natürlich mehrere Queries parallel ausführen (was wohl beim Stress-Testing passiert), aber natürlich auch Queries selber parallel verarbeiten (dies geht jedoch nicht immer).

 

Parallel Query Processing

 

Ich kenne mich mit dem SQL Server 2000 leider nicht wirklich aus (Arbeite erst seit Version 2005 intensiv damit) - aber auch SQL Server 2000 scheint schon Tracing Features gehabt zu haben:

 

Microsoft Security: SQL Server 2000 Auditing

 

Am besten kann und sollte dir eigentlich der Hersteller der Applikation helfen können.

[substyle 20]

@koenig_knuddel ...

 

Naja, ein Update täte es mal für die Signatur, danke für die Erinnerung :)

 

@LukasB

 

Ich rede von der Auslastung am SQL Server. Die Anwendung läuft auf Windows XP :) An den Hersteller habe ich mich bereits gewand, leider mit mäßigem Erfolg. Was mich eben wundert ist die Tatsache das bei "vier Kernen" der Query genau 25% CPU Last erzeugt. Das hat für mich eine gespenstische "parallelität" - oder eben gerade keine - LOL.

 

Daher würde ich gerne mal forschen gehen, welche Transaktionen zwischen Anwendung und SQL Server laufen wenn das besagte phenomen eintritt.

 

Überigens treiben mehrere Aufrufe (selbe Aktion) die zeitgleich von mehreren Clients aus aufgerufen werden die Last auch nicht höher. :(

 

subby

[LukasB 10]

Ich rede von der Auslastung am SQL Server. Die Anwendung läuft auf Windows XP :) An den Hersteller habe ich mich bereits gewand, leider mit mäßigem Erfolg. Was mich eben wundert ist die Tatsache das bei "vier Kernen" der Query genau 25% CPU Last erzeugt. Das hat für mich eine gespenstische "parallelität" - oder eben gerade keine - LOL.

 

Nicht alle Queries können parallel verarbeitet werden - je nachdem was genau gemacht wird kann es sein dass sämtliche Queries die verwendet werden nicht parallelisierbar sind.

 

Daher würde ich gerne mal forschen gehen, welche Transaktionen zwischen Anwendung und SQL Server laufen wenn das besagte phenomen eintritt.

 

Dafür hilft dir wie gesagt das Tracing.

 

Überigens treiben mehrere Aufrufe (selbe Aktion) die zeitgleich von mehreren Clients aus aufgerufen werden die Last auch nicht höher. :(

 

Das kann natürlich mehrere Ursachen haben - evtl. serialisiert die Anwendung automatisch sämtliche Abfragen, egal von welchem Client die kommen (über Locks). Das wäre natürlich Gift für die Performance...

[koenig_knuddel 10]

kann es sein dass sämtliche Queries die verwendet werden nicht parallelisierbar sind.

Ungefähr dann, wenn sämtliche "Queries" Schreibzugriffe sind, lesezugriffe sind leicht bis sehr leicht skalierbar. oft sollen 3/4 aller Zugriffe Lesezugriffe sein, oft sogar noch mehr, heißt es im Grundstudium der Informatik anne Unni.

[phoenixcp 10]

Wie von den beiden anderen schon angemerkt: Nicht alle Queries sind parallelisierbar. Also sollten wir erstmal herausfinden, was für Queries so gegen deine Datenbank laufen. Dazu kannst du den Profiler nutzen, welcher auf dem SQL Server bzw. einem Client mit installierten SQL-Server Client Tools vorhanden ist.

 

Hier ein wenig Informationen dazu: Verwenden von SQL Server Profiler

 

In den Protokollen des Profilers siehst du dann, welche Statements gegen die Datenbank gehen.

 

Weiterhin solltest du dir mal die Konfiguration des SQL Servers ansich anschauen.

Wie ist der konfiguriert? Bei einem Multiprozessorsystem wird immer empfohlen (und das habe ich aus guter Erfahrung bisher immer auch so gemacht):

- CPU 0 für OS vorhalten, alle anderen CPU's dem SQL-Server zuweisen

- sollten die CPU's Hyperthreading beherrschen (HT), lohnt sich immer mal wieder der Test, ob der SQL-Server mit abgeschaltetem HT schneller ist, als mit aktiviertem HT (hängt auch ein wenig von der DB und den Aktionen auf der DB ab)

 

Bei weiteren Fragen, einfach melden.