SQL Server a rencontré des occurrences de demandes d'E / S prenant plus de 15 secondes

Sur Production SQL Server, nous avons la configuration suivante:

3 serveurs Dell PowerEdge R630, combinés en groupe de disponibilité Tous les 3 sont connectés à une seule unité de stockage SAN Dell qui est une matrice RAID

De temps en temps, sur PRIMARY, nous voyons des messages similaires à ceux ci-dessous:

SQL Server a rencontré 11 occurrence (s) de demandes d'E / S prenant plus de 15 secondes pour terminer sur le fichier [F: \ Data \ MyDatabase.mdf] dans l'ID de base de données 8.
Le descripteur de fichier du système d'exploitation est 0x0000000000001FBC.
Le décalage de la dernière longue E / S est: 0x000004295d0000.
La durée de la longue E / S est: 37397 ms.

Nous sommes novices dans le dépannage des performances

Quels sont les moyens les plus courants ou les meilleures pratiques pour résoudre ce problème particulier lié au stockage? Quels compteurs de performances, outils, moniteurs, applications, etc. doivent être utilisés pour limiter la cause première de ces messages? Pourrait-il y avoir des événements étendus qui peuvent aider, ou une sorte d'audit / de journalisation?

Nous avons une configuration similaire et avons récemment rencontré ces messages dans les journaux. Nous utilisons un DELL Compellent SAN. Voici quelques éléments à vérifier lors de la réception de ces messages qui nous ont aidés à trouver une solution

• Examinez vos compteurs de performances Windows pour vos disques vers lesquels les messages d'avertissement pointent, en particulier:
  • Disque moy. Temps de lecture
  • Disque moy. temps d'écriture
  • Octets de lecture du disque / s
  • Octets d'écriture sur disque / s
  • Transferts de disque / s
  • Moy. longueur de la file d'attente du disque
• Ce qui précède sont des moyennes. Si vous avez plusieurs fichiers de base de données sur un lecteur, ces moyennes peuvent fausser le résultat et masquer un goulot d'étranglement sur des fichiers de base de données spécifiques. Découvrez cette requête de Paul S. Randal qui renvoie la latence moyenne pour chaque fichier du dmv sys.dm_io_virtual_file_stats. Dans notre cas, la latence moyenne signalée était acceptable, mais sous les couvertures, nous avions de nombreux fichiers avec une latence moyenne> 200 ms.
• Vérifiez les horaires. Y a-t-il un modèle? Cela se produit-il plus fréquemment à une certaine heure de la nuit? Si tel est le cas, vérifiez si des travaux de maintenance sont en cours d'exécution à ce moment-là ou toute activité planifiée susceptible d'augmenter l'activité du disque et d'exposer un goulot d'étranglement dans votre sous-système d'E / S.
• Recherchez des erreurs dans l'Observateur d'événements Windows. Si votre commutateur ou votre SAN est surchargé ou n'est pas configuré correctement pour votre application, vous pouvez trouver des messages dans ce journal, et il est bon de transmettre ces informations à votre administrateur SAN. Dans notre cas, nous recevions souvent des erreurs de connexion iSCSI tout au long de la journée, faisant allusion au problème.
• Vérifiez votre code SQL Server. Lorsque vous recevez ces messages, vous ne devez pas immédiatement penser qu'il s'agit d'un problème de sous-système d'E / S et le transmettre à votre administrateur SAN. Vous devez faire votre part et revoir la base de données. Avez-vous de très mauvaises requêtes en cours d'exécution qui parcourent souvent des tonnes de données? Mauvaise indexation? Écriture excessive du journal des transactions? Vous pouvez utiliser certaines requêtes open source pour obtenir un bilan de santé de votre base de données, un exemple pour vérifier à quoi ressemble votre plan de requête est sp_blitzCache
• Ne les ignorez pas. Aujourd'hui, vous les recevez peut-être plusieurs fois par jour ... puis plusieurs mois plus tard lorsque votre charge de travail augmente et que vous avez oublié de les surveiller, ils commencent à augmenter. La réception d'un grand nombre de ces messages peut empêcher SQL Server d'accéder à un certain fichier, et s'il s'agit de tempdb , ce n'est pas bon. Dans notre cas, c'est devenu si mauvais que SQL Server s'est arrêté.

Notre solution consistait à mettre à niveau notre commutateur vers un commutateur SAN. Oui, ce sont tous des points à couvrir dans SQL Server. Ce qui nous a amenés à découvrir que c'était le changement, c'est que nous recevions chaque jour environ 1500 erreurs de déconnexion de pdu iSCSI dans l'Observateur d'événements d'applications Windows sur le serveur SQL. Cela a incité nos administrateurs SAN à enquêter sur le commutateur.

Immédiatement après la mise à niveau, les erreurs iSCSI ont disparu et la latence moyenne est tombée à environ 50 ms pour tous les fichiers, ce qui était corrélé à de meilleures performances dans l'application. Avec ces points à l'esprit, nous espérons que vous pourrez trouver votre solution.

C'est beaucoup moins souvent un problème de disque et beaucoup plus souvent un problème de réseau. Vous savez, le N dans SAN?

Si vous allez voir votre équipe SAN et commencez à parler de la lenteur des disques, ils vont vous montrer un graphique sophistiqué avec une latence de 0 milliseconde dessus, puis pointer une agrafeuse vers vous.

Demandez-leur plutôt le chemin réseau vers le SAN. Obtenez des vitesses, s'il s'agit de plusieurs trajets, etc. Obtenez des chiffres sur les vitesses que vous devriez voir. Demandez-leur s'ils ont des repères depuis la configuration des serveurs.

Ensuite, vous pouvez utiliser Crystal Disk Mark ou diskpd pour valider ces vitesses. S'ils ne s'alignent pas, encore une fois, c'est probablement le réseautage.

Vous devez également rechercher dans votre journal des erreurs les messages qui contiennent «FlushCache» et «saturation», car ceux-ci peuvent également être des signes de conflit de réseau.

Une chose que vous pouvez faire pour éviter ces choses en tant qu'administrateur de base de données est de vous assurer que votre maintenance et toutes les autres tâches gourmandes en données (comme ETL) ne se déroulent pas en même temps. Cela peut certainement mettre beaucoup de pression sur les réseaux de stockage.

Vous pouvez également consulter les réponses ici pour plus de suggestions: point de contrôle lent et avertissements d'E / S de 15 secondes sur le stockage flash

J'ai blogué sur un sujet similaire ici: Du serveur au SAN

Pourquoi stocker les données sur un SAN? À quoi ça sert? Toutes les performances de la base de données sont liées aux E / S disque et vous utilisez 3 serveurs avec un seul périphérique pour les E / S derrière eux. Cela n'a aucun sens ... et malheureusement si commun.

Je passe ma vie à rencontrer des plates-formes matérielles mal conçues où les gens essaient simplement de concevoir un ordinateur à grande échelle. Toute la puissance du processeur ici, tous les disques là-bas ... espérons que la RAM distante n'existe pas. Et le plus triste est qu'ils compensent le manque d'efficacité de cette conception avec d'énormes serveurs qui coûtent dix fois plus cher qu'ils ne le devraient. J'ai vu 400 000 $ infra plus lentement qu'un ordinateur portable à 1 000 $.

Un logiciel serveur SQL est un logiciel très avancé, il est conçu pour tirer parti de n'importe quel morceau de matériel, cœurs de processeur, cache de processeur, TLB, RAM, contrôleurs de disque, cache de disque dur ... Ils incluent presque toute la logique du système de fichiers. Ils sont développés sur ordinateur ordinaire et référencés sur des systèmes haut de gamme. Par conséquent, un serveur SQL doit avoir ses propres disques. Les installer sur un SAN, c'est comme "émuler" un ordinateur, vous perdez toutes les optimisations de performances. Les SAN sont destinés au stockage de sauvegardes, de fichiers immuables et de fichiers auxquels vous venez d'ajouter des données (journaux).

Les administrateurs de centre de données ont tendance à mettre tout ce qu'ils peuvent sur les SAN car de cette façon, ils n'ont qu'un seul pool de stockage à gérer, c'est plus facile que de prendre soin du stockage sur chaque serveur. C'est un choix «je ne veux pas faire mon travail», et un très mauvais choix, car alors ils doivent faire face à des problèmes de performance et toute l'entreprise en souffre. Installez simplement le logiciel sur le matériel pour lequel il est conçu. Rester simple. Attention à la bande passante d'E / S, au cache et au changement de contexte, à la gigue des ressources (se produit lorsque la ressource est partagée). Vous finirez par conserver 1 / 10e des appareils pour la même puissance de sortie brute, économiserez beaucoup de maux de tête à votre équipe opérationnelle, augmenterez les performances qui rendront vos utilisateurs finaux heureux et plus productifs, feront de votre entreprise un meilleur endroit où travailler, et économiser beaucoup d'énergie (la planète vous en remerciera).

Vous avez dit dans les commentaires que vous envisagez de mettre un SSD sur votre serveur. Vous ne reconnaîtrez pas votre configuration avec des SSD dédiés, par rapport à un SAN, vous obtiendrez quelque chose comme une amélioration de 500x même avec des données et des fichiers journaux de transactions sur le même lecteur. Un état de l'art SQL Server aurait un SSD séparé rapide pour les données et le journal des transactions sur différents canaux de contrôleurs matériels (la plupart des cartes mères de serveurs en ont plusieurs). Mais par rapport à votre configuration actuelle, nous parlons ici de science-fiction. Essayez simplement le SSD.

Ok, pour toute personne intéressée,

Nous avons résolu le problème dans Question il y a quelques mois simplement en installant des disques SSD directement connectés dans chacun des 3 serveurs et en déplaçant les données DB et les fichiers journaux du SAN vers ces disques SSD

Voici un résumé de ce que j'ai fait pour rechercher sur ce problème (en utilisant les recommandations de tous les articles de cette question), avant de décider d'installer des disques SSD:

1) a commencé à collecter des compteurs PerfMon pour les lecteurs suivants sur les 3 serveurs:

Disk F:est un disque logique basé sur SAN, contient des fichiers de données MDF
Disk I:est un disque logique basé sur SAN, contient des fichiers journaux LDF
Disk T:est directement connecté SSD, dédié uniquement à tempDB

L'image ci-dessous représente les valeurs moyennes collectées pour une période de 2 semaines

Disk I: (LDF)a un si petit IO et la latence est très faible, donc le disque I: peut être ignoré
Vous pouvez voir qu'il Disk T: (TempDB)a un plus grand IO par rapport à Disk F: (MDF), et il a une bien meilleure latence en même temps - 0 ms

De toute évidence, quelque chose ne va pas avec le disque F: là où résident les fichiers de données, il a une latence élevée et une file d'attente d'écriture de disque moyenne, malgré un faible E / S

2) Latence vérifiée pour les bases de données individuelles en utilisant la requête de ce site Web

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Peu de bases de données actives sur le serveur primaire ont lu 150-250 ms de latence et 150-450 ms latence d' écriture
Ce qui est intéressant, les fichiers de base de données master et msdb avaient lu la latence jusqu'à 90 ms , ce qui est suspect compte tenu de la petite taille de leurs données et de faible IO - une autre indication que quelque chose ne va pas avec SAN

3) Il n'y avait pas de calendrier précis

Au cours de laquelle des messages "SQL Server a rencontré des occurrences ..." sont apparus
Il n'y avait pas de maintenance ou d'ETL de disque lourd en cours d'exécution lorsque ces messages ont été enregistrés

4) Observateur d'événements Windows

N'a montré aucune autre entrée qui suggérerait le problème, sauf "SQL Server a rencontré des occurrences ..."

5) A commencé à vérifier les 10 principales requêtes

De sp_BlitzCache (cpu, lectures, etc.), et omptimiser si possible
Pas de requêtes lourdes super IO qui produiraient des tonnes de données et auraient un impact lourd sur le stockage, bien que l'
indexation dans les bases de données soit OK, je la maintiens

6) Nous n'avons pas d'équipe SAN

Nous n'avons qu'un seul administrateur système qui aide à l'occasion sur le
chemin du réseau vers le SAN - il est à chemins multiples, chacun des 3 serveurs a 2 câbles réseau menant aux commutateurs, puis au SAN, et son supposé être de 1 gigaoctet / sec

7) Aucun résultat CrystalDiskMark

Ou tout autre résultat de test de référence depuis la configuration des serveurs, donc je ne sais pas quelles devraient être les vitesses , et il n'est pas possible de comparer à ce stade pour voir quelles sont les vitesses actuellement, car cela aurait eu un impact sur la production

8) Configuration de la session d'événements étendus sur l'événement de point de contrôle pour la base de données en question

La session XE a permis de découvrir que pendant les messages "SQL Server a rencontré des occurrences ...", le point de contrôle s'est produit très lentement (jusqu'à 90 secondes)

9) Journal des erreurs SQL Server

Entrées "FlushCache" "Saturation" contenues
Celles-ci doivent apparaître lorsque l'heure du point de contrôle pour la base de données donnée dépasse les paramètres d'intervalle de récupération

Les détails ont montré que la quantité de données que le point de contrôle tente de vider est petite et prend beaucoup de temps à terminer, et la vitesse globale est d'environ 0,25 Mo / s ... bizarre

10) Enfin, cette image montre un tableau de dépannage de stockage:

Il semble que nous ayons simplement un "problème matériel: - Travaillez avec l'administrateur système / le fournisseur de matériel pour corriger toute mauvaise configuration du SAN, des pilotes anciens / défectueux, des contrôleurs, du micrologiciel, etc."

Dans une autre question "Point de contrôle lent ..." Point de contrôle lent et avertissements d'E / S de 15 secondes sur le stockage flash Sean avait une très belle liste des éléments à vérifier au niveau matériel et logiciel pour dépanner

Notre administrateur système n'a pas pu vérifier toutes les choses de la liste, nous avons donc simplement choisi de jeter du matériel à ce problème - ce n'était pas cher du tout

Résolution:

Nous avons commandé des disques SSD de 1 To et installés directement sur les serveurs

Étant donné que nous avons des groupes de disponibilité, nous avons migré les fichiers de données DB du SAN vers le SSD sur des réplicas secondaires, puis basculé et migré les fichiers sur l'ancien principal. Cela a permis un temps d'arrêt total minimal - moins d'une minute

Désormais, chaque serveur dispose d'une copie locale des données de base de données et des sauvegardes complètes / diff / journaux sont effectuées sur le SAN mentionné
. les reconstructions d'index, les requêtes, etc. ont considérablement augmenté

Quelles sont les performances en termes de latence d'E / S qui se sont améliorées depuis la migration des fichiers DB vers SSD?

Pour évaluer l'impact, utilisé les performances de l'Analyseur de performances Windows enregistre 2 semaines avant la migration et 4 semaines après la migration:

Vous trouverez également ci-dessous une comparaison des statistiques de latence au niveau de la base de données (utilisé les statistiques des fichiers virtuels capturés de SQL Server avant et après la migration)

Sommaire

La migration du SAN vers les SSD locaux directement connectés en valait la peine.Elle a
eu un grand impact sur la latence du stockage et s'est bien améliorée de plus de 90% en moyenne (en particulier les opérations WRITE), et nous n'avons plus de pics de 20 à 50 secondes chez IO

Le passage au SSD local a résolu non seulement les problèmes de performances de stockage, mais également la sécurité des données qui m'inquiétait (si le SAN échoue, les 3 serveurs perdent leurs données en même temps)