AnalyticDB:Tune cluster performance with monitoring information

Utilisation moyenne élevée du CPU

La métrique d'utilisation moyenne du CPU indique la consommation moyenne du processeur sur plusieurs nœuds à un instant donné. Une utilisation moyenne élevée peut compromettre la stabilité du cluster et ralentir les requêtes ainsi que les opérations d'écriture. Si cette utilisation reste élevée, elle présente un risque significatif pour votre cluster et nécessite une optimisation immédiate.

Les causes courantes d'une utilisation moyenne élevée du CPU incluent :

• Requêtes

  Une utilisation élevée du CPU lors des requêtes peut résulter d'instructions SQL mal optimisées, telles que des requêtes avec une logique de calcul complexe, de grands volumes de données à traiter ou des jointures (JOIN) sans conditions générant un produit cartésien. Utilisez la fonctionnalité de diagnostics pour identifier les requêtes problématiques :

  • Dans les résultats de détection des instructions SQL inefficaces, les requêtes qui s'exécutent pendant longtemps, lisent de grandes quantités de données, comportent de nombreuses étapes ou sont intensives en CPU peuvent entraîner une utilisation élevée du processeur du cluster. Ces requêtes nécessitent une analyse approfondie basée sur les résultats du diagnostic ou le plan d'exécution.

  • La fonction de détection des modèles anormaux identifie les schémas de soumission inhabituels du point de vue des modèles SQL. À l'instar des instructions SQL inefficaces, les modèles provoquant une utilisation élevée du CPU doivent être analysés en tenant compte de facteurs tels qu'un volume de lecture de données anormal, une consommation CPU élevée et des durées d'exécution inhabituelles. Ces modèles anormaux peuvent augmenter l'utilisation du CPU.

  • Si vous observez une utilisation élevée du CPU sur les nœuds de calcul ou de stockage, vous pouvez analyser le problème à l'aide des résultats de détection de la couche de calcul et de la couche de stockage fournis par la fonction de diagnostics. La fonction de détection des opérateurs anormaux utilise les détails et les résumés des opérateurs pour filtrer et identifier ceux qui consomment excessivement le CPU.

• Écritures

  Les opérations d'écriture (y compris INSERT, UPDATE, DELETE, REPLACE, INSERT OVERWRITE et INSERT INTO SELECT) consomment également des ressources CPU et peuvent entraîner une utilisation élevée du processeur sur les nœuds de stockage. Dans ce cas, vérifiez si les métriques de surveillance telles que le TPS de suppression, le TPS d'écriture, le TPS de mise à jour et le TPS de chargement affichent également une augmentation soudaine.

  Les causes courantes d'une utilisation élevée du CPU due aux écritures incluent :

  • Clés primaires longues

    Lorsqu'une clé primaire est très longue, l'index de clé primaire devient volumineux et consomme davantage de ressources CPU lors du traitement des requêtes.

  • Instruction DELETE SQL

    Si une seule instruction DELETE WHERE correspond à de nombreuses lignes, le moteur de calcul doit calculer les clés primaires de toutes les lignes correspondantes, puis les envoyer individuellement aux nœuds de stockage pour suppression. Une seule opération DELETE SQL peut ainsi être amplifiée de manière significative, entraînant une utilisation élevée du CPU.

  • Instruction UPDATE SQL

    Si une seule instruction UPDATE WHERE correspond à de nombreuses lignes, le moteur de calcul doit trouver les clés primaires de toutes les lignes concernées, mettre à jour les valeurs de leurs champs correspondants, puis envoyer les modifications aux nœuds de stockage pour marquer les anciennes lignes comme supprimées et ajouter les nouvelles. Une seule opération UPDATE SQL peut être considérablement amplifiée, ce qui se traduit par une utilisation élevée du CPU.

  • INSERT OVERWRITE

    Un chargement par lots effectue des opérations intensives en CPU telles que l'analyse des données, le tri par champs d'index clusterisé (si un index clusterisé existe) et la construction d'index de clés primaires et d'index standard, chaque shard nécessitant un thread dédié pour ces tâches. Bien qu'il existe une limite sur le nombre d'opérations de chargement par lots concurrentes (par exemple, un maximum de deux requêtes SQL de chargement par lots simultanées), l'utilisation du CPU peut toujours devenir élevée car chaque shard a besoin d'un thread dédié pour effectuer ces travaux.

  • INSERT INTO SELECT

    Lorsqu'une grande quantité de données est écrite en peu de temps, les tâches BUILD en arrière-plan peuvent s'accumuler, entraînant une augmentation des données en temps réel. Si une requête implique ces données en temps réel, la base de données doit en scanner un grand volume, car les données en temps réel ne sont pas indexées. Cela conduit à une utilisation élevée du CPU.

• Build

  Une tâche BUILD exécute des actions telles que la construction d'index et la création ou la suppression de partitions. Ces tâches peuvent provoquer une utilisation élevée du CPU sur les nœuds de stockage. Vous pouvez comparer l'utilisation du CPU et le nombre de tâches BUILD dans la console pour identifier la corrélation entre ces deux métriques.

  Remarque

  • Pour plus d'informations sur BUILD, consultez la rubrique BUILD.

  • Pour savoir comment localiser et analyser une utilisation élevée des ressources causée par les tâches BUILD, consultez la section Augmentation du nombre de tâches BUILD.

Déséquilibre de l'utilisation du CPU

La métrique d'utilisation maximale du CPU représente l'utilisation du processeur du nœud le plus sollicité à un instant donné. Un écart important et persistant entre l'utilisation maximale et moyenne du CPU indique une répartition inégale des tâches au sein du cluster, entraînant un déséquilibre de l'utilisation du CPU. Cela signifie que certains nœuds sont fortement chargés tandis que d'autres le sont peu. Un déséquilibre sévère (par exemple, une différence supérieure à 2 fois) peut avoir un impact significatif sur la stabilité du cluster et gaspiller des ressources. En effet, les sous-tâches de requête distribuées sont limitées par le nœud ayant l'utilisation du CPU la plus élevée, ce qui empêche toute amélioration supplémentaire des performances. Souvent, la seule solution consiste à augmenter la capacité du cluster, même si les autres nœuds ne sont pas fortement utilisés.

Les causes possibles d'un déséquilibre de l'utilisation du CPU sont les suivantes :

• Déséquilibre de la table source

  Cela se produit généralement lorsque la clé de distribution choisie lors de la création de la table n'est pas uniforme, provoquant des différences significatives dans la quantité de données entre les shards.

  Comme illustré dans la figure suivante, une grande table est distribuée de manière inégale. Shard_0 et Shard_1 sur le nœud de stockage 0 contiennent une grande quantité de données, tandis que Shard_2 et Shard_3 sur le nœud de stockage 1 en contiennent moins. Lorsque vous interrogez cette table, le nœud de stockage 0 traitera probablement plus de données que le nœud de stockage 1. Cela entraîne une utilisation du CPU du nœud de stockage 0 persistamment plus élevée que celle du nœud de stockage 1, provoquant ainsi un déséquilibre de l'utilisation du CPU.

  

  Pour savoir comment diagnostiquer le déséquilibre de la table source, consultez la rubrique Diagnostics de stockage. La fonction de diagnostics détecte également les tables déséquilibrées qui occupent de grands espaces disque afin de vous aider à analyser le déséquilibre des ressources.

• Déséquilibre des données intermédiaires

  Le déséquilibre des données intermédiaires diffère de celui de la table source. Dans ce scénario, les données de la table source peuvent être uniformément réparties entre les shards, mais la distribution des valeurs d'un champ spécifique n'est pas uniforme.

  Lorsque vous effectuez une requête d'agrégation group-by ou utilisez un champ distribué de manière inégale comme condition de jointure (JOIN), AnalyticDB for MySQL redistribue les données sur différents nœuds en fonction de ce champ. Après redistribution, les données ayant la même valeur de champ sont envoyées au même nœud, ce qui peut provoquer un déséquilibre des données.

  Comme illustré dans la figure suivante, une table est distribuée par le champ « a ». Étant donné que les valeurs du champ « a » sont uniformes, les données sont réparties équitablement sur les nœuds de stockage. Cependant, lorsque vous effectuez un regroupement par le champ « b » (group by b), le nœud de stockage 1 envoie les lignes où « b » vaut « b1 » au nœud de calcul 1. Pour garantir que le nœud de calcul 1 dispose de toutes les lignes où « b » vaut « b1 », le nœud de stockage 2 lui envoie également ses lignes « b1 », tout en envoyant les lignes « b2 » au nœud de calcul 2. Par conséquent, le nœud de calcul 1 reçoit beaucoup plus de lignes que le nœud de calcul 2, créant ainsi un déséquilibre des données. Pour les calculs suivants, le nœud de calcul 1 consommera davantage de ressources du cluster.

  

  Pour résoudre les problèmes d'utilisation inégale du CPU causés par le déséquilibre des données intermédiaires, vous pouvez analyser les résultats du diagnostic au niveau des étapes de la requête afin d'identifier le problème.

Utilisation maximale élevée et utilisation moyenne modérée du CPU

Taille importante des résultats de requête

Cause : Une seule requête SQL renvoyant un très grand volume de données peut augmenter l'utilisation du CPU des nœuds d'accès.

Solution : Ajoutez des conditions de requête plus précises pour réduire la portée de la recherche et diminuer la quantité de données renvoyées. Vous pouvez également utiliser des requêtes paginées pour éviter de charger trop de contenu en une seule fois. Si vous devez exporter un grand volume de données, utilisez des tables externes.

Utilisation élevée du CPU par l'optimiseur

Cause : Lorsque le nombre de requêtes par seconde (QPS) du cluster est élevé et que les instructions SQL sont complexes, l'optimiseur peut consommer une grande quantité de ressources CPU.

Solution : Commencez par activer le cache de plan. Après l'activation, observez si l'utilisation du CPU diminue de manière significative. Si ce n'est pas le cas, soumettez un ticket pour obtenir une assistance technique.

Écritures impliquant des champs longs

Cause : Lorsqu'une table subit des écritures impliquant des champs longs, les nœuds d'accès consomment davantage de ressources pour traiter ces champs, ce qui entraîne une utilisation élevée du CPU.

Solution : Exécutez l'instruction suivante pour vérifier la présence de tables avec des écritures de champs longs. Si des tables sont identifiées, optimisez la logique métier associée en limitant la longueur des champs ou en fractionnant les champs longs.

SELECT *
FROM 
    (SELECT schema_name,
        table_name,
        column_name,
         cast(json_extract(stats,
        '$.avgSize') AS bigint) AS avg_size
    FROM INFORMATION_SCHEMA.COLUMN_STATISTICS ) tmp
ORDER BY  avg_size DESC limit 20;

Débit E/S disque élevé

Le débit des opérations d'E/S disque représente le débit du support de stockage sous-jacent, mesuré en Mo/s. Pour connaître la valeur maximale, consultez la documentation relative aux ESSD. Cette limite supérieure est une valeur théorique obtenue lors de tests effectués dans des conditions idéales ; elle ne reflète pas nécessairement la charge réelle du cluster. En général, la charge effective peut atteindre environ 80 % de cette valeur nominale.

IOPS disque élevés

Les IOPS disque indiquent le nombre d'opérations d'E/S par seconde sur le support de stockage sous-jacent. Pour connaître la valeur maximale des IOPS disque, consultez la documentation relative aux ESSD. Cette limite supérieure est une valeur théorique obtenue lors de tests effectués dans des conditions idéales ; elle ne reflète pas nécessairement la charge réelle du cluster. En général, la charge effective peut atteindre environ 80 % de cette valeur nominale.

Utilisation élevée de la mémoire de calcul

Les bases de données analytiques consomment d'importantes ressources mémoire lors de l'exécution de calculs de données à grande échelle. Les requêtes SQL gourmandes en mémoire incluent généralement les opérateurs d'agrégation, TopN, de fenêtrage et de jointure :

• Opérateur d'agrégation

  Un opérateur d'agrégation consomme beaucoup de mémoire principalement parce que AnalyticDB for MySQL stocke temporairement les informations de regroupement en mémoire. Si le champ de regroupement comporte de nombreuses valeurs uniques, une grande quantité de mémoire est consommée lors de la phase finale de l'agrégation distribuée. La phase partielle consomme moins de mémoire, car elle ne nécessite pas d'agrégation globale ; chaque nœud peut envoyer les données aux nœuds en aval après avoir terminé l'agrégation locale sur un sous-ensemble de données.

• Opérateur TopN

  Lorsque AnalyticDB for MySQL effectue un calcul TopN (par exemple, dans une requête SQL contenant ORDER BY id LIMIT m,n), l'opérateur TopN dans AnalyticDB for MySQL met en cache une grande quantité de données en mémoire pour effectuer le tri global final si la valeur de m est élevée. Ce processus consomme d'importantes ressources mémoire.

• Opérateur de fenêtrage

  Un opérateur de fenêtrage est utilisé pour calculer les fonctions de fenêtrage. À l'instar d'un opérateur d'agrégation, il doit stocker temporairement une grande quantité de données en mémoire pour obtenir le résultat sémantique final.

• Opérateur de jointure

  AnalyticDB for MySQL prend en charge les opérations de requête JOIN standard. Le système utilise généralement des algorithmes de hachage et d'index pour implémenter le processus de jointure. Pour plus d'informations, consultez la section Opérateurs. L'algorithme de hachage met en cache la table la plus petite (table de construction) en mémoire et construit une table de hachage pour accélérer le processus de jointure. Les facteurs suivants peuvent entraîner une occupation importante de la mémoire par la table de hachage :

  • La table de construction elle-même est volumineuse :

    AnalyticDB for MySQL utilise des statistiques pour estimer la taille des tables des deux côtés d'une opération JOIN et choisit la plus petite comme table de construction. Il reste toutefois possible que la table de construction soit volumineuse.

  • Statistiques obsolètes ou inexactes :

    Si les tables impliquées dans une opération JOIN ne sont pas des tables source, mais résultent de plusieurs agrégations, filtres ou autres jointures, il est difficile d'estimer avec précision leurs tailles à partir des statistiques des tables source. De plus, si les statistiques sont obsolètes, une table plus grande peut être incorrectement sélectionnée comme table de construction et utilisée pour construire la table de hachage. Pour plus d'informations, consultez la section Statistiques.

  • Left Join :

    En raison des exigences sémantiques, la table de droite d'une LEFT JOIN doit être utilisée pour construire la table de hachage afin de garantir l'exactitude du résultat. Si la table de droite d'une LEFT JOIN est volumineuse, l'opération de jointure consommera une grande quantité de mémoire.

Pour plus d'informations sur ces opérateurs, consultez la section Opérateurs.

Lorsque la concurrence des requêtes SQL contenant ces opérateurs est élevée, ou lorsqu'un seul opérateur consomme une grande quantité de mémoire, la métrique d'utilisation de la mémoire de calcul augmente. Cela peut affecter la stabilité du cluster et provoquer des erreurs de requête. Les erreurs courantes incluent :

• Query exceeded reserved memory limit : une requête a utilisé plus de mémoire que la limite autorisée sur un seul nœud.

• Query exceeded system memory pool limit : un seul champ est trop long ou trop de colonnes sont impliquées dans le calcul.

• Out of Memory Pool size pre cal. available : le pool de mémoire physique est épuisé.

• The cluster is out of memory, and your query was killed : lorsque le cluster manque de mémoire, il termine la plus grande requête en cours d'exécution.

Pour réduire l'utilisation de la mémoire de calcul, optimisez les requêtes SQL contenant ces types d'opérateurs. Pour des instructions détaillées, consultez la section Résultats de diagnostic au niveau des opérateurs.

Augmentation du nombre de jobs BUILD

Un job BUILD sert principalement à construire des index pour les données écrites, à nettoyer les données expirées et à exécuter des tâches DDL asynchrones. Ce processus transforme les données d'un état optimisé pour l'écriture vers un état optimisé pour la lecture. Dans certains cas, les jobs BUILD peuvent consommer d'importantes ressources CPU et E/S disque sur les nœuds de stockage, ce qui peut affecter d'autres opérations et entraîner des problèmes de stabilité du cluster. Le tableau suivant décrit les métriques BUILD.

Si une augmentation du nombre de jobs BUILD affecte l'utilisation du CPU des nœuds de lecture/écriture, vous pouvez investiguer et analyser le problème selon les axes suivants :

• Partitions uniques de grande taille dans les tables partitionnées. Lorsqu'une partition unique est volumineuse, elle est plus susceptible d'être écrite, mise à jour ou supprimée, ce qui déclenche plus facilement un BUILD sur cette partition. Utilisez les diagnostics de stockage pour localiser ce type de tables et optimiser leur structure.

• Les tables non partitionnées très volumineuses constituent également une cause fréquente. Lorsqu'une table non partitionnée est grande, elle est aussi plus susceptible d'être impliquée dans des écritures, des mises à jour ou des suppressions, ce qui peut facilement déclencher un BUILD sur l'ensemble de la table.

• Un grand nombre de requêtes de lecture et d'écriture entraîne une utilisation soutenue et élevée du CPU sur les nœuds de stockage, ce qui ralentit à son tour l'exécution des jobs BUILD.

Augmentation du nombre de nœuds hors ligne

Lorsque des nœuds au sein d'un cluster AnalyticDB for MySQL deviennent indisponibles, ils passent hors ligne. Les pannes de nœuds dégradent la stabilité du cluster, ralentissant les requêtes et les écritures, et provoquant des erreurs de requête. Lorsqu'un nœud passe hors ligne, analysez si l'utilisation du CPU reste persistamment élevée ou si les métriques liées aux E/S atteignent constamment leurs limites.

Courbes P95

AnalyticDB for MySQL fournit des courbes de surveillance P95 pour des métriques telles que l'utilisation du CPU, l'utilisation du CPU des nœuds d'accès, l'utilisation de la mémoire de calcul, le débit E/S disque, les IOPS disque, l'utilisation des E/S disque et le temps d'attente des E/S disque. La métrique P95 représente la valeur en dessous de laquelle se situent 95 % des observations. Par exemple, prenons l'utilisation du CPU des nœuds de calcul. Si un cluster compte 100 nœuds de calcul, l'utilisation du CPU de tous les nœuds est triée par ordre croissant à un instant donné. L'utilisation du CPU du 95e nœud correspond à l'utilisation P95 du CPU pour les nœuds de calcul.

Les différences entre les valeurs maximales, moyennes et P95 sont les suivantes :

• La valeur maximale indique simplement la limite supérieure des données. En présence de valeurs aberrantes ou extrêmes, la valeur maximale d'une métrique de surveillance peut être influencée par ces points individuels et ne pas représenter avec exactitude l'état général ou typique de l'ensemble de données.

• La valeur moyenne vise à décrire la tendance centrale des données, mais elle peut ne pas refléter avec exactité l'état général si l'ensemble de données contient des valeurs aberrantes ou présente une distribution asymétrique.

• La valeur P95 se concentre sur les performances de la partie supérieure des données tout en ignorant les points de données les plus extrêmes. Elle convient pour évaluer les performances ou les niveaux dans la plupart des situations.

Augmentation du temps de réponse des requêtes

La métrique de temps de réponse des requêtes représente la durée écoulée entre la soumission d'une requête, en passant par la mise en file d'attente, et l'achèvement de son exécution. Pour plus d'informations sur le temps d'exécution dans AnalyticDB for MySQL, consultez la rubrique FAQ sur la surveillance.

Une augmentation soudaine du temps de réponse des requêtes du cluster peut être provoquée par les facteurs suivants :

• Requêtes SQL non optimisées

  Les requêtes SQL non optimisées consomment une grande quantité de ressources du cluster, ce qui affecte l'exécution des autres requêtes SQL.

• Modèles anormaux

  Les modèles anormaux peuvent se manifester de deux manières : soit une requête à faible consommation de ressources est exécutée avec une très haute fréquence, soit une requête à forte consommation de ressources crée un goulot d'étranglement pour l'ensemble du cluster. Cela finit par affecter les autres requêtes et augmente le temps de réponse global des requêtes.

• Augmentation du volume d'écriture

  Une augmentation du volume d'écriture consomme davantage de ressources CPU et d'E/S disque, déclenche davantage de tâches BUILD et conduit finalement à une augmentation du temps de réponse global des requêtes.

Sur la page Monitoring Information de la console, vous pouvez sélectionner la plage horaire pendant laquelle le temps de réponse des requêtes a augmenté et exécuter des diagnostics pour analyser la cause spécifique en fonction des différents résultats de diagnostic.

Augmentation du temps d'attente des requêtes

Lorsqu'une requête est soumise à un nœud d'accès, le cluster détermine s'il faut mettre la requête en file d'attente en fonction des paramètres de taille de la file d'attente de la couche d'accès. Cette mesure permet d'éviter qu'un trop grand nombre de requêtes SQL ne s'exécute simultanément, ce qui pourrait accroître la pression sur le cluster et affecter sa stabilité globale. Pour plus d'informations, consultez la rubrique Contrôle de la concurrence.

Une augmentation soudaine du temps d'attente des requêtes est généralement causée par une diminution de l'efficacité d'exécution interne du cluster. Cela peut être dû à des requêtes SQL non optimisées ou à des modèles anormaux consommant une grande quantité de ressources du cluster. Vous pouvez utiliser les diagnostics pour vérifier les résultats de détection multidimensionnelle des requêtes SQL non optimisées et des modèles anormaux. Une augmentation du volume de données écrites, qui consomme davantage de ressources CPU et d'E/S sur les nœuds de stockage, peut également entraîner des temps d'attente des requêtes plus longs.

Augmentation du taux d'échec des requêtes

La métrique de taux d'échec des requêtes ne comptabilise que la proportion de requêtes ayant échoué et n'indique pas les raisons de l'échec. Les échecs de requête peuvent avoir plusieurs causes. Les causes courantes et leurs solutions sont les suivantes :

• Échec de la requête dû à des problèmes liés à l'instruction SQL

  • Erreur de syntaxe

    L'instruction SQL n'est pas conforme à la syntaxe SQL définie par AnalyticDB for MySQL. Une erreur est généralement signalée lors de l'étape d'analyse de la requête SQL. Les exemples incluent des instructions SQL incomplètes, un formatage incorrect et des mots-clés ou une ponctuation manquants.

  • Erreur sémantique

    L'instruction SQL est conforme à la syntaxe SQL définie par AnalyticDB for MySQL, mais une erreur concernant un objet de base de données est détectée lors de la vérification sémantique. Une erreur est signalée lors de l'étape d'analyse sémantique. Les exemples incluent un nom de table incorrect, une colonne inexistante, un champ GROUP BY manquant ou un type de paramètre de fonction incorrect.

• Échec de la requête dû à des problèmes internes au cluster

  • Délai d'expiration de la requête

    AnalyticDB for MySQL dispose d'un délai d'expiration de requête par défaut. Vous pouvez également configurer un délai d'expiration de requête en fonction de vos besoins métier. Si le temps d'exécution d'une requête dépasse cette limite, la requête échoue.

    Remarque

    • Pour obtenir des informations sur le délai d'expiration de requête par défaut, consultez la rubrique Limites.

    • Pour savoir comment modifier le délai d'expiration de la requête, consultez la rubrique Paramètres de configuration Config et Hint.

  • Forte pression sur le cluster

    Lorsque le cluster subit une forte pression, des délais d'expiration de communication entre les nœuds internes ou des défaillances de processus internes peuvent provoquer des échecs de requête.

• Lecture seule

  Lorsque le système détecte un problème avec le journal Raft, il définit immédiatement l'état du processus en lecture seule. Dans cet état, les opérations d'écriture échoueront.

• Délai d'expiration

  Si le système ne parvient pas à consommer la file d'attente du journal Raft à temps (par exemple, en raison d'écritures lentes causées par des clés primaires longues), une contre-pression se produit, ce qui ralentit finalement la vitesse d'écriture et provoque des erreurs de délai d'expiration.

Quantité de données lues à partir des tables

Dans AnalyticDB for MySQL, les données sont stockées sur différents nœuds de stockage. La métrique Quantité de données lues à partir des tables indique le volume total de données renvoyé de la couche de stockage vers la couche de calcul par toutes les requêtes SQL à un instant donné.

Comme illustré dans la figure suivante, à un instant donné (Time_1), 6 requêtes SQL (query1, query2, query3, query4, query5 et query6) lisent des données à partir de 6 tables (user, report, customer, test, region et partition). À cet instant, la quantité totale de données lues à partir des tables est de 20.1 GB (calculée comme suit : 1.6 + 2 + 3 + 0.7 + 4.8 + 8 = 20.1 GB). La quantité moyenne de données lues à partir des tables est de 6.7 GB (calculée comme suit : total data read from all storage nodes / number of storage nodes, soit (1.6 + 2 + 3 + 0.7 + 4.8 + 8) / 3 = 6.7 GB). La quantité maximale de données lues à partir des tables est de 12.8 GB (calculée comme suit : 4.8 + 8 = 12.8 GB).

Les quantités totales, maximales et moyennes de données lues à partir des tables peuvent refléter dans une certaine mesure la pression exercée par les requêtes SQL sur le cluster.

• Lorsque la quantité moyenne de données lues à partir des tables augmente soudainement, cela indique qu'une grande quantité de données est envoyée de la couche de stockage vers la couche de calcul pour traitement, ce qui consomme davantage de ressources CPU et mémoire. Parallèlement, l'augmentation du volume de données lues depuis la couche de stockage consomme également davantage de ressources d'E/S disque.

• Lorsqu'il existe une grande différence entre les quantités maximales et moyennes de données lues à partir des tables, cela indique que le volume de données lu varie selon les nœuds de stockage. Cette différence de charge de traitement des données peut amener certains nœuds à atteindre prématurément leurs goulots d'étranglement en matière de ressources, ce qui affecte à son tour les performances globales du cluster. Cette situation est souvent due à une conception de table sous-optimale, telle que le choix d'une clé de distribution inégale pour certaines tables, entraînant une répartition inégale des données sur plusieurs nœuds de stockage.

Augmentation des temps de réponse pour les écritures, suppressions et mises à jour

Les métriques de temps de réponse en écriture, en suppression et en mise à jour indiquent le temps nécessaire pour traiter chaque ligne pour les opérations INSERT INTO VALUES, DELETE et UPDATE, respectivement. Les temps de réponse sont généralement influencés par les facteurs suivants :

• Utilisation élevée du CPU sur les nœuds de stockage

  Cela peut être causé par d'autres facteurs, tels que des requêtes SQL non optimisées ou une augmentation du TPS (transactions par seconde) pour les écritures, suppressions ou mises à jour.

• Métriques d'E/S liées à l'écriture élevées sur les nœuds de stockage

  Les métriques d'E/S liées à l'écriture sur les nœuds de stockage incluent le débit d'E/S disque et les IOPS disque. Ces métriques peuvent augmenter pour les raisons suivantes :

  • Une augmentation du nombre de tâches BUILD.

  • Le système a effectué des opérations de sauvegarde ou de mise à l'échelle.

  Étant donné que ces opérations nécessitent toutes des écritures sur disque, elles peuvent affecter les temps de réponse correspondants.

  Si les temps de réponse en écriture continuent d'augmenter pendant le traitement des données, nous vous recommandons de planifier les tâches de traitement de données à grande échelle pendant les heures creuses et de limiter le nombre de tâches d'écriture simultanées afin de réduire la pression sur les E/S disque.