E / A-Anforderungen, die länger als 15 Sekunden dauern

Normalerweise sind unsere wöchentlichen vollständigen Backups in ca. 35 Minuten abgeschlossen, während die täglichen diff-Backups in ca. 5 Minuten abgeschlossen sind. Seit Dienstag haben die Tageszeitungen fast 4 Stunden in Anspruch genommen, weit mehr als nötig. Zufälligerweise passierte dies direkt nachdem wir eine neue SAN / Disk-Konfiguration bekommen hatten.

Beachten Sie, dass der Server in der Produktion ausgeführt wird und keine allgemeinen Probleme vorliegen. Er funktioniert reibungslos - mit Ausnahme des E / A-Problems, das sich hauptsächlich in der Sicherungsleistung manifestiert.

Wenn Sie dm_exec_requests während der Sicherung betrachten, wartet die Sicherung ständig auf ASYNC_IO_COMPLETION. Aha, wir haben also einen Plattenkonflikt!

Weder die MDF (Protokolle werden auf der lokalen Festplatte gespeichert) noch das Sicherungslaufwerk sind aktiv (IOPS ~ = 0 - wir haben genügend Arbeitsspeicher). Die Warteschlangenlänge ~ = 0 ist ebenfalls. CPU schwebt um 2-3%, auch dort kein Problem.

Das SAN ist ein Dell MD3220i, die LUN besteht aus 6x10k SAS-Laufwerken. Der Server ist über zwei physische Pfade mit dem SAN verbunden, von denen jeder über einen separaten Switch mit redundanten Verbindungen zum SAN verbunden ist - insgesamt vier Pfade, von denen jeweils zwei aktiv sind. Ich kann über den Task-Manager überprüfen, ob beide Verbindungen aktiv sind - und die Last gleichmäßig verteilen. Beide Verbindungen werden mit 1G Vollduplex betrieben.

Früher haben wir Jumbo-Frames verwendet, aber ich habe sie deaktiviert, um Probleme hier auszuschließen - keine Änderung. Wir haben einen anderen Server (dasselbe OS + config, 2008 R2), der mit anderen LUNs verbunden ist und keine Probleme aufweist. Es wird jedoch nicht SQL Server ausgeführt, sondern nur CIFS über ihnen freigegeben. Einer der bevorzugten LUN-Pfade befindet sich jedoch auf demselben SAN-Controller wie die problematischen LUNs. Daher habe ich dies ebenfalls ausgeschlossen.

Das Ausführen einiger SQLIO-Tests (10G-Testdatei) scheint darauf hinzudeuten, dass IO trotz der folgenden Probleme in Ordnung ist:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Mir ist klar, dass diese Tests in keiner Weise erschöpfend sind, aber sie machen es mir leicht zu wissen, dass es kein kompletter Müll ist. Beachten Sie, dass die höhere Schreibleistung durch die beiden aktiven MPIO-Pfade verursacht wird, während beim Lesen nur einer davon verwendet wird.

Das Überprüfen des Anwendungsereignisprotokolls zeigt Ereignisse wie die folgenden an:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

Sie sind nicht konstant, treten jedoch regelmäßig auf (einige pro Stunde, mehr bei Sicherungen). Neben diesem Ereignis gibt das Systemereignisprotokoll Folgendes aus:

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Diese treten auch auf dem unproblematischen CIFS-Server auf, der auf demselben SAN / Controller ausgeführt wird, und scheinen nach meinem Googeln unkritisch zu sein.

Beachten Sie, dass alle Server dieselben Netzwerkkarten verwenden - Broadcom 5709C mit aktuellen Treibern. Die Server selbst sind Dell R610.

Ich bin nicht sicher, was ich als nächstes überprüfen soll. Irgendwelche Vorschläge?

Update - Perfmon ausführen
Ich habe versucht, die Avg aufzuzeichnen. Leistungsindikatoren für Datenträger-Sek. / Lese- und Schreibzugriff während einer Sicherung. Das Backup startet rasant und hört bei 50% auf, kriecht langsam in Richtung 100%, nimmt aber 20x so viel Zeit in Anspruch, wie es sein sollte.

Zeigt an, dass beide SAN-Pfade verwendet werden und dann abfallen.

Gegen 15:38:50 Uhr wird die Sicherung gestartet. Beachten Sie, dass alles gut aussieht, und dann gibt es eine Reihe von Spitzenwerten. Mir geht es nicht um das Schreiben, nur das Lesen scheint zu hängen.

Beachten Sie, dass nur sehr wenig ein- und ausgeschaltet werden muss, obwohl die Leistung am Ende des Spiels überragend ist.

Beachten Sie ein Maximum von 12 Sekunden, obwohl der Durchschnitt insgesamt gut ist.

Update - Sichern auf ein NUL-Gerät
Um Lesefehler einzugrenzen und die Dinge zu vereinfachen, habe ich Folgendes ausgeführt:

BACKUP DATABASE XXX TO DISK = 'NUL'

Die Ergebnisse waren genau die gleichen. Beginnt mit einem Burst-Lesevorgang und bleibt dann stehen und nimmt ab und zu den Betrieb wieder auf:

Update - IO
blockiert Ich habe die Abfrage dm_io_virtual_file_stats von Jonathan Kehayias und Ted Kruegers Buch (Seite 29) ausgeführt, wie von Shawn empfohlen. Betrachtet man die 25 wichtigsten Dateien (jeweils eine Datendatei - alle Ergebnisse sind Datendateien), scheint es, als ob Lesevorgänge schlechter sind als Schreibvorgänge - möglicherweise, weil Schreibvorgänge direkt in den SAN-Cache geschrieben werden, wohingegen Kaltlesevorgänge die Festplatte treffen müssen - allerdings nur eine Vermutung .

Update - Wartestatistik
Ich habe drei Tests durchgeführt, um einige Wartestatistiken zu sammeln. Die Wartestatistiken werden mit dem Glenn Berry / Paul Randals- Skript abgefragt . Und nur zur Bestätigung: Die Sicherungen werden nicht auf Band, sondern auf einer iSCSI-LUN durchgeführt. Die Ergebnisse sind ähnlich wie bei der lokalen Festplatte, mit ähnlichen Ergebnissen wie bei der NUL-Sicherung.

Statistik gelöscht. Lief für 10 Minuten, normale Belastung:

Statistik gelöscht. Lief für 10 Minuten, normales Laden + normales Backup läuft (nicht abgeschlossen):

Statistik gelöscht. Lief 10 Minuten, normale Last + NUL-Sicherung läuft (nicht abgeschlossen):

Update - Wtf, Broadcom?
Auf der Grundlage von Mark Storey-Smiths Vorschlägen und Kyle Brandts früheren Erfahrungen mit Broadcom-Netzwerkkarten habe ich mich entschlossen, einige Experimente durchzuführen. Da wir mehrere aktive Pfade haben, kann ich die Konfiguration der Netzwerkkarten relativ einfach einzeln ändern, ohne dass es zu Ausfällen kommt.

Das Deaktivieren von TOE und Large Send Offload ergab einen nahezu perfekten Lauf:

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Also, was ist der Täter, TOE oder LSO? TOE aktiviert, LSO deaktiviert:

Didn't finish the backup as it took forever - just as the original problem!

TOE deaktiviert, LSO aktiviert - sieht gut aus:

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

Und als Kontrolle habe ich sowohl TOE als auch LSO deaktiviert, um zu bestätigen, dass das Problem behoben wurde:

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

Zusammenfassend scheint die aktivierte Broadcom NICs TCP Offload Engine die Probleme verursacht zu haben. Sobald TOE deaktiviert war, funktionierte alles wie ein Zauber. Vermutlich werde ich in Zukunft keine Broadcom-Netzwerkkarten mehr bestellen.

Update - CIFS-Server
funktioniert nicht mehr Heute wurden auf dem identischen und funktionsfähigen CIFS-Server E / A-Anforderungen blockiert. Auf diesem Server wurde SQL Server nicht ausgeführt, sondern lediglich Windows Web Server 2008 R2, das Freigaben über CIFS bereitstellt. Sobald ich auch TOE deaktiviert hatte, lief alles wieder reibungslos.

Bestätigt nur, dass ich TOE nie wieder auf Broadcom-NICs verwenden werde, wenn ich den Broadcom-NICs überhaupt nicht aus dem Weg gehen kann.

Beachten Sie, dass alle Server dieselben Netzwerkkarten verwenden - Broadcom 5709C mit aktuellen Treibern. Die Server selbst sind Dell R610.

Kyle Brandt hat eine Meinung zu Broadcom-Netzwerkkarten, die an meine eigene (wiederholte) Erfahrung anknüpft.

Broadcom, Die Mutha

Meine Probleme waren immer mit TCP-Offload- Funktionen verbunden und in 99% der Fälle wurden die Symptome durch Deaktivieren oder Wechseln zu einer anderen Netzwerkkarte behoben. Ein Client, der (wie in Ihrem Fall) Dell-Server verwendet, bestellt immer separate Intel-Netzwerkkarten und deaktiviert die integrierten Broadcom-Karten beim Erstellen.

Wie in diesem MSDN-Blogpost beschrieben , würde ich mit dem Deaktivieren des Betriebssystems beginnen:

netsh int ip set chimney DISABLED

IIRC Unter bestimmten Umständen kann es erforderlich sein, die Funktionen auf der Kartentreiberebene zu deaktivieren. Dies schadet auf keinen Fall.

Nicht, dass ich ein SAN / Disk-Experte wäre (es gibt Leute hier, die mehr wissen als ich) ... Ich teile nur, was ich ein bisschen gemacht und meistens gelesen habe :)

Jonathan Kehayias und Ted Krueger haben ein Buch "Troubleshooting SQL Server" geschrieben, das einige gute Informationen zur Festplattenleistung enthält. Sie können das PDF hier kostenlos herunterladen . (Ich könnte die gedruckte Ausgabe auch für meinen Schreibtisch kaufen.)

Auf jeden Fall haben sie eine gute Abfrage, mit der Sie die sys.dm_io_virtual_file_stats und die durchschnittliche Latenz Ihrer Datendateien überprüfen können. Möglicherweise ist RAID10 nicht die ideale Konfiguration für die Datendateien.