Présentation de la capture des performances Cloud SQL

L'enregistrement des performances de Cloud SQL pour MySQL vous aide à diagnostiquer et à résoudre les problèmes de performances complexes et temporaires de votre base de données MySQL, causés par l'évolution de la demande du système. À mesure que les charges de travail des applications évoluent et que l'infrastructure environnante devient plus complexe, les bases de données sont soumises à des demandes croissantes et imprévisibles. Ces pressions externes sur le système peuvent entraîner des ralentissements ou des blocages de la base de données.

Lorsque les performances de votre base de données se dégradent, les métriques standards peuvent être insuffisantes pour identifier la cause première dans le contexte de votre infrastructure plus vaste. L'enregistrement des performances résout ce problème en capturant des instantanés détaillés de la base de données à un moment précis, au moment où un problème est détecté. Vous pouvez utiliser des déclencheurs configurables pour prendre des instantanés à l'échelle du système lorsque des problèmes temporaires se produisent. Les déclencheurs peuvent également détecter les transactions de longue durée, qui peuvent être à l'origine de problèmes de performances. Vous pouvez configurer des déclencheurs pour mettre fin automatiquement aux transactions de longue durée.

Exemples de cas d'utilisation

Cette section présente des exemples de cas d'utilisation de l'enregistrement des performances une fois que vous l'avez activé pour votre instance.

Cas d'utilisation Condition de déclenchement Insight de diagnostic
Ralentissement à l'échelle du système en raison de l'accumulation de journaux d'annulation Longueur de la liste d'historique Identifie le moment où le processus de purge InnoDB est en retard en raison de lectures de longue durée ou d'opérations de langage de manipulation de données (LMD) volumineuses. Le délai peut entraîner une augmentation de la pression de stockage et une dégradation des performances.
Blocage de la base de données causé par un conflit de moteur interne Attentes de sémaphore Utile pour diagnostiquer une base de données qui ne répond pas. Ce déclencheur peut détecter les conflits de mutex ou de verrouillage en lecture/écriture dans le moteur de stockage InnoDB, tels que les conflits d'index de hachage adaptatif (AHI) ou de pool de mémoire tampon.
Conflit de verrouillage au niveau de l'application ou requêtes non indexées Attentes de verrouillage de transaction Se déclenche lorsqu'un nombre élevé de transactions est à l'état LOCK WAIT, ce qui indique un conflit au niveau des lignes ou des transactions inactives de longue durée.
Surcharge de l'instance due à un tri ou une agrégation complexes Une utilisation élevée du processeur Capture l'état pendant une utilisation élevée : du processeur du conteneur, souvent causée par des requêtes inefficaces ou des pics de simultanéité massifs.
Risque de redémarrages en cas de mémoire insuffisante Utilisation élevée de la mémoire Vous aide à diagnostiquer des problèmes tels que des tampons par thread surdimensionnés ou des fuites de mémoire avant qu'ils n'entraînent un plantage de l'instance.
Pics de trafic soudains ou applications clientes limitées Threads en cours d'exécution Indicateur général de la charge de l'instance, utile pour identifier les pics soudains de connexions actives simultanées.
Données obsolètes sur l'instance dupliquée en raison de charges de travail d'écriture importantes Secondes de retard sur la source Surveille le délai de réplication sur les instances dupliquées avec accès en lecture pour aider à diagnostiquer les retards de synchronisation des données à partir de l'instance principale.
Requêtes de longue durée bloquant la purge Transactions de longue durée Identifie les transactions qui sont ouvertes depuis trop longtemps et qui peuvent contenir des verrous critiques. De plus, vous pouvez mettre fin automatiquement aux transactions de longue durée.

Comment les données sur les performances sont-elles capturées ?

L'enregistrement des performances fonctionne comme un service basé sur un agent qui surveille votre instance. Lorsque vous activez l'enregistrement des performances, votre instance Cloud SQL effectue les opérations suivantes pour capturer les données sur les performances :

  1. L'agent examine la configuration de votre instance pour lire les déclencheurs basés sur des seuils que vous avez définis. L'agent examine ensuite les métriques de votre instance à un intervalle configurable, probingIntervalSeconds, qui est défini sur 30 secondes par défaut.

  2. Si un problème est détecté et que le seuil d'un déclencheur a été dépassé, l'agent continue de comparer l'état en direct de l'instance à vos règles. Pour éviter les fausses alertes dues à des pics temporaires, l'agent déclenche un enregistrement complet des performances. Un enregistrement n'est déclenché que si la condition est remplie lors de sondes consécutives pour le probeThreshold configuré, qui est défini sur 3 par défaut. Ce seuil consécutif empêche les captures dues à des pics temporaires.

    Par exemple, l'agent peut déclencher un enregistrement des performances s'il détecte que le nombre de threads est élevé pour trois sondes consécutives.

    Si plusieurs conditions de déclenchement sont configurées, Cloud SQL lance une capture si l'une des conditions est remplie.

  3. Lorsqu'une capture est déclenchée, l'enregistrement des performances se connecte à la base de données et exécute une série de commandes de diagnostic pour capturer un instantané détaillé.

  4. Les informations capturées sont mises en forme dans des entrées de journal et envoyées directement à Cloud Logging du projet pour l'instance Cloud SQL sous un flux de journaux spécifique nommé mysql-performance-capture.log.

Périodes de refroidissement et de backoff adaptatif

Pour éviter une journalisation excessive et une surcharge du système, l'enregistrement des performances implémente une période de refroidissement après une capture.

Refroidissement standard

Après une capture réussie, l'enregistrement des performances démarre un refroidissement standard de 30 minutes. Pendant ce temps, l'agent ne déclenche pas de nouvelles captures, même si l'instance est dans un état de problème prolongé.

Refroidissement et backoff adaptatifs

Si une instance déclenche à plusieurs reprises des captures pour la même violation, l'enregistrement des performances utilise un mécanisme de backoff adaptatif. Ce mécanisme permet de limiter le volume de journalisation et le coût des seuils mal configurés.

Dans ce mécanisme :

  • Le refroidissement est étendu à 24 heures.
  • L'enregistrement des performances passe en mode veille, ce qui suspend toutes les vérifications de déclencheur et les captures de diagnostic.
  • L'instance est limitée à un seul enregistrement des performances par jour.

Déclencheurs d'enregistrement des performances

Cette section liste les déclencheurs disponibles pour l'enregistrement des performances MySQL. Tous les déclencheurs listés dans le tableau, sauf indication contraire, utilisent les valeurs de configuration de sonde probingIntervalSeconds et probeThreshold pour valider les conditions de déclenchement durables.

Nom de la condition de déclenchement Nom de l'API Description Valeur par défaut Plage de configuration
Une utilisation élevée du processeur
 cpuUtilizationThresholdPercent Déclenche une capture lorsque l'utilisation globale du processeur de l'instance de base de données dépasse systématiquement ce pourcentage. Cela permet de détecter la surcharge de l'instance, souvent causée par des requêtes inefficaces avec un tri et une agrégation massifs, une indexation insuffisante ou une concurrence très élevée. Pour éviter les captures sur des pics mineurs, configurez la valeur par défaut sur la plage de pourcentage la plus élevée pour votre instance. 0 (désactivé) 0, ou
10-99 (%)
Utilisation élevée de la mémoire
 memoryUsageThresholdPercent Déclenche une capture lorsque l'utilisation de la mémoire du conteneur de base de données dépasse systématiquement ce pourcentage de la mémoire allouée à l'instance. Ce déclencheur peut aider à diagnostiquer des problèmes potentiels de mémoire insuffisante, des fuites de mémoire ou une configuration de mémoire inefficace. Pour éviter la capture de pics mineurs, définissez la valeur par défaut sur la limite supérieure de la plage pour votre instance. 0 (désactivé) 0, ou
10-99 (%)
Utilisation élevée des fichiers temporaires
 Non configurable Ce déclencheur est activé automatiquement pour MySQL 8.0 et versions ultérieures. Déclenche automatiquement une capture lorsqu'il y a une augmentation significative de l'utilisation du disque à partir des fichiers temporaires créés par le processus MySQL. Souvent, les fichiers temporaires sont supprimés, mais ils restent ouverts par un processus MySQL.

Le seuil de ce déclencheur utilise un modèle d'escalade progressive pour les seuils de différence. Il commence à 100 Go et double séquentiellement jusqu'à 1,6 To après chaque refroidissement. En utilisant un modèle d'escalade progressive, l'enregistrement des performances ne se produit que si la différence d'utilisation des fichiers temporaires augmente à un niveau élevé.		 Activé n/a
Longueur de la liste d'historique
 historyListLengthThresholdCount Déclenche une capture lorsque la longueur de la liste d'historique InnoDB (HLL) dépasse la valeur configurée. Une HLL constamment élevée indique que le processus de purge InnoDB ne parvient pas à suivre et que le nombre de transactions non purgées augmente, souvent en raison de transactions de longue durée. Ce nombre élevé peut entraîner une augmentation de la consommation de stockage et des problèmes de performances.

Ce seuil dépend de la charge de travail. Certaines instances peuvent fonctionner correctement même avec une HLL constamment élevée. Toutefois, vous pouvez toujours utiliser ce déclencheur pour mettre en évidence des problèmes potentiels tels que des lectures de longue durée, des instructions de langage de manipulation de données (LMD) volumineuses ou des goulots d'étranglement de thread de purge.		 0 (désactivé) 0, ou
10000-10000000
Transactions de longue durée
 transactionDurationThreshold Une transaction est enregistrée si elle s'exécute plus longtemps que la durée configurée en secondes. Ce déclencheur est utile pour identifier les opérations qui peuvent contenir des verrous pendant des périodes excessives ou consommer des ressources trop longtemps.

Les transactions qui dépassent transactionDurationThreshold sont évaluées après chaque intervalle spécifié dans la configuration probingIntervalSeconds (30 secondes par défaut). Toutefois, pour gérer le volume de journaux, les détails de 10 de ces transactions de longue durée sont envoyés à Cloud Logging au maximum une fois par période de refroidissement (30 minutes). Le texte complet de la requête, jusqu'à 1 024 octets, provenant de INFORMATION_SCHEMA.INNODB_TRX est inclus dans chaque entrée de journal pour les 10 principales transactions.		 3600 (secondes) 60 ou plus
Erreur de thread SQL/IO
de l'instance dupliquée 		Non configurable Ce déclencheur est activé par défaut sur toutes les instances dupliquées et ne peut pas être désactivé. Déclenche immédiatement une capture si le thread SQL de réplication ou le thread IO d'une instance dupliquée rencontre une erreur et s'arrête. Ce déclencheur est essentiel pour maintenir l'intégrité de l'instance dupliquée et identifier les échecs de réplication.

Ce déclencheur n'utilise aucun paramètre de configuration de sonde tel que probingIntervalseconds ou probeThreshold pour valider les conditions d'enregistrement des performances.		 Activé n/a
Threads en cours d'exécution runningThreadsThreshold Déclenche une capture lorsque le nombre de threads actifs en cours d'exécution, basé sur la variable d'état threads_running, dépasse la valeur spécifiée. Par exemple, vous pouvez configurer le seuil pour exécuter l'enregistrement des performances si le nombre de threads actifs en cours d'exécution dépasse 100.

Ce déclencheur est requis pour l'enregistrement des performances. Si vous ne configurez pas explicitement ce déclencheur, la valeur par défaut est calculée en fonction du nombre de processeurs virtuels appartenant à l'instance.		 MIN(600, cpuCount * 20) 10 ou plus
Secondes de retard
sur la source 		secondsBehindSourceThreshold Déclenche une capture lorsque le délai de réplication sur l'instance dupliquée avec accès en lecture, mesuré en secondes, dépasse la valeur spécifiée. Vous pouvez utiliser ce déclencheur pour surveiller et diagnostiquer les retards de réplication. Ce déclencheur est activé automatiquement pour les instances dupliquées. Si vous ne configurez pas explicitement le déclencheur, la valeur par défaut est de 900 secondes. Nous vous recommandons de configurer la valeur sur la limite supérieure pour éviter les captures excessives et les refroidissements fréquents. 900 (secondes) 1 ou plus
Attentes de sémaphore semaphoreWaitThresholdCount Déclenche une capture lorsque le nombre de threads en attente sur les sémaphores InnoDB internes dépasse la valeur configurée de ce déclencheur. Cette métrique avancée indique un conflit, à l'aide d'un mutex ou d'un verrouillage en lecture/écriture, dans le moteur de stockage InnoDB lui-même. Les conflits habituels observés sont les conflits d'index de hachage adaptatif (AHI), les conflits de pool de mémoire tampon et les conflits d'E/S de disque.

Une capture est également déclenchée si le délai d'attente maximal pour un seul sémaphore dépasse 200 secondes, quelle que soit la valeur configurée de ce déclencheur.		 0 (désactivé) 0, ou
10-10000
Attentes de verrouillage de transaction
 transactionLockWaitThresholdCount Déclenche une capture lorsque le nombre de transactions à l'état LOCK WAIT dépasse le nombre configuré. Un petit nombre de transactions à l'état d'attente de verrouillage peut être normal dans un système occupé, mais un nombre constamment élevé d'attentes de verrouillage est un indicateur fort de conflit de verrouillage au niveau de l'application, de LMD non indexés, de transactions inactives de longue durée et de conflits de contenu de ligne à forte concurrence, ce qui peut dégrader considérablement les performances et le débit. 0 (désactivé) 0, ou
10-10000

Tarifs

L'enregistrement des performances est disponible dans toutes les régions Cloud SQL sans frais supplémentaires. Les frais standards ne s'appliquent qu'aux ressources de base de données sous-jacentes. L'enregistrement des performances stocke les journaux dans Cloud Logging, ce qui peut entraîner des coûts de stockage Cloud Logging supplémentaires.

Pour en savoir plus sur les tarifs de stockage des journaux dans Logging, consultez la section Tarifs.

Limites

  • Vous devez activer les insights sur les requêtes pour utiliser l'enregistrement des performances. Si vous désactivez les insights sur les requêtes, l'enregistrement des performances est également désactivé.
  • L'enregistrement des performances n'est disponible que pour Cloud SQL pour MySQL 5.7 et versions ultérieures.

Étape suivante