Realtime Compute for Apache Flink:Problèmes de performance des jobs

Comment diviser les nœuds d'opérateur ?

pipeline.operator-chaining: 'false'

Quelles sont les techniques d'optimisation par agrégation de groupe ?

• Activer MiniBatch (améliore le débit)

  MiniBatch met en tampon les données entrantes avant de déclencher leur traitement. Cette approche réduit la fréquence des accès à l'état (State), augmente le débit et diminue le volume des sorties.

  MiniBatch déclenche un traitement par micro-lots en fonction des messages d'événement insérés à l'intervalle que vous spécifiez au niveau de la source.

  • Scénarios

    Le micro-batching échange une légère augmentation de la latence contre un gain significatif en matière de débit. Ne l'activez pas si vous avez besoin d'une latence ultra-faible. Pour la plupart des scénarios d'agrégation, l'activation de MiniBatch améliore considérablement les performances du système.

  • Procédure d'activation

    MiniBatch est désactivé par défaut. Pour l'activer, accédez à l'onglet Deployment Details de votre tâche cible, puis dans la section Runtime Parameter Settings sous Other Settings, ajoutez le code suivant.

    table.exec.mini-batch.enabled: true
    table.exec.mini-batch.allow-latency: 5s

    Le tableau ci-dessous décrit ces paramètres.

    Paramètre	description
    table.exec.mini-batch.enabled	Indique s'il faut activer le mini-batch.
    table.exec.mini-batch.allow-latency	Intervalle de temps entre les sorties des lots.

• Activer LocalGlobal (résout les problèmes courants de points chauds de données)

  Le mécanisme LocalGlobal utilise LocalAgg pour pré-agréger les données skewées, réduisant ainsi la pression sur les points chauds au niveau de GlobalAgg et améliorant les performances globales.

  LocalGlobal divise une seule agrégation en deux étapes : locale et globale, à l'instar des phases Combine et Reduce dans MapReduce. Lors de la première étape, les nœuds en amont mettent en tampon et agrègent les données localement (localAgg), puis émettent des accumulateurs incrémentiels. Lors de la seconde étape, ces accumulateurs sont fusionnés (Merge) pour produire le résultat final (GlobalAgg).

  • Scénarios

    Cette option améliore les performances des agrégations standard (telles que SUM, COUNT, MAX, MIN et AVG) et résout les problèmes de points chauds de données dans ces cas de figure.

  • Limites

    LocalGlobal est activé par défaut, mais présente les limitations suivantes :

    • MiniBatch doit être activé.

    • Votre AggregateFunction doit implémenter Merge.

  • Vérifier que la modification est prise en compte

    Vérifiez si la topologie générée contient des nœuds nommés GlobalGroupAggregate ou LocalGroupAggregate.

• Activer PartialFinal (résout les problèmes de points chauds liés à COUNT DISTINCT)

  Pour résoudre les points chauds liés à COUNT DISTINCT, il fallait traditionnellement réécrire manuellement les requêtes en une agrégation en deux étapes (en ajoutant une couche de brassage basée sur le modulo). Realtime Compute for Apache Flink propose désormais un brassage automatique de COUNT DISTINCT via l'optimisation PartialFinal, sans nécessiter de réécriture manuelle.

  LocalGlobal fonctionne bien pour les agrégations standard, mais offre peu d'avantages pour COUNT DISTINCT. Lors de l'agrégation locale, les taux de déduplication des clés distinctes restent faibles, ce qui maintient les points chauds au niveau du nœud global.

  • Scénarios

    Utilisez cette option lorsque COUNT DISTINCT ne répond pas aux exigences de performance des nœuds d'agrégation.

    Important

    • N'utilisez pas l'optimisation PartialFinal dans les instructions Flink SQL qui incluent des UDAF.

    • Évitez PartialFinal lorsque le volume de données est faible, car cela introduit un brassage réseau inutile et gaspille des ressources.

  • Procédure d'activation

    Cette fonctionnalité est désactivée par défaut. Pour l'activer, dans l'onglet Deployment Details de la tâche cible, saisissez le code suivant dans le champ Other Configurations de la section Runtime Parameter Settings.

    table.optimizer.distinct-agg.split.enabled: true

  • Vérifiez que les modifications sont effectives.

    Vérifiez si la topologie générée passe d'une seule étape d'agrégation à deux étapes.

• Réécrire AGG WITH CASE WHEN en syntaxe AGG WITH FILTER (améliore les performances dans les scénarios comportant plusieurs COUNT DISTINCT)

  Si votre tâche calcule l'UV selon différentes dimensions (par exemple, UV total, UV client mobile et UV PC), utilisez la syntaxe standard AGG WITH FILTER plutôt que CASE WHEN. L'optimiseur SQL de Realtime Compute reconnaît les paramètres Filter, permettant à plusieurs opérations COUNT DISTINCT sur le même champ de partager l'état (State) et de réduire les E/S State. Les tests de performance montrent que cette réécriture peut doubler les performances.

  • Scénarios

    Des gains de performance significatifs sont observés lors du calcul de plusieurs résultats COUNT DISTINCT sur le même champ selon différentes conditions.

  • Texte original

    COUNT(distinct visitor_id) as UV1 , COUNT(distinct case when is_wireless='y' then visitor_id else null end) as UV2

  • Syntaxe optimisée

    COUNT(distinct visitor_id) as UV1 , COUNT(distinct visitor_id) filter (where is_wireless='y') as UV2

Quelles sont les techniques d'optimisation TopN ?

• Algorithmes TopN

  Si l'entrée TopN est un flux en ajout uniquement (par exemple, depuis SLS), un seul algorithme est disponible : AppendRank. Si l'entrée est un flux de mise à jour (par exemple, après une opération AGG ou JOIN), deux algorithmes sont disponibles, classés par ordre de performance décroissant : UpdateFastRank et RetractRank. Les noms des algorithmes apparaissent dans les étiquettes des nœuds de topologie.

  • AppendRank : pris en charge uniquement pour les flux en ajout uniquement.

  • UpdateFastRank : optimal pour les flux de mise à jour.

  • RetractRank : algorithme de secours pour les flux de mise à jour. Performances inférieures. Dans certains cas, il peut être optimisé en UpdateFastRank.

  Pour optimiser RetractRank en UpdateFastRank, trois conditions doivent être remplies :

  • Le flux d'entrée doit être un flux de mise à jour.

  • Le flux d'entrée doit inclure des informations sur la clé primaire, par exemple après une agrégation GROUP BY.

  • Les champs de tri doivent évoluer de manière monotone dans le sens opposé au tri. Par exemple, ORDER BY COUNT, COUNT_DISTINCT ou SUM (valeurs positives) DESC.

  Pour garantir l'utilisation d'UpdateFastRank avec ORDER BY SUM DESC, ajoutez une condition de filtre garantissant que total_fee est positif.

  insert
    into print_test
  SELECT
    cate_id,
    seller_id,
    stat_date,
    pay_ord_amt  -- Omit rownum to reduce sink table output.
  FROM (
      SELECT
        *,
        ROW_NUMBER () OVER (
          PARTITION BY cate_id,
          stat_date  -- Include a time field to prevent data corruption from State TTL.
          ORDER
            BY pay_ord_amt DESC
        ) as rownum  -- Sort by upstream sum result.
      FROM (
          SELECT
            cate_id,
            seller_id,
            stat_date,
            -- Critical: Declare all SUM inputs as positive, ensuring monotonic increase.
            -- This allows TopN to use the optimized algorithm and fetch only top 100 records.
            sum (total_fee) filter (
              where
                total_fee >= 0
            ) as pay_ord_amt
          FROM
            random_test
          WHERE
            total_fee >= 0
          GROUP
            BY cate_name,
            seller_id,
            stat_date,
            cate_id
        ) a
      ) WHERE
        rownum <= 100;

• Méthodes d'optimisation TopN

  • Optimisation sans sortie de classement

    Si votre sortie TopN n'a pas besoin d'afficher les valeurs rownum, omettez-les et effectuez le tri une seule fois côté frontal. Cela réduit considérablement le volume de sortie vers la table de destination. Pour plus de détails, consultez Top-N.

  • Augmenter la taille du cache TopN

    TopN utilise une couche de cache d'état pour améliorer l'efficacité d'accès à l'état. Le taux de succès du cache se calcule comme suit.

    cache_hit = cache_size*parallelism/top_n/partition_key_num

    Par exemple, avec Top100, une taille de cache de 10 000, un parallélisme de 50 et 100 000 clés de partition, le taux de succès n'est que de 10000*50/100/100000=5%. Un faible taux de succès entraîne la plupart des requêtes vers l'état basé sur disque, créant des anomalies dans les métriques de recherche d'état et dégradant fortement les performances.

    Lorsque la cardinalité des clés de partition est très élevée, augmentez la taille du cache TopN et la mémoire heap en conséquence. Pour plus de détails, consultez Configure job deployment settings.

    table.exec.rank.topn-cache-size: 200000

    La taille de cache par défaut est de 10 000. L'augmenter à 200 000 porte le taux de succès théorique à 200000*50/100/100000 = 100%.

  • Inclure un champ temporel dans PartitionBy

    Pour les classements quotidiens, incluez un champ Jour. Sans cela, le TTL d'état risque de corrompre les résultats TopN finaux.

Quelles sont les solutions de déduplication efficaces ?

Points d'attention lors de l'utilisation des fonctions intégrées

• Privilégiez les fonctions intégrées aux fonctions définies par l'utilisateur

  Realtime Compute optimise continuellement ses fonctions intégrées. Il est donc recommandé de les utiliser plutôt que des fonctions définies par l'utilisateur. Les principales optimisations incluent :

  • Une réduction de la surcharge liée à la sérialisation et à la désérialisation.

  • Des opérations directes au niveau des octets.

• Utilisez des séparateurs à un seul caractère dans les fonctions KEY VALUE

  Signature de la fonction KEYVALUE : KEYVALUE(content, keyValueSplit, keySplit, keyName). Lorsque les paramètres keyValueSplit et keySplit sont des caractères uniques (comme le deux-points « : » ou la virgule « , »), le système applique un algorithme optimisé pour localiser directement le paramètre keyName dans les données binaires, sans avoir à fractionner l'intégralité du contenu. Cette approche améliore les performances d'environ 30 %.

• Remarques concernant l'opérateur LIKE

  • Pour vérifier si une chaîne commence par un préfixe (StartWith), utilisez LIKE 'xxx%'.

  • Pour vérifier si une chaîne se termine par un suffixe (EndWith), utilisez LIKE '%xxx'.

  • Pour vérifier si une chaîne contient une sous-chaîne (Contains), utilisez LIKE '%xxx%'.

  • Pour vérifier l'égalité exacte (Equals), utilisez LIKE 'xxx', ce qui équivaut à str = 'xxx'.

  • Pour faire correspondre le caractère de soulignement (_), vous devez l'échapper : LIKE '%seller/_id%' ESCAPE '/'. En SQL, le soulignement (_) agit comme un joker pour un seul caractère. Sans échappement, l'expression LIKE '%seller_id%' correspondrait aussi bien à seller_id, seller#id, sellerxid qu'à seller1id, ce qui entraînerait des résultats incorrects.

• Évitez les fonctions d'expressions régulières (REGEXP)

  Les expressions régulières ont un coût de calcul extrêmement élevé, souvent 100 fois plus lent que les opérations arithmétiques de base. De plus, elles peuvent entrer dans des boucles infinies dans certaines conditions, bloquant ainsi les jobs. Pour plus de détails, consultez l'article Regex execution is too slow. Privilégiez l'opérateur LIKE. Les fonctions d'expressions régulières incluent :

  • REGEXP

  • REGEXP_REPLACE

Comment résoudre les problèmes de faible efficacité et de contre-pression lors de la lecture complète d'une table ?

La contre-pression peut provenir d'un traitement lent en aval. Commencez par vérifier la présence d'une contre-pression dans les composants downstream. Si c'est le cas, résolvez le problème en appliquant l'une des méthodes suivantes :

• Augmentez le niveau de concurrence.

• Activez les optimisations d'agrégation, telles que le minibatch (pour les nœuds d'agrégation en aval).

Quelle est la signification des indicateurs de couleur dans la colonne Status Durations pour les sous-tâches de sommet dans l'aperçu du job ?

Sur la page Overview du job, cliquez sur un nœud d'opérateur et sélectionnez l'onglet SubTasks pour afficher les badges de durée colorés dans la colonne Status Durations.

La colonne Status Durations indique le temps passé par les sous-tâches de sommet dans chaque phase. La signification des couleurs est la suivante :

• : CREATED

• : SCHEDULED

• : DEPLOYING

• : INITIALIZING

• : RUNNING

Qu'est-ce que le thread RMI TCP Connection et pourquoi consomme-t-il beaucoup plus de CPU que les autres threads ?

Dans la liste de surveillance des threads triée par utilisation du CPU, le thread RMI TCP Connection(62)-172.25.240.255 affiche le statut RUNNABLE avec une utilisation du CPU de 82,3 %, soit bien supérieure à celle des threads kafkaRequestSource (entre 16,9 % et 26,4 % d'utilisation du CPU, principalement au statut TIMED_WAITING).

Les threads RMI TCP Connection appartiennent au framework RMI (Remote Method Invocation) intégré à Java et gèrent les appels de méthode distants. L'utilisation du CPU fluctue dynamiquement. Des pics de courte durée n'indiquent pas nécessairement une charge élevée soutenue. Observez l'utilisation du CPU sur une période donnée. L'analyse via le graphe en flammes (ci-dessous) montre que les threads RMI ne consomment pratiquement pas de CPU.

Pourquoi observe-t-on un décalage horaire entre les valeurs Low Watermark, Watermark et Task InputWatermark dans la topologie en cours d'exécution et l'heure actuelle ?

• Raison 1 : Le Watermark de la table source est déclaré avec le type TIMESTAMP_LTZ (TIMESTAMP(p) WITH LOCAL TIME ZONE), ce qui engendre des écarts horaires.

  Les exemples ci-dessous comparent le comportement du Watermark selon l'utilisation des types TIMESTAMP_LTZ ou TIMESTAMP.

  • Le Watermark de la table source utilise le type TIMESTAMP_LTZ.

    CREATE TEMPORARY TABLE s1 (
      a INT,
      b INT,
      ts as CURRENT_TIMESTAMP,-- CURRENT_TIMESTAMP generates TIMESTAMP_LTZ.
      WATERMARK FOR ts AS ts - INTERVAL '5' SECOND 
    ) WITH (
      'connector'='datagen',
      'rows-per-second'='1',
      'fields.b.kind'='random','fields.b.min'='0','fields.b.max'='10'
    );
    CREATE TEMPORARY TABLE t1 (
      k INT,
      ts_ltz timestamp_ltz(3),
      cnt BIGINT
    ) WITH ('connector' = 'print');
    -- Output results.
    INSERT INTO t1
    SELECT b, window_start, COUNT(*) FROM
    TABLE(
        TUMBLE(TABLE s1, DESCRIPTOR(ts), INTERVAL '5' SECOND))
    GROUP BY b, window_start, window_end;

    Remarque

    La syntaxe Legacy Window produit des résultats identiques à ceux de la fonction TVF Window (Table-Valued Function). Exemple avec la syntaxe héritée :

    SELECT b, TUMBLE_END(ts, INTERVAL '5' SECOND), COUNT(*) FROM s1 GROUP BY TUMBLE(ts, INTERVAL '5' SECOND), b;

    Après le déploiement et l'exécution de la tâche dans la Realtime Compute development console, vous constaterez un décalage de 8 heures entre le Watermark et l'heure actuelle (en prenant UTC+8 comme référence).

    • Watermark et Low Watermark

      Dans l'onglet Watermarks de l'interface de surveillance des tâches Flink, la sous-tâche 0 affiche une valeur de Watermark égale à 1706778525521, ce qui correspond à l'Datetime of Watermark Timestamp 02-01 09:08:45. L'heure de démarrage de la tâche était 02-01 17:03:04, soit un écart d'environ 8 heures. Le panneau de l'opérateur sur la gauche indique un Low Watermark identique : 02-01 09:08:45.

    • Task InputWatermark

      

  • Le Watermark de la table source utilise le type TIMESTAMP (TIMESTAMP(p) WITHOUT TIME ZONE).

    CREATE TEMPORARY TABLE s1 (
      a INT,
      b INT,
      -- Simulate TIMESTAMP without timezone, starting at 2024-01-31 01:00:00 and incrementing by second.
      ts as TIMESTAMPADD(SECOND, a, TIMESTAMP '2024-01-31 01:00:00'),
      WATERMARK FOR ts AS ts - INTERVAL '5' SECOND 
    ) WITH (
      'connector'='datagen',
      'rows-per-second'='1',
      'fields.a.kind'='sequence','fields.a.start'='0','fields.a.end'='100000',
      'fields.b.kind'='random','fields.b.min'='0','fields.b.max'='10'
    );
    CREATE TEMPORARY TABLE t1 (
      k INT,
      ts_ltz timestamp_ltz(3),
      cnt BIGINT
    ) WITH ('connector' = 'print');
    -- Output results.
    INSERT INTO t1
    SELECT b, window_start, COUNT(*) FROM
    TABLE(
        TUMBLE(TABLE s1, DESCRIPTOR(ts), INTERVAL '5' SECOND))
    GROUP BY b, window_start, window_end;

    Une fois la tâche déployée et exécutée dans la Realtime Compute development console, le Watermark est aligné sur l'heure actuelle (plus précisément, sur l'heure des données simulées) : aucun décalage n'est observé.

    • Watermark et Low Watermark

      Dans l'interface web Apache Flink, accédez aux détails de la tâche et sélectionnez un opérateur (par exemple, GlobalWindowAggregate). Le panneau d'informations de l'opérateur, situé à gauche, affiche le Low Watermark (par exemple, 01-31 01:03:49). Basculez vers l'onglet Watermarks à droite pour consulter les valeurs de Watermark des sous-tâches ainsi que leurs horodatages : les deux heures coïncident.

    • Task InputWatermark

      

• Raison 2 : Différence de fuseau horaire entre la Realtime Compute development console et l'interface utilisateur Apache Flink.

  La Realtime Compute development console affiche les heures au format UTC+0. L'interface utilisateur Apache Flink utilise le fuseau horaire local du navigateur. En prenant UTC+8 (heure de Pékin) comme référence, la Realtime Compute development console affiche des heures retardées de 8 heures par rapport à l'interface Apache Flink.

  • Realtime Compute development console

    Dans la topologie de la page Job O&M, les heures associées au Watermark sont affichées en UTC+0. Par exemple, lorsque l'heure de l'événement est 2024/1/31 09:01:34 AM (heure de Pékin), la console affiche 2024/1/31 01:01:34 AM.

    Les métriques de surveillance liées au Watermark dans la console du produit utilisent également UTC+0, soit un retard de 8 heures par rapport à l'heure de Pékin.

  • Interface utilisateur Apache Flink

    Dans l'interface web Apache Flink, sélectionnez un nœud d'opérateur (par exemple, GlobalWindowAggregate) dans la topologie de la tâche, puis basculez vers l'onglet Watermarks. Consultez les valeurs de Watermark des sous-tâches et les heures d'événement correspondantes. Par exemple, un Low Watermark de 1706662894000 correspond à un Datetime of Watermark Timestamp de 2024/1/31 09:01:34 AM. Il s'agit de l'heure de l'événement, et non de l'heure de traitement ; il est donc normal d'observer des écarts par rapport à l'heure système.

Comment résoudre les problèmes de contre-pression (backpressure) des tâches ?

1. Dans la page Job O&M, cliquez sur le nom de la tâche cible pour ouvrir l'onglet Overview.

2. Examinez les indicateurs Busy et BackPressure pour identifier la source de la contre-pression.

   Plus les indicateurs Busy sont rouges, plus la charge de la tâche est élevée. Plus les indicateurs BackPressure sont foncés, plus l'impact de la contre-pression est important.

   Par exemple, si l'indicateur Backpressured (max) de l'opérateur en amont atteint 99 %, que l'indicateur Busy (max) de l'opérateur intermédiaire est à 100 % (mis en évidence en rouge) et que celui de l'opérateur en aval n'est qu'à 7 %, le goulot d'étranglement se situe au niveau de l'opérateur intermédiaire : optimisez-le.

3. Cliquez sur l'opérateur soumis à la contre-pression.

4. Dans l'onglet BackPressure, vérifiez l'état de la contre-pression pour chaque sous-tâche.

   Si le statut Back Pressure Status est vert (OK) et que le tableau indique pour les sous-tâches 0 à 7 des valeurs Backpressured / Idle / Busy de 0%, 0%, N/A avec tous les états définis sur OK, la tâche ne subit aucune contre-pression.

Comment résoudre les problèmes de latence excessive des tâches ?

Dans la page Job O&M, consultez l'onglet Monitoring and Alerts ou Data Curves pour examiner les métriques currentEmitEventTimeLag et currentFetchEventTimeLag :

• Si la valeur de currentEmitEventTimeLag est élevée, la tâche rencontre des retards lors de la récupération ou du traitement des données. Vérifiez les performances des opérateurs.

• Si la valeur de currentFetchEventTimeLag est élevée, les retards proviennent de la récupération des données ou du traitement par le système en amont. Investiguez les entrées/sorties réseau et les systèmes en amont.

Comment optimiser un job Flink SQL lorsque le déséquilibre des données provoque une contre-pression ?

Lorsque la contre-pression est causée par des points chauds de données (confirmés via l'analyse des sous-tâches), appliquez les optimisations suivantes :

• Activez LocalGlobal (résout les problèmes courants de points chauds de données)

  Le mécanisme LocalGlobal utilise LocalAgg pour pré-agréger les données déséquilibrées, ce qui réduit la pression sur GlobalAgg et améliore les performances globales.

  LocalGlobal divise une agrégation unique en deux étapes : Locale et Globale, à l'image des phases Combine et Reduce dans MapReduce. Lors de la première étape, les nœuds en amont mettent en tampon et agrègent les données localement (localAgg), puis émettent des accumulateurs incrémentiels. Lors de la seconde étape, ces accumulateurs sont fusionnés (Merge) pour produire le résultat final (GlobalAgg).

  • Scénarios

    Cette méthode améliore les performances des agrégations standard (telles que SUM, COUNT, MAX, MIN et AVG) et résout les problèmes de points chauds de données dans ces cas de figure.

  • Limites

    LocalGlobal est activé par défaut, mais les restrictions suivantes s'appliquent :

    • MiniBatch doit être activé.

    • Votre AggregateFunction doit implémenter Merge.

  • Vérification du statut

    Vérifiez si la topologie générée contient des nœuds nommés GlobalGroupAggregate ou LocalGroupAggregate.

• Activez PartialFinal (résout les problèmes de points chauds liés à COUNT DISTINCT)

  Pour traiter les points chauds liés à COUNT DISTINCT, il fallait traditionnellement réécrire manuellement les requêtes en une agrégation en deux étapes (en ajoutant une couche de redistribution basée sur le modulo). Realtime Compute for Apache Flink propose désormais une redistribution automatique de COUNT DISTINCT via l'optimisation PartialFinal, sans nécessiter de réécriture manuelle.

  LocalGlobal fonctionne bien pour les agrégations standard, mais offre peu d'avantages pour COUNT DISTINCT. Lors de l'agrégation locale, les taux de déduplication des clés distinctes restent faibles, ce qui maintient les points chauds au niveau du nœud global.

  • Scénarios

    Utilisez cette option lorsque COUNT DISTINCT ne satisfait pas aux exigences de performance des nœuds d'agrégation.

    Important

    • N'utilisez pas l'optimisation PartialFinal dans Flink SQL incluant des UDAF.

    • Évitez PartialFinal lorsque le volume de données est faible, car cela introduit une redistribution réseau inutile et gaspille des ressources.

  • Activation

    Par défaut, cette fonctionnalité est désactivée. Pour l'activer, accédez à l'onglet Deployment Details du job cible, puis saisissez le code suivant dans la section Other Configurations de la zone Runtime Parameter Settings.

    table.optimizer.distinct-agg.split.enabled: true

  • Vérification de l'efficacité

    Vérifiez si la topologie générée passe d'une seule étape d'agrégation à deux étapes.

Comment résoudre l'instabilité de la vitesse de consommation des données d'entrée ?

Causes possibles et solutions :

• Le modèle de production des données en amont ne correspond pas à la vitesse de traitement actuelle.

  Analysez les modèles de génération des données en amont afin d'aligner les taux de production et de traitement.

• Le job subit une contre-pression.

  Vérifiez la présence d'une contre-pression affectant la consommation en amont. Si votre job n'affiche qu'un seul nœud, ajoutez pipeline.operator-chaining: 'false', redémarrez le job pour scinder la chaîne d'opérateurs, et identifiez les nœuds soumis à une contre-pression qui impactent le taux de consommation.

• Taux d'E/S anormal.

  Examinez les courbes d'entrée et de consommation des données de Flink au moment pertinent pour déterminer si les E/S sont en cause.

• Taux de consommation anormal.

  Vérifiez si les fluctuations du taux de consommation coïncident avec les événements de Garbage Collection (GC). Si c'est le cas, inspectez l'utilisation de la mémoire des nœuds TM.