Database
 sql >> Base de données >  >> RDS >> Database

Les compteurs Zombie PerfMon qui ne meurent jamais !

L'une des choses à la fois formidables et horribles à propos d'Internet est que, une fois que quelque chose est publié dans l'éther, il ne disparaît pratiquement jamais. (Un jour, les politiciens s'en rendront compte. Nous pouvons facilement vérifier leur cohérence.) En raison de la longévité du contenu publié sur Internet, de nombreux sujets d'optimisation des performances deviennent des "zombies". Nous les abattons, mais ils reviennent !

En d'autres termes, ces anciennes recommandations étaient une bonne pratique suggérée il y a longtemps, pour une version spécifique de SQL Server, mais qui est maintenant inappropriée pour la version la plus récente. Il n'est pas rare pour moi, lorsque je prends la parole lors d'une conférence, de rencontrer quelqu'un qui s'accroche encore à des paramètres et à des techniques qui ne sont plus une bonne pratique depuis l'époque de SQL Server 2000. Le Guide des opérations de SQL Server 2000 sur la capacité/le stockage contient de nombreux " meilleures pratiques" qui étaient très spécifiques à la version et ne s'appliquent plus aujourd'hui.

Voici donc un exemple. Le % Disk Time et Disk Queue Length Les compteurs PerfMon ont été fortement recommandés comme indicateurs de performance clés pour les performances d'E/S. SQL Server lance un grand nombre d'E/S sur les disques à l'aide du scatter/gather pour optimiser l'utilisation du sous-système d'E/S sur disque. Cette approche conduit à de courtes rafales de longues profondeurs de file d'attente pendant les points de contrôle et les lectures anticipées pour une instance de SQL Server. Parfois, la charge de travail du serveur est telle que votre disque ne peut pas suivre les E/S qui lui sont imposées et, lorsque cela se produit, vous verrez également de longues longueurs de file d'attente. Le scénario de courte rafale n'est pas un problème. Le scénario d'allongement de la longueur de la file d'attente est généralement un problème. Alors est-ce une bonne pratique ?

En un mot, pas tellement.

Ces compteurs peuvent toujours être utiles sur une instance de SQL Server qui n'a qu'un seul disque dur (bien que ce soit excessivement rare de nos jours). Pourquoi ?

Le compteur PerfMon % Disk Time est une fausse mesure de performance pour plusieurs raisons. Il ne prend pas en compte les requêtes d'E/S asynchrones. Il ne peut pas dire quel peut être le profil de performances réel d'un ensemble RAID sous-jacent, car il contient plusieurs disques. Le compteur PerfMon Disk Queue Length est également généralement inutile, sauf sur les serveurs SQL avec un seul disque physique, car le cache du contrôleur de disque dur masque le nombre d'opérations d'E/S en attente ou non dans la file d'attente. En fait, certains disques durs ont même de minuscules caches en écriture, ce qui complique davantage la question de savoir si les E/S sont vraiment mises en file d'attente, dans un cache quelque part entre le système d'exploitation et le disque, ou ont finalement fait tout le chemin. au CMOS sur le disque.

Meilleurs compteurs de performances d'E/S

Au lieu d'utiliser ces compteurs PerfMon, utilisez le Avg Disk Reads/sec , Avg Disk Writes/sec , et Avg Disk Transfers/sec pour suivre les performances des sous-systèmes de disque. Ces compteurs suivent le nombre moyen d'E/S de lecture, d'E/S d'écriture et d'E/S combinées de lecture et d'écriture qui se sont produites au cours de la dernière seconde. De temps en temps, j'aime suivre les mêmes mesures en fonction du volume de données plutôt que du taux d'opérations d'E/S. Donc, pour obtenir ces données, vous pouvez essayer ces compteurs PerfMon spécifiques au volume : Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec , et Avg Disk Write Bytes/sec .

Pour les performances d'E/S de SQL Server, utilisez les vues de gestion dynamique (DMV)

Et à moins que vous n'ayez vécu dans une grotte, vous devez vous assurer d'utiliser les vues de gestion dynamique (DMV) de SQL Server pour vérifier les performances d'E/S des versions récentes de SQL Server. Certains de mes DMV préférés pour les E/S incluent :

  • sys.dm_os_wait_stats
  • sys.dm_os_waiting_tasks
  • sys.dm_os_performance_counters
  • sys.dm_io_virtual_file_stats
  • sys.dm_io_pending_io_requests
  • sys.dm_db_index_operational_stats
  • sys.dm_db_index_usage_stats

Alors, comment suivez-vous les métriques de performances d'E/S ? Lesquelles utilisez-vous ?

J'ai hâte d'avoir de vos nouvelles !

Profitez-en,
-Kev
–Suivez-moi sur Twitter !