SQL Server 2005 / Win2k3R2 Hauptspeichernutzung

[phoenixcp 10]

Hallo Freunde

 

Ich habe ein "Problem" mit der Hauptspeichernutzung meines SQL Servers.

 

Erstmal ein paar Randdaten:

- Windows Server 2003 R2 Standard Edition SP2

- 4 GB RAM

- Boot.ini /3GB /PAE

 

- SQL Server 2005 Enterprise Edition 9.0.3215 (SP 2 + Cumulativer Fix KB943656 SRP5)

 

Der SQL Server ist folgendermaßen konfiguriert (was die Memoryoptionen betrifft):

Use AWE to allocate memory = ON

Minimum server memory 1024 MB

Maximum server memory 3072 MB

Index creation memory 0 (dynamic memory)

minimum memory per query 1024 kB

 

Auf diesem Server läuft eine DB (aktuelle Größe 3,7 GB) im Simple Recovery Mode.

 

Jetzt zu meinem eigentlichen Problem:

Egal wieviel Last ich auf der DB erzeuge (Datenimporte, massive Statements über hundertausende Datensätze, etc.), die SQL Server Instanz holt sich nie mehr als ca. 100 MB physikalischen Speicher ab. Per ProcessExplorer kann ich nachvollziehen, das er neben den ca. 100 MB physikalischem Speicher ca. 3,8 GB virtuellen Speicher (Pagefile) belegt.

Damit ist natürlich die Performance ein wenig bescheiden.

 

Das ganze läuft auf einem ML 350.

 

Die selbe Softwarekonfiguration, die selbe Datenbank auf einem DC 7600 mit ebenfalls 4 GB RAM in meinem TEC zieht sich die SQL Server Instanz knapp 2,8 GB physikalischen Speicher. Und das schon ohne das ich Last erzeugen muss.

 

Hat irgendwer einen Ansatz der Erklärung für dieses Phänomen? Welche Schrauben könnte ich möglicherweise noch drehen, damit sich der SQL Server mehr physikalischen Speicher reinzieht und damit auch in der Performance noch zulegt?

 

Optionen wie Neuinstallation des Servers mit einer W2k3R2SP2-EE und mehr RAM fallen aktuell leider aus. Die TEC-Installation beweist ja quasi das es eigentlich gehen müsste, so auch meine Erfahrungen aus diversen SQL Server 2005 Umgebungen.

[zahni 521]

Hi,

 

sahclte mal zum Test die AWE-Option ab. Die ist bei 4GB RAM eh sinnlos und drückt die Performance.

 

-Zahni

[phoenixcp 10]

Sieht gut aus. Danke für den Hinweis. Mittlerweile zieht er sich mehr Speicher ran. Muss mir wohl die TEC nochmal intensiver anschauen, die verhält sich nämlich trotz AWE-Schalter anders... Aber nu ist erstmal Wochenende.

[Squire 212]

Hi,

 

also .. selbiges Phänomen hab ich auch auf unseren SQL ... allerdings 18GB RAM. AWE gesetzt - auf 16GB - der SQL zieht sich minimal Speicher allerdings Paging wird 16GB zugesichert.

 

Jedoch ... die Kiste ist performant wie noch nie. Navision DB mit 40GB. Funktionen die vorher fast 10min brauchten laufen nun in Sekunden.

 

SQL 2005 allerdings mit SPR7 (wenn ich das richtig im Kopf hab - musste bei MS angefordert werden - gibt es nicht zum freien Download)

[zahni 521]

Dieses Verhalten ist bei AWE-Speicher normal, da Windows den Speicher nur über einen Hardware-Trick adressieren. Windows selbst sieht AWE-Speicher sozusagen als RAM-Pagefile.sys und blendet Speicherfenster innerhalb des User Adressbereiches ein. Das müssen Anwendungen unterstützen. Generell ist das aber deutlich weniger performant als 64-Bit Adressierung. Da muss die Anwendung über solche Dinge keine Gedanken machen. IBM DB2 hat übrigens in der Version 9 oder 9.5 den AWE-Support entsorgt und empfiehlt den Einsatz der 64-Bit Version.

 

-Zahni

[Squire 212]

klar macht 64it mehr Sinn, aber - nicht jede Software ist eben 64bit fähig/kompatibel. Auf unserem läuft noch 3rd party Software (diverse Importer) und die sind eben nicht 64bit fähig ...

[gysinma1 13]

Hallo Zusammen

 

wir hatten dieses Phänomen auch aber bei mehreren DBs mit 200 GB im Fullmode mit 32 Kernservern. Mit dem (AEW Switch) "verschwinden" sowohl im x32 wie x64 OS die Memoryallocation aus dem SQL Prozess. Allgemein empfiehlt MS nicht den AEW Mode auf X64 zu aktivieren (bei 32 bit nur bei speziellen Situationen). Eventuell sinnvoll ist pro Kern eine Tempfile Datei zu pflegen, da dieses exklusiv genutzt wird d.h. die tempdb sollte bei 8 Kernen aus 8 Dateien bestehen. Oft wird auch diskutiert, die SQL Affinität der CPU0 aufzuheben und dies für das OS zu belassen v.a. bei Highpeformance Applikationen da diese v.a. bei Clustern bei längernen 100%Linien sonst Clusterswitche auslösen.

 

Natürlich ist/war unsere Umgebung ein bisschen extremer ... aber mit vielen kleinen Details lässt sich oft noch etwas rausholen.

 

Gruss

Matthias

[phoenixcp 10]

Eventuell sinnvoll ist pro Kern eine Tempfile Datei zu pflegen, da dieses exklusiv genutzt wird d.h. die tempdb sollte bei 8 Kernen aus 8 Dateien bestehen.

 

Du hast da nicht grade nen Link bei der Hand dafür?

 

Oft wird auch diskutiert, die SQL Affinität der CPU0 aufzuheben und dies für das OS zu belassen

Kann ich aus Erfahrung nur empfehlen. Ausser es handelt sich um HT-Prozessoren. Dort musste ich feststellen das bei heftigen Transaktionen die ganze Kiste massiv langsam wurde. Nachdem wir dann HT deaktiviert haben und die Affinität sauber verteilt haben (CPU0 ==> System, alle anderen SQL), rannte das Ding wie Rudi, das Rennschwein...