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 Dell SAN qui est une matrice RAID
De temps en temps, sur PRIMARY, nous voyons des messages similaires à 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.
L'offset des dernières E/S longues 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 SAN Dell Compellent. 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. Consultez la requête this de Paul S. Randal qui retourne 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 IO.
- Recherchez des erreurs dans l'Observateur d'événements Windows. Si votre commutateur ou 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 prendre ces informations dans votre SAN admin. 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 penser immédiatement qu'il s'agit d'un problème de sous-système IO et le transmettre à votre administrateur SAN. Vous devez faire votre part et examinez 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 des requêtes open source pour obtenir un contrôle de santé de votre base de données, un exemple pour vérifier le fonctionnement de votre requête l'apparence du plan est sp_blitzCache
- Ne les ignorez pas. Aujourd'hui, vous pouvez les recevoir 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 de beaucoup de ces messages peut empêcher SQL Server d'accéder à un certain fichier, et si c'est 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 commutateur était que nous recevions environ 1500 iSCSI Les erreurs de déconnexion de pdu dans l'Observateur d'événements d'applications Windows sur le serveur SQL chaque jour. 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 correspondait à 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 dans votre équipe SAN et que vous 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 d'erreurs les messages contenant "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 vérifier 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 lent qu'un ordinateur portable de 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. En les installant sur un SAN, c'est comme "émuler" un ordinateur, vous perdez toutes les optimisations de performances. Les SAN servent à stocker des sauvegardes, des fichiers immuables et des fichiers auxquels vous ajoutez simplement 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 d'opérations, augmentez les performances qui rendent vos utilisateurs finaux heureux et plus productifs, faites 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 ont 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 de science-fiction. Essayez simplement le SSD.