Comment identifier et résoudre une utilisation intensive du processeur sur mon instance RDS for SQL Server ?

Lecture de 7 minute(s)
0

Je constate une utilisation intensive du processeur sur mes instances de base de données Amazon Relational Database Service (Amazon RDS) for Microsoft SQL Server. Comment identifier et résoudre une utilisation intensive du processeur ?

Brève description

Les causes courantes de l'augmentation de l'utilisation du processeur sont les suivantes :

  • Charges de travail intensives initiées par l'utilisateur, requêtes multiples simultanées ou transactions de longue durée
  • Utilisation d'une classe d'instance sous-provisionnée pour la charge de travail
  • Statistiques obsolètes et fragmentation des index ou index manquants
  • Requêtes pouvant faire l'objet d'améliorations
  • Blocages et interblocages
  • Parallélisme
  • Compilation et recompilation fréquentes
  • Détection des paramètres
  • Insuffisance de fils

Pour identifier la source de l'utilisation du processeur dans votre instance Amazon RDS for SQL Server, passez en revue les outils suivants :

  • Métriques Amazon CloudWatch pour Amazon RDS
  • Enhanced Monitoring (Surveillance améliorée)
  • Performance Insights (Analyse des performances)
  • Outils natifs de SQL Server

Une fois la source identifiée, vous pouvez analyser et optimiser votre charge de travail afin de réduire l'utilisation du processeur.

Solution

Métriques Amazon CloudWatch pour Amazon RDS

Vous pouvez utiliser les métriques CloudWatch pour identifier les modèles de processeur pendant des périodes prolongées. Comparez les graphiques WriteIOPs, ReadIOPs, ReadThroughput et WriteThroughput, ainsi que l'utilisation du processeur (CPU) pour trouver les moments où la charge de travail a entraîné une utilisation intensive du processeur (CPU). Pour plus d'informations, consultez les métriques Amazon CloudWatch pour Amazon RDS.

Si vous utilisez une instance de la classe d'instance t2 ou t3, vérifiez si votre instance est sous-approvisionnée. Si vous constatez une diminution constante du solde de crédits du processeur et une augmentation constante de l'utilisation du crédit du processeur, alors vos cœurs de processeur ne sont pas suffisants pour votre charge de travail.

Une fois la période identifiée, vous pouvez consulter les données Enhanced Monitoring (Surveillance accrue) associées à votre instance de base de données. Vous pouvez paramétrer Enhanced Monitoring (Surveillance améliorée) pour collecter des données à des intervalles de 1, 5, 10, 15, 30 ou 60 secondes. Cela vous permet de collecter des données à un niveau plus détaillé que CloudWatch.

Enhanced Monitoring (Surveillance améliorée)

Si vous avez configuré Enhanced Monitoring (Surveillance améliorée), vous pouvez l'utiliser pour surveiller le système d'exploitation s'exécutant sur votre instance de base de données. Pour vérifier l'utilisation du processeur à l'aide de Enhanced Monitoring (Surveillance améliorée), procédez comme suit :

  1. Dans la console RDS, sélectionnez Bases de données, puis choisissez votre base de données.
  2. Dans l'onglet Surveillance, sélectionnez la liste des processus du système d'exploitation dans le menu déroulant Surveillance. Vérifiez si l’intensité du processeur est pilotée par le système d'exploitation, un processus RDS, un processus SQL Server ou un processus SQL Agent. Vous pouvez également vérifier le pourcentage d’utilisation du processeur et de la mémoire à l’aide de ces processus.
  3. Sélectionnez des métriques dans la liste déroulante Enhanced Monitoring (Surveillance améliorée) pour vérifier les données du moniteur de performance. Ces métriques incluent l'inactivité du processeur, le noyau et l'utilisateur. Ces métriques vous indiquent si, la plupart du temps, le processeur est inactif, exécute le noyau ou des processus utilisateur.
  4. Consultez d'autres métriques en sélectionnant Gestion des graphiques. Vous pouvez ensuite sélectionner les métriques relatives aux E-S et au débit du disque. Ces métriques comprennent la lecture par seconde, l'écriture par seconde, la lecture (Ko/s) et l'écriture (Ko/s). Vous pouvez également consulter les paramètres relatifs à la mémoire, comme la mémoire disponible, la mémoire SQL Server et la mémoire totale. Ces métriques sont utiles, car si votre processeur passe beaucoup de temps à attendre des ressources, vous pouvez constater une utilisation élevée du processeur.

Pour plus d'informations, consultez Affichage des métriques du système d'exploitation dans la console RDS.

Performance Insights (Analyse des performances)

Vous pouvez utiliser l’analyse des performances d’Amazon RDS pour identifier les requêtes responsables du chargement de la base de données. Pour ce faire,

  1. Vérifiez l'onglet SQL qui correspond à la période que vous voulez analyser.
  2. Identifiez la requête qui prend le plus de temps.
  3. Vérifiez la requête exigeante en ressources et les événements d'attente observés pendant cette période. Les événements d'attente ci-après sont fréquemment associés à une utilisation élevée du processeur :
    SOS_SCHEDULER_YIELD : cette attente indique qu'un travailleur a cédé pour laisser place à une autre exécution. En général, un nombre d'attente élevé associé à de faibles temps d'attente indique des requêtes liées au processeur. Les temps d'attente élevés peuvent être dus à des problèmes de génération. Si vous constatez un long délai d'attente, vous devez réexaminer la charge de travail.
    Si SOS_SCHEDULER_YIELD est le type d'attente courant, cela peut indiquer que la pression du processeur est à l'origine du problème. Passez en revue le type de charge de travail et effectuez des ajustements supplémentaires.
    CXPACKET et CXCONSUMER : en général, les événements d'attente liés au parallélisme ne sont pas un problème. Toutefois, si les événements d'attente sont fréquents et affectent les performances, passez en revue les requêtes et définissez des valeurs appropriées pour le seuil de coût du parallélisme. Assurez-vous que SQL Server choisit le paramètre de parallélisme le plus économique du groupe de paramètres.
    Vous pouvez également augmenter le MAXDOP (degré maximal de parallélisme) à 1 au niveau de la requête ou de l'instance, en fonction de votre cas d'utilisation.
    ThreadPool : cet événement d'attente indique une insuffisance de fils. Si votre classe d'instance peut le prendre en charge, augmentez le paramètre de nombre maximal de fils de travail. Des attentes ThreadPool peuvent survenir en raison de l'utilisation d'un nombre excessif de fils.. Un nombre excessif de fils est utilisé en raison d’un blocage, d'une charge de travail élevée ou d'un grand nombre de requêtes parallèles. Ou bien, cette attente peut être due à une mauvaise configuration du paramètre de nombre maximal de fils de travail.
  4. Vérifiez les métriques de base de données pour les requêtes par lots, les compilations SQL et les recompilations SQL. Vérifiez si les requêtes sont compilées de nombreuses fois, ce qui indique des requêtes improvisées. Vérifiez également si les requêtes sont recompilées fréquemment pour un lot donné, en indiquant l'utilisation avec recompilation dans le code de la requête. Ces deux facteurs entraînent une utilisation élevée du processeur.

Outils natifs de SQL Server

Requêtes spécifiques pour la résolution de problèmes liés au processeur : pour plus d'informations, voir Résoudre les problèmes d'utilisation intensive du processeur dans SQL Server sur le site Web de documentation Microsoft. Concentrez-vous sur les requêtes exigeantes en ressources du processeur, les statistiques de mise à jour, les index manquants et la détection de paramètres.

Vérifiez le plan d'exécution ne contient pas de requêtes peu performantes et procédez des réglages supplémentaires. Pour plus d'informations, voir Affichage d’un plan d'exécution réel sur le site Web de documentation Microsoft.

Résolvez les problèmes liés au verrouillage, au blocage et à l'interblocage excessifs à l'aide de requêtes et d'événements étendus. Pour plus d'informations, voir Compréhension et résolution des problèmes de blocage de SQL Server sur le site Web de documentation Microsoft.

Remarque : vous ne pouvez pas utiliser la méthode normale pour enregistrer des fichiers XEL lors de la configuration d’événements étendus dans RDS for SQL Server. Pour obtenir des instructions sur la manière de configurer Extended Events, voir Configuration d’événements étendus dans Amazon RDS for SQL Server.

Utilisez les rapports SQL Server pour obtenir les rapports de performance disponibles de manière native dans SQL Server. Utilisez ces rapports pour ajuster votre charge de travail. Pour plus d'informations, consultez Tableau de bord des performances sur le site Web de documentation Microsoft.