Les demandes d'E / S prennent plus de 15 secondes

Habituellement, nos sauvegardes complètes hebdomadaires se terminent en environ 35 minutes, avec des sauvegardes différentielles quotidiennes se terminant en ~ 5 minutes. Depuis mardi, les quotidiens ont pris près de 4 heures à compléter, bien plus que nécessaire. Par coïncidence, cela a commencé à se produire juste après que nous ayons obtenu une nouvelle configuration SAN / disque.

Notez que le serveur fonctionne en production et que nous n'avons aucun problème global, il fonctionne correctement - à l'exception du problème d'E / S qui se manifeste principalement dans les performances de sauvegarde.

En regardant dm_exec_requests pendant la sauvegarde, la sauvegarde attend constamment sur ASYNC_IO_COMPLETION. Aha, nous avons donc un conflit de disque!

Cependant, ni le MDF (les journaux sont stockés sur le disque local) ni le lecteur de sauvegarde n'ont d'activité (IOPS ~ = 0 - nous avons beaucoup de mémoire). La longueur de la file d'attente du disque ~ = 0 également. Le CPU oscille autour de 2-3%, aucun problème là-bas non plus.

Le SAN est un Dell MD3220i, le LUN composé de disques SAS 6x10k. Le serveur est connecté au SAN via deux chemins physiques, chacun passant par un commutateur séparé avec des connexions redondantes au SAN - un total de quatre chemins, deux d'entre eux étant actifs à tout moment. Je peux vérifier que les deux connexions sont actives via le gestionnaire de tâches, répartissant ainsi la charge de manière parfaitement uniforme. Les deux connexions fonctionnent en duplex intégral 1G.

Nous avions l'habitude d'utiliser des trames jumbo, mais je les ai désactivées pour exclure tout problème ici - aucun changement. Nous avons un autre serveur (même OS + config, 2008 R2) qui est connecté à d'autres LUN, et il ne montre aucun problème. Cependant, il n'exécute pas SQL Server, mais partage simplement CIFS par dessus. Cependant, l'un de ses chemins d'accès préférés se trouve sur le même contrôleur SAN que les LUN gênants - j'ai donc également exclu cela.

L'exécution de quelques tests SQLIO (fichier de test 10G) semble indiquer que les E / S sont décentes, malgré les problèmes:

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

Je me rends compte que ces tests ne sont en aucun cas exhaustifs, mais ils me mettent à l'aise de savoir que ce ne sont pas des déchets complets. Notez que les performances d'écriture supérieures sont causées par les deux chemins MPIO actifs, tandis que la lecture n'utilisera qu'un seul d'entre eux.

La vérification du journal des événements de l'application révèle des événements comme ceux-ci dispersés autour de:

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

Ils ne sont pas constants, mais ils se produisent régulièrement (un couple par heure, plus pendant les sauvegardes). Parallèlement à cet événement, le journal des événements système affichera les éléments suivants:

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.

Ceux-ci se produisent également sur le serveur CIFS non problématique fonctionnant sur le même SAN / contrôleur, et de mon googling, ils semblent être non critiques.

Notez que tous les serveurs utilisent les mêmes cartes réseau - Broadcom 5709C avec des pilotes à jour. Les serveurs eux-mêmes appartiennent au Dell R610.

Je ne sais pas quoi vérifier ensuite. Aucune suggestion?

Mise à jour - Exécution de perfmon
J'ai essayé d'enregistrer l'Avg. Disque sec / Lecture et écriture des compteurs de performance lors d'une sauvegarde. La sauvegarde démarre de manière éclatante, puis s'arrête essentiellement à 50%, rampant lentement vers 100%, mais en prenant 20 fois le temps qu'elle aurait dû.

Affiche les deux chemins SAN utilisés, puis en cours de suppression.

Sauvegarde lancée vers 15:38:50 - remarquez que tout va bien, puis il y a une série de pics. Je ne suis pas concerné par les écritures, seules les lectures semblent se bloquer.

Notez très peu d'action on / off, bien que des performances fulgurantes à la toute fin.

Notez un maximum de 12 secondes, bien que la moyenne soit globalement bonne.

Mise à jour - Sauvegarde sur un périphérique NUL
Pour isoler les problèmes de lecture et simplifier les choses, j'ai exécuté ce qui suit:

BACKUP DATABASE XXX TO DISK = 'NUL'

Les résultats étaient exactement les mêmes - commence par une lecture en rafale, puis s'arrête, reprenant les opérations de temps en temps:

Mise à jour - IO stands
je courais la requête dm_io_virtual_file_stats de Jonathan Kehayias et Ted Kruegers livre (page 29), tel que recommandé par Shawn. En regardant les 25 premiers fichiers (un fichier de données chacun - tous les résultats étant des fichiers de données), il semblerait que les lectures soient pires que les écritures - peut-être parce que les écritures vont directement au cache SAN tandis que les lectures à froid doivent frapper le disque - juste une supposition cependant .

Mise à jour - Statistiques d'attente
J'ai fait trois tests pour recueillir des statistiques d'attente. Les statistiques d'attente sont interrogées à l'aide du script Glenn Berry / Paul Randals . Et juste pour confirmer - les sauvegardes ne sont pas effectuées sur bande, mais sur un LUN iSCSI. Les résultats sont similaires s'ils sont effectués sur le disque local, avec des résultats similaires à la sauvegarde NUL.

Statistiques effacées. A fonctionné pendant 10 minutes, charge normale:

Statistiques effacées. Fonctionné pendant 10 minutes, charge normale + sauvegarde normale en cours d'exécution (non terminée):

Statistiques effacées. Fonctionné pendant 10 minutes, charge normale + sauvegarde NUL en cours d'exécution (non terminée):

Mise à jour - Wtf, Broadcom?
Sur la base des suggestions de Mark Storey-Smiths et des expériences précédentes de Kyle Brandts avec les cartes réseau Broadcom, j'ai décidé de faire quelques expériences. Comme nous avons plusieurs chemins actifs, je pourrais relativement facilement changer la configuration des cartes réseau une par une sans provoquer de pannes.

La désactivation de la TOE et du déchargement d'envoi volumineux a produit une exécution presque parfaite:

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).

Alors, quel est le coupable, TOE ou LSO? TOE activée, LSO désactivée:

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

TOE désactivée, LSO activée - en bon état:

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).

Et comme contrôle, j'ai désactivé TOE et LSO pour confirmer que le problème avait disparu:

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).

En conclusion, il semble que le moteur de déchargement TCP Broadcom NICs soit à l'origine des problèmes. Dès que la TOE a été désactivée, tout a fonctionné comme un charme. Je suppose que je ne commanderai plus de cartes réseau Broadcom à l'avenir.

Mise à jour - Down va le serveur CIFS
Aujourd'hui, le serveur CIFS identique et fonctionnel a commencé à présenter des demandes d'E / S suspendues. Ce serveur n'exécutait pas SQL Server, simplement Windows Web Server 2008 R2 servant des partages sur CIFS. Dès que j'ai désactivé TOE dessus, tout s'est remis à fonctionner correctement.

Confirme simplement que je n'utiliserai plus TOE sur les cartes réseau Broadcom, si je ne peux pas éviter les cartes réseau Broadcom du tout.

Notez que tous les serveurs utilisent les mêmes cartes réseau - Broadcom 5709C avec des pilotes à jour. Les serveurs eux-mêmes appartiennent au Dell R610.

Kyle Brandt a une opinion sur les cartes réseau Broadcom qui fait écho à ma propre expérience (répétée).

Broadcom, Die Mutha

Mes problèmes ont toujours été associés aux fonctionnalités de déchargement TCP et dans 99% des cas, la désactivation ou le passage à une autre carte réseau a résolu les symptômes. Un client qui (comme dans votre cas) utilise des serveurs Dell, commande toujours des cartes réseau Intel distinctes et désactive les cartes Broadcom intégrées lors de la construction.

Comme décrit dans ce billet de blog MSDN , je commencerais par désactiver le système d'exploitation avec:

netsh int ip set chimney DISABLED

IIRC il peut être nécessaire de désactiver les fonctionnalités au niveau du pilote de carte dans certaines circonstances, cela ne fera certainement pas de mal à le faire.

Non pas que je sois un expert en SAN / disque (il y a des gens ici qui en savent plus que moi) ... Je ne partage que ce que j'ai fait un peu et surtout lu :)

Jonathan Kehayias et Ted Krueger ont écrit un livre "Dépannage de SQL Server" qui contient de bonnes informations sur les performances du disque. Vous pouvez obtenir le PDF gratuitement à partir d' ici . (Je pourrais aussi acheter l'édition imprimée de ceci pour mon bureau.)

Quoi qu'il en soit, ils ont une bonne requête qui peut être utilisée pour vérifier les sys.dm_io_virtual_file_stats et vérifier la latence moyenne de vos fichiers de données. Vous pouvez constater que RAID10 n'est pas la configuration idéale pour les fichiers de données sur lesquels résider.