Hologres:Monitoring metrics

Utilisation du CPU de l'instance (%)

Charge globale du CPU de l'instance.

Les processus d'arrière-plan et les tâches de compactage consomment du CPU même en l'absence de requêtes actives ; une utilisation à l'état inactif est donc normale. Hologres utilise le parallélisme multicœur, ce qui signifie qu'une seule requête peut porter l'utilisation du CPU à 100 %. Cela indique une utilisation complète des ressources et ne constitue pas nécessairement un problème.

Quand investiguer : Si l'utilisation du CPU reste proche de 100 % pendant 3 heures ou supérieure à 90 % pendant 12 heures, l'instance est fortement sollicitée et le CPU constitue probablement le goulot d'étranglement. Vérifiez si :

• Des imports de données hors ligne volumineux (INSERT) sont en cours d'exécution avec des volumes de données croissants.

• Des requêtes ou des écritures à fort QPS consomment toutes les ressources du CPU.

• Des charges de travail hybrides combinent les scénarios ci-dessus.

Si une utilisation élevée et soutenue du CPU est prévue, augmentez la taille de l'instance.

FAQ sur les métriques de surveillance.

Utilisation du CPU des nœuds Worker (%)

Charge du CPU sur chaque nœud Worker. Le nombre de nœuds Worker varie selon le type d'instance. Pour plus d'informations, consultez la section Gestion des instances.

Version : V1.1+

• Si tous les nœuds Worker affichent une utilisation soutenue du CPU proche de 100 %, l'instance est fortement sollicitée. Optimisez les requêtes ou augmentez la taille de l'instance.

• Si seuls certains nœuds Worker affichent une utilisation élevée du CPU, un déséquilibre des ressources existe. Pour connaître les causes courantes et les étapes de dépannage, consultez la section FAQ sur les métriques de surveillance.

Utilisation du CPU du cluster (%)

Utilisation du CPU de chaque Cluster dans le groupe de calcul.

Version : V4.0+. Instances de groupe de calcul uniquement.

Utilisation de la mémoire de l'instance (%)

La consommation globale de mémoire de l'instance.

Hologres réserve de la mémoire pour les métadonnées, les index et les caches afin d'accélérer les requêtes. Une utilisation inactive de 30 % à 40 % est typique. Si l'utilisation approche les 80 %, la mémoire peut devenir un goulot d'étranglement.

Utilisez les métriques de répartition de la mémoire conjointement avec le QPS et d'autres indicateurs pour identifier les consommateurs élevés de mémoire. Consultez le Guide de dépannage des problèmes de mémoire insuffisante.

Utilisation de la mémoire du nœud Worker (%)

La charge mémoire sur chaque nœud Worker. Le nombre de nœuds Worker varie selon le type d'instance. Pour plus d'informations, consultez la rubrique Gestion des instances.

Version : V1.1+

• Si tous les nœuds Worker affichent une utilisation de la mémoire soutenue proche de 80 %, l'instance est fortement sollicitée. Optimisez les requêtes ou augmentez la capacité de l'instance.

• Si seuls certains nœuds Worker présentent une utilisation élevée de la mémoire, un déséquilibre des ressources existe. Pour connaître les causes courantes et les solutions de dépannage, consultez la rubrique FAQ sur les métriques de surveillance.

Utilisation détaillée de la mémoire de l'instance (%)

Version : V2.0+ (les métriques de répartition de la mémoire sont disponibles à partir de la version V2.0.15)

Hologres divise la mémoire en six catégories :

Dépannage : Une utilisation élevée de la mémoire Query ou des événements de mémoire insuffisante (OOM) indiquent généralement des requêtes complexes ou une concurrence élevée. Pour obtenir des conseils d'optimisation, consultez la rubrique Optimiser les performances des requêtes.

Utilisation de la mémoire des requêtes QE (octets)

La mémoire (en octets) utilisée par les requêtes exécutées par les moteurs HQE, SQE ou autres moteurs XQE.

Version : V2.0.44+ / V2.1.22+

Dans les répartitions de mémoire, l'utilisation de la mémoire Query dépasse celle de la mémoire des requêtes QE, car Query inclut tous les types de moteur. Une utilisation plus élevée de la mémoire des requêtes QE indique des requêtes plus complexes nécessitant davantage de mémoire.

Utilisation de la mémoire des requêtes QE (%)

Le pourcentage de mémoire utilisé par les requêtes du moteur QE.

Version : V2.0.44+ / V2.1.22+

Une utilisation élevée peut entraîner des erreurs OOM. Optimisez les requêtes ou augmentez la capacité de l'instance.

Utilisation de la mémoire du cluster (%)

L'utilisation de la mémoire de chaque Cluster dans le groupe de calcul.

Version : V4.0+. Uniquement pour les instances de groupe de calcul.

QPS des requêtes (nombre/s)

Nombre moyen d'instructions SQL exécutées par seconde, y compris SELECT, INSERT, UPDATE, DELETE, UTILITY et UNKNOWN.

Relation : Query QPS >= QE Query QPS + FixedQE Query QPS

Le QPS total inclut toutes les requêtes (UNKNOWN, UTILITY, Engine Type={PG}), il est donc supérieur ou égal à la somme des QPS QE et FixedQE.

QPS des requêtes QE (nombre/s)

Nombre de requêtes par seconde exécutées par le moteur QE, y compris SELECT, INSERT, UPDATE et DELETE.

Version : V2.2+

QPS des requêtes FixedQE (nombre/s)

Nombre de requêtes par seconde exécutées par le moteur FixedQE (chemin Fixed Plan, anciennement SDK), y compris SELECT, INSERT, UPDATE et DELETE.

Version : V2.2+

RPS DML (nombre/s)

Nombre moyen d'enregistrements de données importés ou mis à jour par seconde, y compris INSERT, UPDATE et DELETE.

Relation : DML RPS = QE DML RPS + FixedQE DML RPS

RPS DML QE (nombre/s)

Nombre d'enregistrements de données importés ou mis à jour par seconde par le moteur QE, y compris INSERT, UPDATE et DELETE.

Version : V2.2+

Scénarios QE courants :

• Importation ou mise à jour par lots à partir de tables externes MaxCompute ou OSS

• Écriture ou mise à jour par lots à l'aide de COPY

• Importation par lots entre tables Hologres

RPS DML FixedQE (nombre/s)

Nombre d'enregistrements de données importés ou mis à jour par seconde par le moteur FixedQE (chemin Fixed Plan, anciennement SDK), y compris INSERT, UPDATE et DELETE.

Version : V2.2+

Scénarios FixedQE courants :

• Écritures en temps réel à l'aide de Flink

• Écritures à l'aide de Holo-Client

• Imports à l'aide de Spark

• Synchronisation en temps réel de MySQL Binlog vers Hologres

• Imports depuis DataHub

• Écritures hors ligne à l'aide de Data Integration (DataX)

• Écritures à l'aide de SQL ou JDBC avec INSERT INTO VALUES()

Latence des requêtes (millisecondes)

Latence moyenne de toutes les requêtes, y compris SELECT, INSERT, UPDATE, DELETE, UTILITY et UNKNOWN.

Relation : Query Latency >= MAX(QE Query Latency, FixedQE Query Latency)

Latence des requêtes QE (millisecondes)

Latence moyenne des requêtes exécutées par le moteur QE, y compris SELECT, INSERT, UPDATE et DELETE.

Version : V2.2+

Pour résoudre les problèmes de latence élevée des requêtes QE, vérifiez les métriques Durée de la phase d'optimisation, Durée de la phase de démarrage de la requête, Durée de la phase Get Next et QPS QE.

Latence des requêtes FixedQE (millisecondes)

Latence moyenne des requêtes exécutées par le moteur FixedQE, y compris SELECT, INSERT, UPDATE et DELETE.

Version : V2.2+

Dépannage :

• Pics occasionnels : peuvent indiquer des verrous HQE. Vérifiez si le temps d'attente des verrous Backend FixedQE a augmenté. Si c'est le cas, utilisez la fonctionnalité Obtenir des informations sur les requêtes pour identifier les requêtes bloquantes.

• Latence élevée persistante : peut résulter d'une conception de table sous-optimale ou d'interférences causées par des requêtes complexes. Consultez la rubrique Problèmes courants et diagnostics pour Blink et Flink.

Durée de la phase d'optimisation (millisecondes)

Temps passé dans la phase d'optimisation, où l'optimiseur analyse le code SQL et génère un plan physique.

Version : V2.0.44+ / V2.1.22+

Des durées d'optimisation longues suggèrent des requêtes complexes. Si les requêtes ne diffèrent que par leurs paramètres, utilisez des instructions préparées (Prepared Statements) pour réduire la charge d'optimisation. Pour plus d'informations, consultez la rubrique JDBC.

Durée de la phase de démarrage de la requête (millisecondes)

Temps passé dans la phase de démarrage de la requête — initialisation avant l'exécution de la requête, y compris le verrouillage et l'alignement de la version du schéma.

Version : V2.0.44+ / V2.1.22+

Des durées longues pour le démarrage de la requête résultent souvent d'attentes de verrous ou d'une utilisation élevée du CPU. Utilisez les plans d'exécution pour une analyse plus approfondie.

Durée de la phase Get Next (millisecondes)

Temps écoulé entre la fin de la phase de démarrage de la requête et le retour de tous les résultats, y compris le calcul et la livraison des résultats.

Version : V2.0.44+ / V2.1.22+

Des durées longues pour la phase Get Next reflètent souvent des calculs complexes. Mettez-les en corrélation avec l'utilisation de la mémoire QE et le QPS QE. Si aucune anomalie n'existe dans ces métriques, le client peut simplement être lent à consommer les résultats.

Latence P99 des requêtes (millisecondes)

Latence du 99e percentile de toutes les requêtes, y compris SELECT, INSERT, UPDATE, UTILITY et les requêtes système.

Durée de la requête la plus longue en cours d'exécution sur cette instance (millisecondes)

Durée de la requête active la plus longue, couvrant SELECT, INSERT, UPDATE, DELETE, UTILITY et UNKNOWN.

Version : V1.1+

Les requêtes sont distribuées sur les nœuds Worker. Cette métrique signale la requête la plus longue sur tous les Workers. Par exemple, si les Workers exécutent des requêtes de 10 minutes, 5 minutes et 30 secondes, la valeur rapportée est de 10 minutes.

Combinez cette métrique avec les requêtes actives ou les journaux des requêtes lentes pour diagnostiquer les requêtes de longue durée et résoudre les interblocages.

Les métriques sont rapportées chaque minute, donc la « durée d'exécution actuelle » commence légèrement après le début de la requête. Cette métrique est utile pour la détection d'anomalies, mais ne fournit pas de chronométrage précis.

QPS des requêtes échouées (millisecondes)

Nombre moyen d'instructions SQL ayant échoué par seconde, y compris SELECT, INSERT, UPDATE, DELETE, UTILITY et UNKNOWN.

Relation : Failed Query QPS >= QE Failed Query QPS + FixedQE Failed Query QPS

Le QPS total des échecs inclut toutes les requêtes ayant échoué (UNKNOWN, UTILITY, Engine Type={PG}), il est donc supérieur ou égal à la somme des QPS d'échec QE et FixedQE.

Utilisez le type et la fréquence des requêtes échouées pour trouver les requêtes défaillantes dans les journaux des requêtes lentes, puis analysez les causes racines pour améliorer la disponibilité.

QPS des requêtes QE échouées (nombre/s)

Nombre de requêtes échouées par seconde par le moteur QE, y compris SELECT, INSERT, UPDATE et DELETE.

Version : V2.2+

QPS des requêtes FixedQE échouées (nombre/s)

Nombre de requêtes échouées par seconde par le moteur FixedQE, y compris SELECT, INSERT, UPDATE et DELETE.

Version : V2.2+

Temps d'attente maximal des verrous FE (millisecondes)

Hologres dispose de plusieurs nœuds FE qui analysent, distribuent et routent les instructions SQL. Lorsque plusieurs connexions sur le même FE effectuent des opérations DDL sur la même table (telles que CREATE ou DROP), des verrous FE se produisent. Cette métrique affiche le temps d'attente des verrous DDL par FE.

Version : V2.2+

Si le temps d'attente des verrous FE dépasse 5 minutes et que le délai de réplication FE augmente également, une opération DDL peut être bloquée. Utilisez la fonctionnalité Gérer les requêtes pour trouver et terminer les requêtes de longue durée.

Temps d'attente des verrous Backend FixedQE (millisecondes)

Les requêtes INSERT, DELETE ou UPDATE utilisant HQE prennent des verrous de table, tandis que les requêtes FixedPlan prennent des verrous de ligne. Cette métrique augmente lorsque les requêtes FixedPlan attendent des verrous de ligne pendant que les requêtes HQE détiennent des verrous de table sur la même table.

Version : V2.2+

Si cette valeur est élevée, vérifiez les journaux des requêtes lentes pour identifier les requêtes FixedQE lentes, puis utilisez la fonctionnalité Obtenir des informations sur les requêtes pour identifier les requêtes HQE bloquantes.

Temps total d'attente des verrous Backend pour l'instance (millisecondes)

Le temps total d'attente des verrous pour les requêtes INSERT, DELETE ou UPDATE dans l'instance, y compris les attentes de verrous FixedQE et HQE.

Version : V2.2+

Si cette valeur est élevée, vérifiez les journaux des requêtes lentes pour identifier les requêtes INSERT, DELETE ou UPDATE lentes, puis utilisez la fonctionnalité Obtenir des informations sur les requêtes pour identifier les requêtes HQE bloquantes.

Connexions Gateway (nombre)

Nombre total de connexions au niveau de la couche Gateway de l'instance, reflétant la charge globale des connexions à la couche d'accès.

• Connexions Gateway = Connexions FE + Émetteurs WAL FE + FE fixe non-Binlog + FE fixe Binlog.

• Si le nombre de connexions Gateway reste proche de la limite de l'instance pendant une période prolongée, les ressources de connexion approchent de la saturation. Nettoyez les connexions inactives ou augmentez la capacité de l'instance pour obtenir plus de ressources de connexion.

Utilisation maximale des connexions Gateway (%)

Taux d'utilisation maximal des connexions Gateway, reflétant la pression maximale exercée sur le pool de connexions de la couche d'accès. Lorsque l'utilisation approche régulièrement les 100 %, les nouvelles connexions peuvent échouer. Analysez cette métrique conjointement avec celle des Connexions Gateway et envisagez une mise à l'échelle verticale.

Connexions FE (nombre)

Connexions sur les nœuds FE (Frontend), reflétant la charge des connexions au niveau de la couche d'analyse et de routage SQL. Hologres définit des limites par défaut pour les connexions FE en fonction des spécifications de l'instance. Pour plus d'informations, consultez Gestion des instances. Cette métrique inclut les connexions actives, inactives et inactives dans une transaction. Utilisez la fonctionnalité Gérer les requêtes pour afficher l'utilisation actuelle des connexions et terminer les connexions inactives lorsque les ressources sont faibles.

Connexions FE par base de données (nombre)

Répartition des connexions FE par base de données, permettant d'identifier les bases de données qui consomment le plus de connexions.

Connexions FE par nœud FE (nombre)

Répartition des connexions FE par nœud FE, permettant d'évaluer si la charge des connexions est équilibrée entre les nœuds.

• Limite de connexion par défaut par nœud FE : 128. Pour les limites totales, consultez Gestion des instances.

• Si le nombre de connexions sur un nœud approche de la limite, examinez la répartition entre connexions inactives et actives. Utilisez la fonctionnalité Gérer les connexions pour nettoyer les connexions inactives ou augmenter la capacité de l'instance.

• Si la charge des connexions est inégale entre les nœuds, utilisez la fonctionnalité Gérer les connexions pour identifier et nettoyer les connexions inactives.

Utilisation maximale des connexions FE (%)

Taux d'utilisation maximal des connexions FE : Max(frontend_connection_used_rate). Utilisez cette métrique pour détecter quand un nœud FE approche de sa limite de connexions. Les nœuds FE utilisent un équilibrage de charge de type round-robin. Utilisez la fonctionnalité Gérer les requêtes pour afficher les détails d'utilisation et terminer les connexions inactives si nécessaire.

Nombre d'émetteurs WAL FE par nœud FE (nombre)

Émetteurs WAL par nœud FE. Lors de la consommation du Binlog via JDBC, chaque shard de chaque table utilise une connexion d'émetteur WAL. Les connexions d'émetteurs WAL sont indépendantes des connexions classiques et possèdent leur propre limite. Utilisez cette métrique pour surveiller l'utilisation des émetteurs WAL par nœud FE.

Utilisation maximale des émetteurs WAL (%)

Taux d'utilisation maximal des émetteurs WAL, reflétant la pression maximale exercée sur les connexions liées au Binlog. Lorsque l'utilisation approche de la limite, la consommation du Binlog peut être affectée. Effectuez une analyse et augmentez la capacité si nécessaire.

Connexions FE fixes (non-Binlog) (nombre)

Connexions non-Binlog sur les nœuds FE fixes, reflétant la charge des connexions sur le chemin d'exécution Fixed Plan.

Connexions Binlog FE fixes (nombre)

Connexions Binlog sur les nœuds FE fixes, reflétant la charge des connexions liées au Binlog sur le chemin d'exécution Fixed Plan.

Nombre de requêtes en file d'attente (nombre)

Nombre de demandes de requête en attente d'exécution.

Version : V3.0+

QPS d'entrée dans la file d'attente des requêtes (nombre/s)

Nombre de requêtes soumises à la file d'attente système par seconde. Utilisez cette métrique pour évaluer la charge du système et la fréquence des requêtes.

Version : V3.0+

QPS des requêtes passant de l'état En attente à Exécution (nombre/s)

Nombre de requêtes passant de l'état d'attente à l'état d'exécution par seconde.

Version : V3.0+

QPS par état pour les requêtes ayant commencé à s'exécuter (nombre/s)

Nombre par seconde de requêtes dans la file d'attente, regroupées par état :

• kReadyToRun -- prêt à s'exécuter

• kQueueTimeout -- échec dû à un dépassement du délai d'attente de la file

• kCanceled -- échec dû à une annulation

• kExceedConcurrencyLimit -- échec dû au dépassement de la limite de concurrence

Version : V3.0+

Temps d'attente moyen dans la file d'attente des requêtes (millisecondes)

Temps moyen entre l'entrée dans la file d'attente et le début du traitement. Cela n'inclut pas le temps réel d'exécution de la requête.

Version : V3.0+

Concurrence maximale de la limitation automatique du débit de la file d'attente des requêtes (nombre)

Concurrence maximale pour les files d'attente de requêtes soumises à une limitation automatique du débit.

Version : V3.1+. Instances de groupe de calcul uniquement.

Débit de lecture des E/S standard (octets/s)

Débit de lecture pour les données stockées en stockage standard.

Débit d'écriture des E/S standard (octets/s)

Débit d'écriture pour les données stockées en stockage standard.

Débit de lecture des E/S basse fréquence (octets/s)

Débit de lecture pour les données stockées en stockage IA.

Débit d'écriture des E/S basse fréquence (octets/s)

Débit d'écriture pour les données stockées en stockage IA.

Capacité utilisée du stockage standard (octets)

Capacité utilisée dans le stockage standard. Augmentez la capacité de stockage si l'utilisation dépasse la capacité achetée.

Utilisation du stockage standard (%)

Pourcentage d'utilisation de la capacité du stockage standard. Augmentez la capacité de stockage si l'utilisation dépasse la capacité achetée.

Capacité utilisée du stockage IA (octets)

Capacité utilisée dans le stockage IA. Augmentez la capacité de stockage si l'utilisation dépasse la capacité achetée.

Utilisation du stockage IA (%)

Pourcentage d'utilisation de la capacité du stockage IA. Augmentez la capacité de stockage si l'utilisation dépasse la capacité achetée.

Utilisation du stockage de la corbeille (octets)

Version : V3.1+

Hologres prend en charge une corbeille de tables à partir de la version V3.1. Les tables supprimées avec DROP restent dans la corbeille pendant une période de rétention, permettant la récupération des tables supprimées accidentellement. Ces tables continuent de consommer du stockage de l'instance.

Surveillez l'utilisation de la corbeille par base de données. Si des suppressions fréquentes de tables entraînent une utilisation élevée de la corbeille, configurez les tables pour qu'elles ignorent la corbeille lors de la suppression.

Délai de relecture FE (millisecondes)

Version : V2.2+

Hologres comporte plusieurs nœuds FE. Pour les opérations DDL, Hologres exécute l'opération sur un nœud FE et la rejoue sur les autres. Des délais de relecture de l'ordre de la milliseconde ou de la seconde sont normaux.

Si le délai de relecture d'un nœud FE dépasse plusieurs minutes, un trop grand nombre d'opérations DDL peut surcharger le processus de relecture. Si le délai continue d'augmenter, une requête peut être bloquée. Utilisez la vue hg_stat_activity pour trouver et terminer les requêtes de longue durée.

Délai de synchronisation multi-réplicas des shards (millisecondes)

Délai de synchronisation entre les réplicas de shard après activation de la réplication.

Le délai typique des réplicas de shard est de l'ordre de la milliseconde. Des écritures ou mises à jour massives de données, ou des opérations DDL fréquentes, peuvent augmenter ce délai de synchronisation.

Délai de synchronisation primaire-secondaire (millisecondes)

Délai lorsqu'une instance secondaire lit les données depuis l'instance primaire. Cette métrique n'apparaît que pour les instances secondaires, pas pour les instances primaires.

• Les données n'apparaissent qu'après qu'une instance secondaire est liée à une instance primaire (0 ms initialement). Le délai de synchronisation fluctue lorsque l'instance primaire reçoit des écritures.

• Un délai de synchronisation normal est de l'ordre de la milliseconde. Des variations occasionnelles dues aux opérations DDL sur l'instance primaire peuvent être ignorées. Un délai élevé persistant de plus de quelques secondes peut indiquer une charge importante de l'instance ou un manque de ressources -- vérifiez l'utilisation du CPU et de la mémoire et augmentez la capacité si nécessaire.

• Le délai de synchronisation peut atteindre plusieurs minutes lors des redémarrages ou des mises à niveau, puis se rétablit automatiquement.

Délai de synchronisation des fichiers inter-instances (millisecondes)

Délai de synchronisation des fichiers entre les instances de reprise après sinistre. Cette métrique n'apparaît que sur les instances secondaires (lecteurs secondaires).

Tables manquantes de statistiques par base de données (nombre)

Nombre de tables dépourvues de statistiques dans chaque base de données.

Version : V2.2+

Pour Hologres V2.0 et versions ultérieures, Auto Analyze s'exécute par défaut. Après la création d'une table ou des écritures/mises à jour massives, les statistiques peuvent temporairement prendre du retard -- observez la situation pendant une courte période.

Si une base de données manque constamment de statistiques pendant des heures ou des jours, Auto Analyze n'a peut-être pas été déclenché. Utilisez la vue HG_STATS_MISSING pour lister les tables concernées, puis exécutez manuellement ANALYZE. Pour plus d'informations, consultez ANALYZE et AUTO ANALYZE.

Durée de la requête de calcul Serverless la plus longue (millisecondes)

Durée de la requête la plus longue exécutée dans le calcul Serverless. Le calcul Serverless exécute des requêtes spécifiques dans un pool de ressources dédié, isolé de l'instance principale.

Version : V2.1+

Utilisez la vue hg_stat_activity pour inspecter l'état des requêtes de calcul Serverless.

Nombre de requêtes en file d'attente pour le calcul Serverless (nombre)

Nombre de requêtes en file d'attente dans le pool de ressources de calcul Serverless.

Version : V2.2+

Utilisation du quota de ressources de calcul Serverless (%)

Ratio entre les ressources de calcul Serverless réellement utilisées et les ressources maximales allouables.

Version : V2.2+

Taux de consommation du Binlog (nombre/s)

Nombre d'entrées Binlog consommées par seconde. Hologres prend en charge l'abonnement au Binlog Hologres pour la hiérarchisation des données en temps réel et l'accélération du transfert des données.

Version : V2.2+

Taux de consommation du Binlog (octets/s)

Octets consommés depuis le Binlog par seconde. Des champs plus volumineux ou des volumes de données plus élevés augmentent le nombre d'octets.

Version : V2.2+

Nombre d'émetteurs WAL par FE (nombre)

Nombre d'émetteurs WAL utilisés par nœud FE. Chaque shard de chaque table consomme une connexion d'émetteur WAL lors de la consommation du Binlog via JDBC. Les connexions d'émetteurs WAL sont indépendantes des connexions classiques et disposent d'une limite par défaut.

Version : V2.2+

Taux d'utilisation des émetteurs WAL du FE avec l'utilisation la plus élevée (%)

Utilisation maximale des émetteurs WAL parmi tous les nœuds FE.

Version : V2.2+

Si l'utilisation des émetteurs WAL atteint la limite, consultez Consommer le Binlog Hologres via JDBC pour le dépannage.

Nombre de cœurs élastiques pour les groupes de calcul

Cœurs ajoutés par la mise à l'échelle basée sur le temps dans le groupe de calcul. Élasticité basée sur le temps (Beta).

Version : V2.2.21+. Instances de groupe de calcul uniquement.

Nombre de cœurs auto-élastiques du groupe de calcul (nombre)

Cœurs ajoutés par la mise à l'échelle automatique dans le groupe de calcul. Multi-cluster et auto-élasticité (Beta).

Version : V4.0+. Instances de groupe de calcul uniquement.

Utilisation du CPU du Gateway (%)

L'utilisation du CPU de chaque Gateway au sein de l'instance.

Version : V2.0+. Uniquement pour les instances de groupe de calcul.

Les Gateways utilisent un transfert de trafic en tourniquet (round-robin), ce qui génère une utilisation du CPU même en l'absence de nouvelles connexions. À partir de la version V2.2.22, les Gateways lancent davantage de threads de travail par défaut afin d'améliorer la gestion des connexions, ce qui augmente l'utilisation de base du CPU.

Utilisation de la mémoire du Gateway (%)

L'utilisation de la mémoire de chaque Gateway au sein de l'instance.

Version : V2.0+. Uniquement pour les instances de groupe de calcul.

Nouvelles demandes de connexion du Gateway par seconde (nombre/s)

Le nombre maximal de nouvelles connexions que le système peut accepter et établir avec succès par seconde.

Version : V2.1.12+. Uniquement pour les instances de groupe de calcul.

Un seul Gateway gère environ 100 nouvelles connexions par seconde. Si les demandes de nouvelles connexions approchent 100 x Gateway count, les Gateways constituent le goulot d'étranglement. Configurez un pool de connexions ou augmentez le nombre de Gateways.

Débit du trafic entrant du Gateway (o/s)

Le volume de données entrantes via le Gateway par seconde.

Version : V2.1+. Uniquement pour les instances de groupe de calcul.

Si le trafic entrant approche 200 MiB/s x Gateway count, la capacité réseau du Gateway constitue le goulot d'étranglement. Augmentez le nombre de Gateways.

Débit du trafic sortant du Gateway (o/s)

Le volume de données envoyées par le Gateway par seconde.

Version : V2.1+. Uniquement pour les instances de groupe de calcul.

Si le trafic sortant approche 200 MiB/s x Gateway count, la capacité réseau du Gateway constitue le goulot d'étranglement. Augmentez le nombre de Gateways.