Performance-Troubleshooting von Microsoft SQL Server (2)

Haben Sie das Gefühl, das Netzwerk könnte für die schlechte Performance verantwortlich sein, schauen Sie sich zunächst die Erfolgsrate der Netzübertragung an, allen voran die "TCP Retransmits". Diese können Sie mit PerfMon verfolgen oder den aktuellen Stand schnell mit dem Befehl »netstat -s« ausgeben lassen, in Bild 1 beispielsweise für TCPv4 zu sehen.

Lassen Sie sich Ihre in Windows gemessenen Zahlen auch von Ihren Netzwerkern am Switch-Port bestätigen. Liegt der Wert zu hoch, müssen Sie die zuständigen Netzwerkkomponenten – sowohl am SQL-Server als auch bei dessen Kommunikationspartnern und in der gesamten Signalkette dazwischen – überprüfen und entstören lassen. Sind die Retransmits in Ordnung, nehmen Sie zu einer Zeit, in der der SQL-Traffic nicht allzu hoch ist, eine Performance-Messung etwa mit iPerf [1] vor.

Eventuell zieht ein falsch konfigurierter Switch die Performance herunter? Oder ein Router zwischen dem Client- und dem Servernetz arbeitet nur mit 100 MBit/s? Im Kontext der SQL-Performance ist für Sie besonders wichtig, dass der Server die Daten, die er an die Clients schicken möchte, auch schnell genug über das Netzwerk übertragen bekommt. Schafft er es nicht, so ist eine Mehrbelastung von CPU und RAM programmiert.

Unwahrscheinlicher Flaschenhals CPU

Im Regelfall ist es eher schwierig, einen CPU-Flaschenhals im SQL-Server zu verursachen, sofern dieser ordentlich dimensioniert ist. Von den SQL-eigenen Funktionen hat allenfalls ein Vollbackup einer großen Datenbank das Potential hierzu, wenn die Komprimierung aktiv ist. Den Flaschenhals erkennen Sie daran, dass der PerfMon-Indikator "System / Prozessor-Warteschlangenlänge" über lange Strecken den Schwellenwert von 1 überschreitet.

Behalten Sie unbedingt auch Ihr Antivirus-Programm im Auge. Fehlen wichtige Ausschlüsse oder ist das Scannen von

Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.