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 quotidiennes différentes 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 général, il fonctionne correctement - à l'exception du problème IO 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). 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 lecteurs 6x10k SAS. 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 gestionnaire de tâches - répartition parfaitement uniforme de la charge 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 IO est décent, 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 la moyenne. Disque sec/Lecture et écriture des compteurs de performance lors d'une sauvegarde. La sauvegarde démarre de façon é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 décrochage.
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 appareil 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 de temps en temps les opérations:
Mise à jour - IO décroche
J'ai exécuté la requête dm_io_virtual_file_stats de Jonathan Kehayias et Ted Kruegers livre (page 29), comme 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 alors que les lectures à froid doit 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 de Glenn Berry/Paul Randals script . 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 les cartes réseau Broadcom activées TCP Offload Engine a causé les 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 - Le serveur CIFS descend
Aujourd'hui, le serveur CIFS identique et fonctionnel a commencé à présenter IO requêtes suspendues. Ce serveur n'exécutait pas SQL Server, juste Windows Web Server 2008 R2 servant des partages sur CIFS. Dès comme j'ai désactivé TOE dessus, tout était redevenu fluide.
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).
Mes problèmes ont toujours été associés aux fonctionnalités TCP Offload 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 article 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 de ici . (Je pourrais peut-être acheter l'édition imprimée de ceci aussi 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.