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)