Je suis un étudiant de l'Université Fontys à Eindhoven, et je mène actuellement une série d'entretiens pour aider au développement d'un outil SQL Server et je voudrais obtenir les commentaires des experts dans le domaine.
Une de mes questions est:
Quels compteurs de performances pouvez-vous consulter sur une instance SQL Server pour déterminer ses performances et son état de santé général?
Je m'intéresse particulièrement aux valeurs seuils lorsque le bien devient mauvais.
Jamil Young Eindhoven Pays-Bas
sql-server
performance
Jamil
la source
la source
Il s'agit d'un gros sujet avec beaucoup de matériel disponible avec un peu de googling. Comme point de départ, ce sont les compteurs que j'ai tendance à regarder en premier:
Processeur -% temps processeur
Système - Longueur de la file d'attente du processeur
Vous obtiendrez probablement une valeur cible différente pour l'utilisation du processeur de chaque DBA que vous demandez. Les licences SQL Server sont chères, donc d'une part, vous voulez maximiser l'utilisation des CPU tandis que d'autre part, vous ne voulez pas compromettre la disponibilité. Dans un monde idéal avec des charges de travail bien comprises, vous pouvez cibler une utilisation de 70%, avertir à 80-90%, alerte à 90% +. De retour dans le monde réel avec une charge de travail qui atteint des sommets et des creux, vous pourriez être plus à l'aise en ciblant une moyenne de 50 à 60%.
Mémoire - Mo disponibles
Fichier d'échange -% d'utilisation
Avec un serveur SQL dédié, selon la RAM installée, moins de 100 à 200 Mo de mémoire disponible peuvent indiquer la famine et un risque de pagination du système d'exploitation. En général, nous ne voulons pas voir beaucoup d'activité de fichier de page, donc j'examinerais si le% d'utilisation était supérieur à 2% et je m'inquiéterais s'il atteignait 5%
Gestionnaire de tampons - Taux de succès du cache de tampons
Buffer Manager - Espérance de vie de la page
Ces deux compteurs sont mieux considérés par rapport à une ligne de base établie pour un serveur. Idéalement, nous aimerions un taux d'accès au cache aussi proche que possible de 100% et un PLE s'exécutant en milliers de secondes. Faites attention quand ils s'éloignent des moyennes historiques.
Statistiques SQL - Demandes de lot / s
Statistiques SQL - Compilations / s
Statistiques SQL - Recompilations / s
Les requêtes / s sont une excellente mesure relative de l'occupation d'un serveur. Des valeurs de compilation / recompilation élevées peuvent indiquer que des cycles CPU sont gaspillés lors de la compilation de requêtes.
Disque physique - Moy. Disque sec / lecture
Disque physique - Moy. Disque sec / écriture
Disque physique - Lectures de disque / s
Disque physique - Écritures de disque / s
Une directive approximative pour un système d'E / S correctement configuré est <5 ms (idéalement 1 ms) pour les lecteurs de journal, <20 ms (idéalement <10 ms) pour les données. Les lectures / écritures par seconde doivent être considérées par rapport à la limite connue pour le (s) lecteur (s), c'est-à-dire si vous avez une capacité de 1000 IOPS, j'évaluerais les options de mise à niveau lorsque l'IOPS moyen atteindrait 750.
la source