Tous les produits
Search

Ce produit

    ApsaraDB RDS:Utilisation élevée du processeur sur les instances ApsaraDB RDS for MySQL ou MariaDB

    Centre de documentation

    ApsaraDB RDS:Utilisation élevée du processeur sur les instances ApsaraDB RDS for MySQL ou MariaDB

    Dernière mise à jour :Sep 16, 2026

    Description du problème

    L'utilisation du CPU de votre instance ApsaraDB RDS for MySQL ou MariaDB est élevée, atteignant parfois 100 %.

    Causes

    Lorsqu'une application soumet une requête ou modifie des données, le système effectue de nombreuses lectures logiques. Ces opérations impliquent l'accès à un grand nombre de lignes dans une table. Le système utilise ensuite d'importantes ressources CPU pour maintenir la cohérence des données entre le stockage et la mémoire. Cette rubrique explique deux causes courantes d'une utilisation du CPU à 100 % ainsi que leurs solutions : une charge d'application élevée, mesurée en requêtes par seconde (QPS), et un coût élevé des requêtes dû à des instructions SQL lentes. Une utilisation élevée du CPU dans MySQL est souvent causée par des instructions SQL lentes qui accèdent à un grand nombre de lignes, ce qui entraîne un coût de requête élevé.

    Remarque

    Cette rubrique n'aborde pas l'utilisation élevée du CPU causée par des conflits de verrous de ligne, des attentes de verrouillage ou des tâches en arrière-plan. Ces problèmes surviennent rarement.

    • Charge d'application élevée (QPS élevé) :

      • Caractéristiques : L'instance présente un QPS élevé. Les requêtes sont simples et efficaces. La marge d'optimisation est faible.

      • Symptômes : Aucune requête lente ne se produit, ou les requêtes lentes ne constituent pas la cause principale. Les courbes du QPS et de l'utilisation du CPU correspondent.

      • Scénarios courants : Ce problème est fréquent dans les systèmes optimisés de traitement transactionnel en ligne (OLTP), tels que les systèmes de commande, les applications web populaires avec des taux de lecture élevés et les outils de test de charge tiers comme Sysbench.

    • Coût élevé des requêtes dû à des instructions SQL lentes (nombre élevé de lignes de données accessibles) :

      • Caractéristiques : L'instance présente un QPS faible. L'exécution des requêtes est inefficace et nécessite l'analyse de grandes quantités de données de table. Il existe une marge d'optimisation significative.

      • Symptômes : Des requêtes lentes existent. Les courbes du QPS et de l'utilisation du CPU ne correspondent pas.

      • Analyse des causes : Les requêtes inefficaces doivent accéder à de grandes quantités de données pour récupérer les résultats attendus. Cela entraîne une entrée/sortie logique moyenne élevée. Par conséquent, l'utilisation du CPU peut être élevée même lorsque le QPS est faible, comme sur un site web à faible trafic.

    Solutions

    Choisissez une solution en fonction de votre situation spécifique.

    Charge d'application élevée (QPS élevé)

    Si une utilisation élevée du CPU est causée par une charge d'application élevée, la marge d'optimisation SQL est faible. Résolvez le problème en ajustant l'architecture de l'application ou le type d'instance. Envisagez les méthodes suivantes :

    • Mettez à niveau le type d'instance pour ajouter davantage de ressources CPU. Pour plus d'informations, consultez Modifier les configurations d'instance.

    • Ajoutez des instances en lecture seule. Transférez les requêtes non sensibles à la cohérence des données, telles que les requêtes de catégories de produits ou d'horaires de train, vers les instances en lecture seule. Cela réduit la charge sur l'instance principale. Pour plus d'informations, consultez Créer une instance en lecture seule ApsaraDB RDS for MySQL.

    • Utilisez PolarDB-X, une base de données distribuée cloud-native d'Alibaba Cloud. Elle effectue automatiquement le sharding pour distribuer la charge des requêtes sur plusieurs instances RDS.

    • Utilisez Alibaba Cloud Memcache ou Tair (compatible OSS Redis). Récupérez les résultats de requête fréquemment utilisés depuis le cache pour réduire la charge sur l'instance RDS.

    • Pour les applications qui interrogent des données relativement statiques, présentent une répétition élevée des requêtes et dont les ensembles de résultats sont inférieurs à 1 Mo, envisagez d'activer le cache de requêtes.

      Remarque

      Testez si l'activation du cache de requêtes est bénéfique pour votre application. Pour plus d'informations sur les paramètres, consultez Définir et utiliser le cache de requêtes pour ApsaraDB RDS for MySQL.

    • Archivez périodiquement les données historiques. Utilisez le sharding ou le partitionnement pour réduire la quantité de données accessibles par les requêtes. Optimisez les requêtes pour réduire les coûts d'exécution et améliorer l'évolutivité de l'application.

    Coût élevé des requêtes dû à des instructions SQL lentes

    Pour résoudre ce problème, identifiez les requêtes inefficaces, optimisez leur efficacité d'exécution et réduisez leurs coûts d'exécution.

    1. Identifiez les requêtes inefficaces de la manière suivante :

      • Exécutez l'instruction SQL suivante pour afficher les requêtes en cours d'exécution.

        show processlist;
show full processlist;

        Le système affiche une sortie similaire à la suivante :

        mysql> show processlist;
+----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
| Id       | User  | Host              | db      | Command | Time  | State        | Info                                         |
+----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
|101031643 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|117731567 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|134298793 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|134384670 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   |     0 | Init         | show processlist                             |
|234891284 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235125098 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235200576 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235633985 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235887773 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|251990394 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|252662718 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
+----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
11 rows in set (0.00 sec)

        Les sessions de requête qui s'exécutent pendant une longue période et dont l'état est Sending data, Copying to tmp table, Copying to tmp table on disk, Sorting result ou Using filesort peuvent présenter des problèmes de performance.

        • Dans les scénarios où un QPS élevé provoque une utilisation élevée du CPU, les requêtes s'exécutent souvent rapidement. Cela peut rendre difficile leur capture avec la commande show processlist; ou en affichant les sessions de l'instance. Dans ce cas, exécutez l'instruction SQL suivante :

          explain [$SQL]
          Remarque

          [$SQL] est la requête SQL qui présente des problèmes de performance.

        • Exécutez une commande telle que kill [$ID]; pour arrêter une session s'exécutant depuis longtemps. Pour plus d'informations sur l'arrêt des sessions, consultez Comment arrêter les sessions sur une instance ApsaraDB RDS for MySQL.

          Remarque

          [$ID] est l'ID de session correspondant à la requête.

      • Affichez les requêtes en cours d'exécution à l'aide de Database Autonomy Service (DAS) :

        1. Connectez-vous à la console DAS.

        2. Dans le volet de navigation de gauche, cliquez sur Intelligent O&M Center > Instance Monitoring .

        3. Recherchez l'instance cible et cliquez sur son ID pour ouvrir la page des détails de l'instance.

        4. Dans le volet de navigation de gauche, cliquez sur Instance Sessions.

        5. Cliquez sur le texte de la requête dans la colonne SQL pour afficher la requête complète et son plan d'exécution.

    2. Après avoir identifié les requêtes nécessitant une optimisation, utilisez SQL Diagnostics dans la console DMS pour obtenir des suggestions d'optimisation. Le rapport de diagnostic est également utile pour le dépannage des problèmes historiques d'utilisation élevée du CPU :

      1. Connectez-vous à l'instance dans la console DMS. Pour plus d'informations, consultez Se connecter à une instance de base de données.

      2. En haut de la page, cliquez sur SQL Window et sélectionnez la base de données cible.

      3. Collez la requête dans la fenêtre SQL et cliquez sur SQL Diagnostics pour obtenir des suggestions d'optimisation.

    3. Suivez les suggestions d'optimisation selon vos besoins. Par exemple, l'ajout d'un index peut réduire considérablement les coûts d'exécution des requêtes.

    Informations complémentaires

    Fonctionnalités de dépannage des problèmes de performance

    Data Management (DMS) propose plusieurs fonctionnalités pour vous aider à diagnostiquer et résoudre les problèmes de performance des instances. Le rapport de diagnostic est le meilleur outil pour le dépannage des problèmes de performance sur les instances MySQL et MariaDB. Quelle qu'en soit la cause, vérifiez d'abord le rapport de diagnostic. Accordez une attention particulière aux sections d'optimisation SQL, de liste des sessions et de résumé des SQL lents.

    Principes pour éviter une utilisation du CPU à 100 %

    Suivez ces principes pour éviter une utilisation du CPU à 100 % :

    • Définissez des alertes d'utilisation du CPU pour garantir que votre instance dispose d'une marge CPU suffisante.

    • Lors de la conception et du développement de l'application, prenez en compte l'optimisation des requêtes. Suivez les principes généraux d'optimisation pour MySQL afin de réduire les E/S logiques et d'améliorer l'évolutivité de l'application.

    • Avant la mise en ligne d'une nouvelle fonctionnalité ou d'un nouveau module, effectuez des tests de charge avec des données de production .

    • Avant la mise en ligne d'une nouvelle fonctionnalité ou d'un nouveau module, effectuez des tests de régression avec des données de production.

    Algorithme des ressources système

    Le modèle simplifié suivant explique la relation entre les ressources système, les coûts d'exécution des instructions SQL et les requêtes par seconde (QPS) :

    • Condition : Le modèle d'application est constant, ce qui signifie que l'application n'est pas modifiée.

    • avg_lgc_io : L'E/S logique moyen requis pour exécuter chaque requête.

    • total_lgc_io : Le total des E/S logiques que les ressources CPU de l'instance peuvent traiter par unité de temps.

    • Formule : total_lgc_io = avg_lgc_io × QPS. Cela signifie Total CPU resources per unit of time = Average logical I/O per query × Number of queries per unit of time.

    Références

    Résoudre une utilisation élevée du CPU sur une instance ApsaraDB RDS for MySQL à l'aide du service d'autonomie

    Versions applicables

    • ApsaraDB RDS for MySQL

    • ApsaraDB RDS for MariaDB