SQL Server: Server Einstellungen

Performance by Settings? Das ist auf jeden Fall zu unterstreichen..sofern die Einstellungen nicht ok waren ;-). Die Grundeinstellungen des SQL Servers sind meist nahe am Optimum. Was ist aber optimal? Interessantes zu Servereinstellungen…

In der Praxis kam es mir bereits des öfteren unter die Finger, dass die SQL Server Einstellungen nach dem Prinzip "Mehr ist besser als weniger" gemacht wurden. Aber um das Fazit bereits vorweg zu nehmen: Standardeinstellung sind oft besser als manuelle konfigurierte Werte. Aber nun mal schön der Reihe nach.

Affinität

Wollen wir mal die Affinität unter die Lupe nehmen. Affinität (lateinisch affinitas: „Schwägerschaft“) legt die "Enge" der Bindung an bspw. CPU fest. Wenn man in einer Mehrprozessormaschine eine Affinitätsmaske angibt, wird dadurch der SQL Server angewiesen eine Aktion strenger an eine CPU zu binden. Die Standardeinstellungen des SQL Server bevorzugen keine "strenge" Affinität, wodurch ein Thread durchaus mal auf CPU 1 oder auch mal auf CPU x landen bzw. migrieren kann. Abhängig davon, ob die bevorzugte CPU salopp gesagt, gerade mal Zeit und Platz hat. Bei einer Wanderung von CPU zu CPU müsste der Prozessorcache logischerweise immer wieder neu geladen werden. Deswegen käme eine Optimierung also nur dann in Frage, sofern andere Prozesse ebenfalls konkurrierend die CPU beanspruchen würden und dadurch das Migrieren erzwungen wird. In der Regel läßt man die Einstellungen unverändert, da der SQL Server mit normaler Priorität läuft und daher der Windows´-Thread-Scheduler versucht dynamisch allen Threads gleiche gute CPU Qualität zu gewährleisten.

Unter SQL 2005 gesellt sich nicht die E/A Affinität dazu, die zuständig ist für die Verteilung von Lese- und Schreibvorgängen. Die Affinität sollte in diesem Fall (SQL 2005) nicht auf die gleichen CPUs verteilt werden.

Tipp: Achten Sie bei Änderungen, dass Windows 2000 Netzwerkkarten den CPUs mit der höchsten Nummer zuweist. Sprich einer 4 Prozessoren Maschine mit 2 Netzwerkkarten, werden die NICs der CPU 3 und CPU 4 zugewiesen.

SQL Server 2005 Affinität

Lightweight Pooling

Diese Threads werden normalerweise pro Sitzung ergo SPID vergeben. Nun kann man sich vorstellen, dass nicht unendlich viele Threads erzeugt werden können, da auch diese verwaltet werden wollen. Daher werden die Threads in einer Poolkonfiguration verwaltet, um letztendlich mehrere Threads durch die erweiterte Poolkonfiguration zu einem Thread zusammenfassen zu können. Dieses Zusammenfassen wird auch als Lightweight Pooling bezeichnet und findet sich unter der Bezeichnung NT Fibers im SQL wieder. Was um Himmels Willen sind nun NT Fibers. Nun… Threads werden im Gegensatz zu den Applikationen nicht im Benutzermodus, sondern im Kernelmodus verwaltet. Wechsel zwischen diesen beiden Modi beanspruchen rel. hohe Ressourcen. Daher stellt man eine Möglichkeit zur Verfügung sogenannte Fibers zu erzeugen (als Unterkomponente eines Threads), die wiederum nur im Benutzermodus liegen. Der Wechsel findet nur noch innerhalb dieser Fibers statt. Insofern sind hier Wechsel nur noch mit wenig Last verbunden. Lediglich in Systemen mit mehr als 4 CPUs und einer sehr hohen Auslastung, kann die Aktivierung von NT Fibers von Nutzen sein. Ein guter Ausgangswert, um NT Fibers zu aktivieren sind mehr als 20000 "Kontextwechsel/sec" (zu finden im Systemmonitor).

Übrigens Threads und Fibers, die im Pool zusammengefasst werden, sind die sogenannten Max worker Threads. Die angegebene Anzahl von 255 muss eigtl nicht korrigiert werden. Auch bei hoher Last erweist sich dieser Wert als sehr performant. Letztendlich würde ein Erhöhung eine zusätzliche Verwaltung der Threads erzeugen und somit Ressource rauben. Neue Threads werden dem nächst freien Worker Thread zugewiesen. Sofern keiner frei ist, wird auf den nächst freien gewartet. Dieses wird mit Meldung
The working thread limit of 255 has been reached quittiert.

Prioritäten

Eine weitere Alternative stellt die Prozessorpriorität dar. Sie können durch ein Höherstufen die Prozessorpriorität von Normal (7) auf Hoch (13) einstufen. Sofern keine weiteren Anwendungen auf dem Server betrieben werde, eine rel. gute Maßnahme.

Speichermaßnahmen

Eine weiter Maßnahme, die zunächst unverändert bleiben sollte, stellt die Größe des Abfragespeichers dar. Standardmäßig weist der SQL Server pro Benutzer 1024 kb zu. Die Größen können jedoch zwischen 512 kb und 2 GB eingestellt werden, da die Größenangaben als Mindestgrößen interpretiert werden. Dieser Wert ist abhängig von der Gesamtgröße des freien Speichers, der durchschnittl. Anzahl der Abfragen und deren durchschnittliche Größe, sowie der gewünschten Abfragezeit.Als Daumen mal pi, wird ganz gern folgender Ansatz vorgeschlagen:

Freier Speicher / (Durchschn. Abfragegröße * Anzahl gleichz. Abfragen)

Dem Thema AWE möchte ich einen eigenen Artikel widmen. Nur soviel dazu: AWE wird ab einer Speichergröße über 3 GB RAM interessant. Hierzu sind einige weitreichende Einstellungen vorzunehmen. Unter anderem in der boot.ini.

Speicher SQL 2005

Parallelität

Für die Entscheidung über parallele Verarbeitung sind für den SQL Server folgende Fälle entscheidend:

– stehen mehr Prozessoren als aktive Verbindungen zur Verfügung und
– sind die geschätzten Kosten für die serielle Ausführung über dem Abfrageplanschwellwert.

Der Standardwert von 0 beim Max. Grad an Parallelität gibt an, dass die max. Anzahl der CPUs für die parallele Verarbeitung automatisch eingeteilt wird. Die Parallele Verarbeitung kann im SQL Server durch die Angabe eines Wertes, der die max. Anzahl der CPUs wiedergibt, reguliert werden.

Der Vorteil der Parallelität liegt in der Erledigung aufwendiger Aufgaben. Sind die Sekunden für die Ausführung über den eingestellten Kostenschwellenwert für Parallelität, so wird erst ab diesem Moment die Aufgabe auf mehrere CPus verteilt.

Parallelität SQL Server 2005

Fazit

Die Standardeinstellungen sind in vielen Fällen bereits optimal. Nur wer sein System genau kennt und weiß welche Auswirkungen die jeweiligen Einstellungen nach sich ziehen. Viele der besprochenen Einstellungen betreffen Mehrprozessoren Maschinen. Aber keine Bange…es folgen auch noch Beiträge zu SQL Server, die durchaus auf "normalen" Server nachzuvollziehen sind. 😉

Author: Fumus

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert