it-swarm.com.de

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

Normalerweise werden unsere wöchentlichen vollständigen Sicherungen in etwa 35 Minuten abgeschlossen, während die täglichen Diff-Sicherungen in ca. 5 Minuten abgeschlossen sind. Seit Dienstag haben die Tageszeitungen fast 4 Stunden gebraucht, weit mehr als nötig. Zufälligerweise geschah dies direkt nachdem wir eine neue SAN/Disk-Konfiguration erhalten hatten.

Beachten Sie, dass der Server in der Produktion ausgeführt wird und wir keine allgemeinen Probleme haben. Er läuft reibungslos - mit Ausnahme des Problems IO], das sich hauptsächlich in der Sicherungsleistung manifestiert.

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

Weder das MDF (Protokolle werden auf der lokalen Festplatte gespeichert) noch das Sicherungslaufwerk haben irgendeine Aktivität (IOPS ~ = 0 - wir haben genügend Speicher). Die Länge der Festplattenwarteschlange ~ = 0 ist ebenfalls hoch. Die 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 mit dem SAN durch) verbunden zwei physische Pfade, die jeweils über einen separaten Switch mit redundanten Verbindungen zum SAN - insgesamt vier Pfade, von denen zwei jederzeit aktiv sind) durchlaufen. Ich kann überprüfen, ob beide Verbindungen aktiv sind Task-Manager - verteilt die Last perfekt gleichmäßig. Auf beiden Verbindungen wird 1G-Vollduplex ausgeführt.

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 Betriebssystem + Konfiguration, 2008 R2), der mit anderen LUNs verbunden ist und keine Probleme aufweist. Es wird jedoch kein SQL Server ausgeführt, sondern nur CIFS darüber freigegeben. Einer der von LUNs bevorzugten 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 anständig 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 dies in keiner Weise erschöpfende Tests sind, aber sie machen es mir bequem zu wissen, dass es kein vollständiger 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.

Durch Überprüfen des Anwendungsereignisprotokolls werden Ereignisse wie diese angezeigt:

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, aber sie treten regelmäßig auf (ein paar pro Stunde, mehr während Backups). Neben diesem Ereignis werden im Systemereignisprotokoll folgende Informationen veröffentlicht:

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 nach meinem Googeln scheinen sie unkritisch zu sein.

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

Ich bin mir nicht sicher, worauf ich als nächstes achten soll. Irgendwelche Vorschläge?

Update - Perfmon ausführen
Ich habe versucht, den Durchschn. Disk sec/Read & Write-Leistungsindikatoren während der Durchführung einer Sicherung. Das Backup beginnt blitzschnell und endet dann bei 50%. Es kriecht langsam in Richtung 100%, benötigt aber das 20-fache der Zeit, die es haben sollte.

Task monitor during start of backup Zeigt beide SAN Pfade, die verwendet werden und dann abfallen) an.

Perform during same Das Backup wurde gegen 15:38:50 Uhr gestartet. Beachten Sie, dass alles gut aussieht, und dann gibt es eine Reihe von Spitzen. Ich bin nicht mit den Schreibvorgängen beschäftigt, nur die Lesevorgänge scheinen zu hängen.

Task monitor during end of backup Beachten Sie sehr wenig Action beim Ein- und Ausschalten, obwohl die Leistung ganz am Ende ist.

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

Update - Sichern auf NUL-Gerät
Um Leseprobleme zu isolieren und Dinge zu vereinfachen, habe ich Folgendes ausgeführt:

BACKUP DATABASE XXX TO DISK = 'NUL'

Die Ergebnisse waren genau die gleichen - beginnen mit einem Burst-Lesevorgang und werden dann blockiert, wobei ab und zu der Betrieb wieder aufgenommen wird:

Results

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. Wenn man sich die Top-25-Dateien ansieht (jeweils eine Datendatei - alle Ergebnisse sind Datendateien), scheint es, als wären Lesevorgänge schlechter als Schreibvorgänge - vielleicht, weil Schreibvorgänge direkt in den Cache SAN) gehen, während Kaltlesevorgänge ausgeführt werden muss auf die Festplatte - nur eine Vermutung.

IO Stalls

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

Gelöschte Statistiken. 10 Minuten gelaufen, normale Belastung: No backup

Gelöschte Statistiken. Lief 10 Minuten lang, normale Last + normales Backup (nicht abgeschlossen): Normal backup

Gelöschte Statistiken. Lief 10 Minuten lang, normales Laden + NUL-Backup läuft (nicht abgeschlossen): NUL backup

Update - Wtf, Broadcom?
Aufgrund von Mark Storey-Smiths Vorschlägen und Kyle Brandts früheren Erfahrungen mit Broadcom-Netzwerkkarten habe ich beschlossen, 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: enter image description here

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, welcher ist der Schuldige, TOE oder LSO? TOE aktiviert, LSO deaktiviert: enter image description here

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

TOE deaktiviert, LSO aktiviert - sieht gut aus: enter image description here

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 ist: enter image description here

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 es, dass die aktivierten Broadcom-NICs TCP Offload Engine die Probleme verursacht haben. Sobald TOE deaktiviert wurde, funktionierte alles wie ein Zauber. Ich schätze, ich werde in Zukunft keine Broadcom-NICs mehr bestellen .

Update - Der CIFS-Server fällt aus
Heute zeigte der identische und funktionierende CIFS-Server IO Anfragen hängen. Auf diesem Server wurde kein SQL Server ausgeführt, sondern nur Windows Web Server 2008 R2, das Freigaben über CIFS bereitstellt. Sobald Da ich auch TOE deaktiviert habe, lief alles wieder reibungslos.

Bestätigt nur, dass ich TOE nie wieder auf Broadcom-NICs verwenden werde, wenn ich die Broadcom-NICs überhaupt nicht vermeiden kann.

31

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

Kyle Brandt hat eine Meinung zu Broadcom-Netzwerkkarten, die meine eigene (wiederholte) Erfahrung widerspiegelt.

Broadcom, Die Mutha

Meine Probleme waren immer mit TCP Offload Funktionen verbunden und in 99% der Fälle hat das Deaktivieren oder Umschalten auf eine andere Netzwerkkarte die Symptome 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-Blog-Beitrag beschrieben, würde ich mit dem Deaktivieren im Betriebssystem beginnen mit:

netsh int ip set chimney DISABLED

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

14

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

Jonathan Kehayias und Ted Krueger haben ein Buch "Fehlerbehebung bei SQL Server" geschrieben, das einige gute Informationen zur Festplattenleistung enthält. Sie können das PDF kostenlos von hier erhalten. (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.

4
user507