dynamische speicherverwaltung funktioniert nicht?!

[jl77]

Hallo zusammen,

aaaalso:

SQL Server 2005 (Enterprise/SP2) auf Win2003 Server.

Mir ist bekannt, dass man die Speichernutzung des SQL Servers sowohl dynamisch belassen, als auch manuell festlegen kann.

Ich habe hier 2 Server stehen:
a) 1 Produktivsystem wie oben beschrieben - Hier ist die Speicherverwaltung in den Standardeinstellungen, d.h. keine Ober- und Untergrenze für Speichernutzung.
Das funktioniert einwandfrei.. Bei Serverlast schraubt sich der Speicher hoch und anschliessend wieder herunter...prima.

b) Einen Cluster-Knoten (2node, active-active)
Installation ebenfalls wie oben beschrieben, nur als Cluster Instnz (named) installiert.

Wenn ich die Standardeinstellungen belasse, schraubt sich der Speicher immer weiter hoch und bleibt dort bestehen.
Die Frage ist nun, warum wird der Speicher nicht wieder freigegeben???

Ich habe jetzt nach oben hin auf 8000 MB begrenzt.
Diese Grenze funktioniert zwar, jedoch "hängt" der relationale Prozess eben permanent auf diesem Oberwert - selbst wenn der Server schläft...

Was könnte denn dazu führen, dass die dynamische Verwaltung nicht funktioniert?

Vielen Dank im Voraus für eure Anregungen!!!

Jörg

[O. Helper]

Speicher hoch und anschliessend wieder herunter...prima

Eher das Verhalten ist ungewöhnlich.

Also unsere div. SQL Server nehmen sich soviel Speicher, wie sie bekommen können und geben den freiwillig auch nicht wieder her.
Warum auch, das kostet nur unnötig, Speicher zu allocieren, ihn wieder frei zu geben, nur um in 2 Minuten später wieder zu allocieren.

nach oben hin auf 8000 MB begrenzt

Ist es eine 64 Bit Maschine? Andernfalls reichen 3,5 GB, mehr kann er eh unter 32 Bit nicht verwalten.

[Bernhard Geyer]

Starte den Server neu und stelle eine Abfrage auf eine größere Tabelle. Der erste Zugriff bis zum cachen der verwendeten Indize wird länger dauern als die späteren Abfragen. Wilslt du trotz vorhandem freien RAM diesen Performanceverlust haben?

Sollte ein anderer Prozess Speicher benötigen sorgt Windows schon dafür das er diesen als RAM bekommt indem Speicher des SQL-Servers ausgelagert wird. Dein Aufgabe ist die beste Verteilung heraus zu bekommen.

[O. Helper]

Starte den Server neu

Her je, wie brutal.
Das geht auch anderes, um es mal zu testen:
[HIGHLIGHT=SQL]DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS[/HIGHLIGHT]
Empfiehlt sich bei jedem Performance-Test.

Der verwendete Speicher wird dadurch aber nicht freigegeben.

[Bernhard Geyer]

@Olaf:

Danke für den Hinweis/Tipp. Hoffentlich vergess ichs nicht beim nächsten Test.

[jl77]

hi zusammen,

also danke erstmal für eure antworten...und gleich zu anfang: yep: ist ne x64 maschine. hatte ich vergessen, sorry.

die instanz wird als datawarehouse genutzt...daher interessiert mich die performance des relationalen prozesses eigentlich nur 1x täglich beim import der daten.
eher sekundär...also. die relationalen DBs werden ansonsten nicht wirklich beansprucht.

mir ist wichtiger, dass der OLAP prozess ausreichend speicher erhält, wenn unsere benutzer dem cube fragen stellen

@o.helper
du hast geschrieben, dass eher das verhalten unseres produktivsystems ungewöhnlich ist. leuchtet mir nach euren antworten prinzipiell ein, jedoch kenne ich es garnicht anders. nagut, ich bin auch erst ein halbes jahr dabei.
(vllt. kommt das daher, dass diese installation auf vmware ist?)

------

dann gehen wir mal von folgender hypothetischen situation aus:
ich stelle die schwellenwerte für speichernutzung wieder auf standard und lasse den server "einfach mal machen".
spätestens nach 2 oder 3 import-routinen befindet sich der rel. prozess im ca. 20 GB bereich.
laut windows taskmanager sind dann nur noch einige hundert MB speicher verfügbar.

--> WENN anschl. der OLAP prozess (msmdsrv.exe) gefordert wird, weil die anwender sich auf den cube stürzen.... wird DANN der, zwar allokierte aber nicht genutze speicher vom SQL Server wieder freigegeben?

------

frage nr. 2:
eine einschränkung nach oben erschien mir u.a. deshalb sinnvoll weil es bei dem 2-node cluster vorkommen kann, dass sie die MS Dynamics umgebung des anderen knoten (STANDARD Edition) hinzuschaltet. die soll natürlich auch ein bisschen was von dem speicherkuchen abbekommen.

gibt's da best practice tips?

[O. Helper]

diese installation auf vmware ist

Ihr virtualisiert SQL Server? Klar, kann man machen, schneller wird das System dadurch aber nicht (aus dem Grund ist auch noch kein Gamer auf die Idee gekommen )

wird DANN der, zwar allokierte aber nicht genutze speicher vom SQL Server wieder freigegeben?

Ja, das geschieht dann.
Ich habe teils 2 benannte SQL-Instanzen auf einem Rechner und die teilen sich den Speicher; mal nutzt der ein mal der andere mehr.
Also, er gibt es nicht freiwillig, aber gezwungener Maßen schon Speicher wieder frei.

gibt's da best practice tips?

Nicht so ganz wirklich; wie Bernhard schon schrieb, muss man da etwas experimentieren, um auf die optimale Einstellung zu kommen.

[jl77]

Ihr virtualisiert SQL Server?

jaaa, ich weiss auf mich wollte ja keiner hören
nein, wir hatten wegen massiver probleme auf dem ursprünglichen system (x86) die anforderung, schnellstmöglich auf ein x64 system zu schwenken...da blieb nur virtualisieren.

ok, folks.. danke für die antworten.
ich denke, ich werde nun erstmal OHNE die manuelle einschränkung testen und dann sehen, wie es sich verhält.

schade eigentlich - ich steh so auf "best practice" )

thnxx!!!

[dimitri]

Empfiehlt sich bei jedem Performance-Test.

Weswegen sollte es nützlich sein bei einem Performancetest den Cache zu leeren??

Dim

[O. Helper]

Hallo Dimitri,

ganz einfach:
Wenn ich SQL Statements optimiere (was bei unseren Entwicklern meisst dringend nötig ist), dann möchte ich dabei natürlich reproduzierbare Ergebnisse bekommen.
Das bekomme ich aber nicht, wenn er beim erstenmal die Daten aufwendig zusammenkramen muss und beim zweiten mal sich easy aus dem Cache bedienen kann.
Zugegeben, 100% repro ist es nie, da immern noch der Cache vom SAN und vom System hinzukommt.

Und nur den Ausführsplan zu analysieren reicht mir nicht, da sind mir auch die effektiven Laufzeit wichtig.

P.S.: Unser Ora-DBA macht es auch so

[dimitri]

(was bei unseren Entwicklern meisst dringend nötig ist)

Ja das kommt raus wenn man den DBA ran lässt

Aber wieder im Ernst: Es ist leider ein Kardinalfehler der oft gemacht wird, den Cache leer zu machen um reprodozierbare Ergebnisse zu bekommen. Umgekehrt macht man aber auch keinen Motortest an einem Auto wenn der Motor kalt ist.

Vergleichen lassen sich SQLs anhand von rein physikalische Blockzugriffen relativ schlecht, besser geht das anhand von allen Blockzugriffen (oder consistent gets wie es z.B. in oracle heißt)=physikalischer Blockzugriff + Blockzugriff aus dem Cache.

Typisches Beispiel wäre z.B. der Vergleich eines Full Table Scan mit einem Indexzugriffs auf einen großen Teil der Daten einer großen Tabelle.

Der FTS würde viel mehr Plattenzugriffe bewirken, während der Indexzugriff wohl weniger auf der Platte lesen muss aber dafür deutlich mehr Zugriffe im Cache hat. Ab einem bestimmten bestimmten Prozentsatz der selektierten Daten wird der FTS dann deutlich performanter obwohl er viel mehr Plattenzugriffe hat.

Des weiteren bekommt man mit dieser Messmethode den Zeitfaktor weg, denn wenn anhand der Zeit verglichen werden soll, welches SQL performanter ist, dann muss man ja immer auch schauen, was grade sonst noch so auf der Maschine läuft etc.

Dim