Troubleshoot OOM errors in Hologres - Hologres - Centre de documentation Alibaba Cloud

Une erreur OOM (Out of Memory, mémoire insuffisante) se produit lorsqu'une requête dépasse la mémoire disponible dans Hologres. Cette rubrique explique comment surveiller l'utilisation de la mémoire, identifier les erreurs OOM et les résoudre.

Analyser la consommation de mémoire

Afficher la consommation de mémoire
- Consommation totale : La console Hologres affiche la consommation agrégée de mémoire sur tous les nœuds. Pour plus d'informations, reportez-vous à Métriques de surveillance.
- Consommation par requête : Le champ memory_bytes donne une approximation de la consommation de mémoire par requête. Cette valeur peut être imprécise. Pour plus d'informations, reportez-vous à Obtenir et analyser les journaux de requêtes lentes.
Gérer une utilisation élevée de la mémoire

Surveillez l'utilisation globale de la mémoire dans la console Hologres (consultez Métriques de surveillance). Une utilisation soutenue supérieure à 80 % est considérée comme élevée. Hologres pré-alloue de la mémoire pour les métadonnées et le cache, il est donc normal que l'utilisation au repos se situe entre 30 et 50 %. Une utilisation proche de 100 % dégrade la stabilité et les performances.
- Causes
  - Forte consommation de mémoire due aux métadonnées
    
    La mémoire utilisée par les métadonnées augmente avec le volume des tables et peut entraîner une utilisation élevée même en l'absence de tâches en cours d'exécution. Maintenez chaque groupe de tables (Table Group) sous la barre des 10 000 tables (y compris les partitions, à l'exclusion des tables externes). Un nombre excessif de shards dans un groupe de tables accroît la fragmentation et la surcharge liée aux métadonnées.
  - Forte consommation de mémoire due au calcul
    
    Une consommation élevée de mémoire par les requêtes résulte généralement du balayage de grands volumes de données ou d'opérations complexes, telles que plusieurs fonctions COUNT DISTINCT, des opérations JOIN complexes, des clauses GROUP BY sur plusieurs colonnes ou des fonctions de fenêtrage.
  - Utilisation élevée de la mémoire dans le module Other
    
    Lorsque la surveillance de la mémoire indique une augmentation soudaine de l'utilisation de la mémoire du module Other, accompagnée d'une utilisation globale élevée, la cause peut être le paramètre expérimental hg_experimental_enable_hash_partitioned_sort_v2. Ce paramètre active un algorithme de tri partitionné par hachage pour le filtrage des numéros de ligne dans les fenêtres. Cet algorithme présente des problèmes connus de consommation de ressources et entraîne une accumulation de mémoire non classifiée sous la catégorie du module Other.
    
    Solution
    
    Désactivez le paramètre expérimental en exécutant l'instruction SQL suivante :
```
SET hg_experimental_enable_hash_partitioned_sort_v2 = off;
```
    Après avoir désactivé ce paramètre, surveillez l'utilisation de la mémoire de l'instance. La mémoire attribuée au module Other devrait revenir à des niveaux normaux.
- Impacts majeurs
  - Stabilité
    
    Une consommation excessive de mémoire, notamment celle liée aux métadonnées, réduit la mémoire disponible pour les requêtes et peut provoquer des erreurs sporadiques telles que SERVER_INTERNAL_ERROR, ERPC_ERROR_CONNECTION_CLOSED ou Total memory used by all existing queries exceeded memory limitation.
  - Performance
    
    Une utilisation élevée de la mémoire due à un excès de métadonnées épuise l'espace du cache, ce qui réduit les taux de succès du cache et augmente la latence des requêtes.
- Solutions
  - Si une utilisation élevée de la mémoire est causée par un excès de métadonnées : utilisez la table hg_table_info pour gérer vos tables. Pour plus d'informations, reportez-vous à Interroger et analyser les statistiques des tables. Supprimez les données ou les tables inutilisées et réduisez les partitions inutiles pour libérer de la mémoire.
  - Si une utilisation élevée de la mémoire est causée par le calcul : optimisez le code SQL séparément pour les cas d'usage d'écriture et de requête. Pour plus d'informations, reportez-vous à Résoudre les erreurs OOM lors des requêtes et Résoudre les erreurs OOM lors de l'importation et de l'exportation des données.
  - Solution générale : augmentez les ressources de calcul et de stockage. Consultez la page Liste des instances.

Identifier les erreurs OOM

Une erreur OOM se produit lorsque la mémoire de calcul dépasse sa limite allouée (par exemple, 20 Go ou plus). Voici un message d'erreur typique :

Total memory used by all existing queries exceeded memory limitation. 
memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100

Interprétez le message d'erreur comme suit :

queries=(query_id, memory_used_by_query)

Chaque entrée, telle que queries=(2031xxxx,184yy), affiche la consommation de mémoire par requête. Par exemple, queries=(2031xxxx,18441803528) signifie que la requête query_id=2031xxxx a consommé environ 18 Go sur un seul nœud. Les cinq requêtes les plus gourmandes en mémoire sont répertoriées. Pour plus d'informations, reportez-vous à Obtenir et analyser les journaux de requêtes lentes.
Used/Limit: xy1/xy2

Indique compute_memory_used_on_node / compute_memory_limit_on_node en octets. Used correspond à la mémoire de calcul totale consommée par toutes les requêtes en cours d'exécution sur ce nœud. Par exemple, Used/Limit: 33288093696/33114697728 signifie que les requêtes ont utilisé 33,2 Go, dépassant la limite de 33,1 Go et déclenchant une erreur OOM.
quota/sum_quota: zz/100

zz représente le pourcentage des ressources totales de l'instance allouées à un groupe de ressources. Par exemple, quota/sum_quota: 50/100 signifie que le groupe de ressources utilise 50 % des ressources totales de l'instance.

Causes fondamentales des erreurs OOM

Hologres privilégie le calcul en mémoire pour optimiser l'efficacité des requêtes. Contrairement aux systèmes qui déversent les données sur le disque lorsque la mémoire est insuffisante, Hologres génère directement une erreur OOM lorsqu'une requête dépasse la mémoire disponible.

Allocation et limites de la mémoire

Une instance Hologres fonctionne comme un système distribué, composé de plusieurs nœuds dont le nombre varie selon les spécifications de l'instance. Pour plus de détails, reportez-vous à Gestion des instances.

Chaque nœud dispose généralement de 16 vCPU et de 64 Go de mémoire. Une erreur OOM se produit si un seul nœud épuise sa mémoire. Ces 64 Go sont partitionnés pour le calcul des requêtes, les processus backend, le cache et les métadonnées. Avant la version V1.1.24, la mémoire de calcul était plafonnée à 20 Go. À partir de la version V1.1.24, la mémoire disponible est allouée dynamiquement aux requêtes lorsque la consommation de métadonnées est faible.

Résoudre les erreurs OOM lors des requêtes

Causes.
- Plans d'exécution incorrects : cela peut être dû à des statistiques imprécises, à un ordre de jointure inapproprié ou à d'autres problèmes d'optimisation.
- Concurrence élevée des requêtes : de nombreuses requêtes consomment simultanément une quantité importante de mémoire.
- Requêtes complexes : requêtes intrinsèquement complexes ou balayant de grands volumes de données.
- Opérations UNION ALL : les requêtes contenant UNION ALL peuvent augmenter le parallélisme de l'exécuteur, entraînant une utilisation plus élevée de la mémoire.
- Allocation insuffisante du groupe de ressources : un groupe de ressources est configuré mais les ressources allouées sont inadéquates.
- Biais de données ou élagage des shards (shard pruning) : ces facteurs peuvent provoquer un déséquilibre de la charge et une forte pression sur la mémoire de nœuds spécifiques.

Analyse et solutions :

Cause : allocation insuffisante du groupe de ressources

Solution : utilisez la fonctionnalité Serverless Computing pour compléter les ressources dédiées de votre instance avec une capacité de calcul supplémentaire. Pour une vue d'ensemble et les instructions d'utilisation, reportez-vous à Serverless computing et Utiliser Serverless Computing.

Dans Hologres V3.0 et versions ultérieures, Query Queues relance automatiquement les requêtes OOM sur les ressources Serverless Computing. Consultez la section Contrôler les requêtes volumineuses.

Cause : plan d'exécution incorrect

Type 1 : statistiques imprécises

Exécutez EXPLAIN <SQL> pour afficher le plan d'exécution. L'indication rows=1000 signale des statistiques manquantes ou imprécises, conduisant à un plan d'exécution inefficace qui consomme des ressources excessives et déclenche une erreur OOM.

tt=# explain  select count(1) from tmp join tmp1 on tmp.a = tmp1.b;
                                    QUERY PLAN
----------------------------------------------------------------------------------
Partial Aggregate  (cost=0.00..10.11 rows=1 width=8)
  ->  Gather Motion  (cost=0.00..10.11 rows=10 width=8)
    ->  Partial Aggregate  (cost=0.00..10.11 rows=10 width=8)
      ->  Hash Join  (cost=0.00..10.11 rows=1 width=1)
            Hash Cond: (tmp.a = tmp1.b)
            ->  Parallelism (Gather Exchange)  (cost=0.00..5.04 rows=1000 width=1)
                  ->  DecodeNode  (cost=0.00..5.04 rows=1000 width=1)
                        ->  Seq Scan on tmp  (cost=0.00..5.01 rows=1000 width=1)
            ->  Hash  (cost=5.04..5.04 rows=1000 width=1)
                  ->  Parallelism (Gather Exchange)  (cost=0.00..5.04 rows=1000 width=1)
                        ->  DecodeNode  (cost=0.00..5.04 rows=1000 width=1)
                              ->  Seq Scan on tmp1  (cost=0.00..5.01 rows=1000 width=1)
Optimizer: HQO version 0.8.0
(13 rows)

Les solutions incluent les éléments suivants :

Exécutez la commande ANALYZE <tablename> pour mettre à jour les statistiques de la table.
Activez Auto Analyze pour mettre à jour automatiquement les statistiques. Pour plus d'informations, reportez-vous à ANALYZE et AUTO ANALYZE.

Type 2 : ordre de jointure incorrect

Dans une jointure par hachage (Hash Join), la table la plus petite doit constituer le côté de construction (build side). Utilisez EXPLAIN <SQL> pour vérifier le plan d'exécution. Si la table la plus grande construit la table de hachage, l'ordre de jointure est inefficace et peut provoquer une erreur OOM. Raisons courantes :

Statistiques de table obsolètes. Par exemple, les statistiques de la table supérieure n'ont pas été mises à jour, ce qui entraîne l'affichage de rows=1000.

Dans le plan d'exécution, le nœud Result situé à gauche de la jointure Hash Left Join affiche un nombre estimé de lignes de seulement 1 000, tandis que le côté de construction du hachage (Hash build side) à droite affiche un nombre estimé de lignes atteignant 6 754 108 416 (environ 6,75 milliards). Cet écart important indique que la grande table a été utilisée pour construire la table de hachage.

Gather  (cost=0.00..56428622.14 rows=6754109416 width=496)
  -> Insert  (cost=0.00..49020180.01 rows=6754109416 width=496)
    -> Result  (cost=0.00..79269.98 rows=6754109416 width=742)
      -> Hash Left Join  (cost=0.00..54211.24 rows=6754109416 width=660)
            Hash Cond: (row_pk = dws_tb_crm_itm_prf_exp_analysis_nd.row_pk)
            -> Result  (cost=0.00..7.03 rows=1000 width=600)
                  -> Redistribution  (cost=0.00..6.01 rows=1000 width=496)
                        -> Result  (cost=0.00..6.00 rows=1000 width=496)
                              Filter: ((ds = ‘${bizdate}’::text) AND (NOT (row_pk IS NULL)))
                              -> Forward  (cost=0.00..6.00 rows=1000 width=504)
                                    -> Sequence  (cost=0.00..5.00 rows=1000 width=504)
                                          -> Partition Selector for dws_tb_crm_itm_prf_exp_analysis_nd_extl (dynamic scan id: 1)  (cost=10.00..100.00 rows=100 width=4)
                                                Partitions selected: 0 (out of 33)
                                          -> DynamicSeqScan  (cost=0.00..5.00 rows=1000 width=504)
            -> Hash  (cost=11717.79..11717.79 rows=6754108416 width=60)
                  -> Exchange (Gather Exchange)  (cost=0.00..11717.79 rows=6754108416 width=60)
                        -> Decode  (cost=0.00..2755.96 rows=6754108416 width=60)
                              -> Seq Scan on dws_tb_crm_itm_prf_exp_analysis_nd  (cost=0.00..871.47 rows=6754108416 width=60)
Optimizer: HQO version 0.10.0
(19 rows)

L'optimiseur n'a pas réussi à générer un plan d'exécution optimal.

Solutions :

Exécutez ANALYZE <tablename> sur toutes les tables impliquées dans la jointure afin de garantir des statistiques à jour. Cela aide l'optimiseur à déterminer l'ordre de jointure correct.

Si l'ordre de jointure reste incorrect après avoir exécuté ANALYZE <tablename>, ajustez un paramètre GUC. Définissez optimizer_join_order = query pour forcer l'optimiseur à suivre la séquence de jointure spécifiée dans l'instruction SQL. Cette approche est particulièrement adaptée aux requêtes complexes.

SET optimizer_join_order = query;
SELECT * FROM a JOIN b ON a.id = b.id; -- Table b is used as the build side of the hash table.

Vous pouvez également ajuster la politique d'ordre de jointure selon vos besoins.

Paramètre

Description

set optimizer_join_order = <value>

Ce paramètre contrôle l'algorithme d'ordre de jointure (Join Order) de l'optimiseur. Valeurs valides :

query : n'effectue aucune transformation de l'ordre de jointure. Les jointures sont exécutées strictement dans l'ordre spécifié dans la requête SQL. Ce paramètre engendre la surcharge d'optimisation la plus faible.
greedy : utilise un algorithme glouton pour explorer les ordres de jointure possibles. Cette option entraîne une surcharge d'optimisation modérée.
exhaustive (par défaut) : utilise un algorithme de planification dynamique pour la transformation de l'ordre de jointure. Il vise à générer le plan d'exécution optimal, mais présente la surcharge d'optimisation la plus élevée.

Type 3 : estimation incorrecte de la table de hachage

Dans une jointure par hachage, l'entrée la plus petite doit construire la table de hachage. Cependant, la complexité de la requête ou des statistiques imprécises peuvent amener le système à sélectionner une relation plus grande comme entrée de construction, créant ainsi une table de hachage surdimensionnée qui déclenche une erreur OOM.

Hash (cost=727353.45..627353.35 , rows=970902134 width=94) représente l'entrée de construction, et rows=970902134 indique le volume de données estimé pour la construction de la table de hachage. Si la table réelle contient moins de données, l'estimation est incorrecte.

Le nœud Hash situé en bas du plan d'exécution affiche un nombre estimé de lignes atteignant rows=970902134 (environ 970 millions de lignes), ce qui est un symptôme typique d'une surestimation sévère ou d'une sélection incorrecte du volume de données du côté Build Side.

-> Broadcast  (cost=0.00..5.17 rows=119488 width=16)
                    -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1867 width=16)
                        -> Decode  (cost=0.00..5.10 rows=1867 width=16)
                            -> Seq Scan on xxx  (cost=0.00..5.00 rows=1867 width=16)
            -> Hash  (cost=5.17..5.17 rows=119488 width=16)
                -> Broadcast  (cost=0.00..5.17 rows=119488 width=16)
                    -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1867 width=16)
                        -> Decode  (cost=0.00..5.10 rows=1867 width=16)
                            -> Seq Scan on xxx  (cost=0.00..5.00 rows=1867 width=16)
        -> Hash  (cost=5.13..5.13 rows=119488 width=8)
            -> Broadcast  (cost=0.00..5.13 rows=119488 width=8)
                -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1867 width=8)
                    -> Decode  (cost=0.00..5.10 rows=1867 width=8)
                        -> Seq Scan on xxx  (cost=0.00..5.00 rows=1867 width=8)
    -> Hash  (cost=5.10..5.10 rows=896 width=3)
        -> Broadcast  (cost=0.00..5.10 rows=896 width=3)
            -> Exchange (Gather Exchange)  (cost=0.00..5.10 rows=14 width=3)
                -> Decode  (cost=0.00..5.10 rows=14 width=3)
                    -> Seq Scan on xxx  (cost=0.00..5.00 rows=14 width=3)
-> Hash  (cost=627353.45..627353.45 rows=970902134 width=94)
    -> Partial HashAggregate  (cost=0.00..627353.45 rows=970902134 width=94)

Solutions :

Vérifiez les statistiques : contrôlez si les statistiques de la table de la sous-requête sont actuelles et exactes. Sinon, exécutez ANALYZE <tablename> pour les mettre à jour.
Désactiver l'estimation de la table de hachage : désactivez l'estimation de la table de hachage du moteur d'exécution à l'aide du paramètre suivant :

Remarque
Ce paramètre est défini sur off par défaut. Toutefois, il peut avoir été activé dans certains scénarios de réglage des performances. S'il est actuellement activé, veillez à le redéfinir sur off.
```
SET hg_experimental_enable_estimate_hash_table_size =off;
```

Type 4 : diffusion (broadcasting) d'une grande table

La diffusion copie les données sur tous les shards et n'est efficace que pour les petites tables avec peu de shards. Lors des jointures, l'entrée de construction est diffusée vers chaque shard. Un jeu de données volumineux ou un nombre excessif de shards peut consommer une quantité importante de mémoire, provoquant des erreurs OOM.

Par exemple, une table de 80 millions de lignes peut n'afficher qu'une seule ligne estimée dans le plan d'exécution. La diffusion effective des 80 millions de lignes consomme une mémoire excessive, déclenchant une erreur OOM.

Gather  (cost=0.00..119000614.54 rows=495989952 width=5537)
  ->  Insert  (cost=0.00..112801537.07 rows=495989952 width=5537)
        ->  Redistribution  (cost=0.00..428813.57 rows=991979904 width=2320)
              ->  Result  (cost=0.00..338771.55 rows=991979904 width=2320)
                    ->  Result  (cost=0.00..338771.55 rows=991979904 width=2320)
                          ->  Hash Left Join  (cost=0.00..310003.14 rows=991979904 width=5561)
                                Hash Cond: ((olap_event_1480807263997566978.pub_distinct_id = olap_event_1480807263997566978_new.pub_distinct_id) AND (olap_event_1480807263997566978.pub_event_name = olap_event_1480807263997566978_new.pub_event_name) AND (olap_event_1480807263997566978.uuid = olap_event_1480807263997566978_new.uuid))
                                ->  Exchange (Gather Exchange)  (cost=0.00..68102.40 rows=495989952 width=5537)
                                      ->  Decode  (cost=0.00..65774.92 rows=495989952 width=5537)
                                            ->  Seq Scan on olap_event_1480807263997566978  (cost=0.00..1923.43 rows=495989952 width=5537)
                                ->  Hash  (cost=5.10..5.10 rows=80 width=24)
                                      ->  Broadcast  (cost=0.00..5.10 rows=80 width=24)
                                            ->  Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1 width=24)
                                                  ->  Decode  (cost=0.00..5.10 rows=1 width=24)
                                                        ->  Seq Scan on olap_event_1480807263997566978_new  (cost=0.00..5.00 rows=1 width=24)
Optimizer: HQO version 1.1.0

Solutions :

Vérifiez si le nombre de lignes estimé dans le plan d'exécution correspond à la réalité. Sinon, exécutez ANALYZE tablename pour mettre à jour les statistiques.
Désactivez la diffusion et réécrivez-la en tant qu'opérateur de redistribution à l'aide du paramètre GUC suivant.
```
SET optimizer_enable_motion_broadcast = off;
```

Cause : concurrence élevée des requêtes
Si le QPS augmente considérablement, ou si l'erreur OOM affiche HGERR_detl memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); avec chaque requête utilisant une mémoire minimale, une concurrence élevée est la cause probable. Solutions :
- Réduire la concurrence des écritures : si les opérations d'écriture y contribuent, réduisez leur concurrence. Pour plus d'informations, reportez-vous à Résoudre les erreurs OOM lors de l'importation et de l'exportation des données.
- Mettre en œuvre la séparation lecture/écriture : déployez une architecture de séparation lecture/écriture avec instances principale et secondaire (stockage partagé).
- Augmenter les spécifications de calcul de votre instance.
Cause : requête complexe
Si une seule requête déclenche une erreur OOM en raison de sa complexité ou d'un volume de données important, envisagez les approches suivantes :
- Pré-calculer les données : écrivez les données pré-calculées dans Hologres pour éviter les opérations ETL à grande échelle au sein de Hologres.
- Ajoutez des conditions de filtre.
- Optimiser le code SQL : utilisez des techniques telles que Fixed Plan ou l'optimisation Count Distinct. Pour plus d'informations, reportez-vous à Optimiser les performances des requêtes sur les tables internes.
Cause : UNION ALL

Comme illustré ci-dessous, lorsqu'une instruction SQL contient de nombreuses sous-requêtes UNION ALL, l'exécuteur les traite simultanément. Cela peut surcharger la mémoire et provoquer une erreur OOM.
```
subquery1 UNION ALL subquery2 UNION ALL subquery3 ...
```
Solution : forcez l'exécution sérielle à l'aide des paramètres suivants pour atténuer les erreurs OOM. Notez que cela ralentira les performances des requêtes.
```
SET hg_experimental_hqe_union_all_type=1;
SET hg_experimental_enable_fragment_instance_delay_open=on;
```
Cause : configuration inadéquate du groupe de ressources
Une erreur OOM indique : memory usage for existing queries=(3019xxx,37yy)(3022xxx,37yy)(3023xxx,35yy)(4015xxx,30yy)(2004xxx,2yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100. Si zz est faible — par exemple, 10 (seulement 10 % des ressources allouées) — les requêtes de ce groupe disposent d'une mémoire limitée, augmentant la probabilité d'erreurs OOM.
```
AcquireOrRelease] HGERR code 53200 HGERR msge Total memory used by all existing queries
exceeded memory limitation. HGERR detl memory usage for existing
queries=(7001xxx 5,4367295472)(673125xxx9,1701576)(6731xxx 3,3590736)(6731xxx 5,3510024) (673116xxx ,3088256
Used/Limit: 4408213504/42552795136 quota/sum_quota: 10/100.
```
Solution : réinitialisez le quota du groupe de ressources. Allouez au moins 30% des ressources totales de l'instance à chaque groupe de ressources.
Cause : biais de données ou élagage des shards
Si l'utilisation globale de la mémoire est faible mais qu'une erreur OOM se produit toujours, un biais de données ou l'élagage des shards peut concentrer la pression sur la mémoire sur des nœuds spécifiques.

Remarque
L'élagage des shards (shard pruning) est une technique d'optimisation des requêtes qui analyse uniquement un sous-ensemble de shards, plutôt que tous.
- Vérifiez la présence d'un biais de données : utilisez la requête SQL suivante. Le champ hg_shard_id est un champ masqué intégré dans chaque table qui indique le shard où réside chaque ligne.
```
SELECT hg_shard_id, count(1) FROM t1 GROUP BY hg_shard_id;
```
- Inspectez l'élagage des shards : examinez le plan d'exécution pour détecter des indications d'élagage des shards. Par exemple, si le sélecteur de shard affiche l0[1], cela signifie que seules les données d'un shard spécifique ont été sélectionnées pour la requête.
```
-- The distribution key is x. Based on the filter condition x=1, you can quickly locate the shard.
SELECT count(1) FROM bbb WHERE x=1 GROUP BY y;
```
```
                          QUERY PLAN
--------------------------------------------------------------
Result  (cost=0.00..5.10 rows=1 width=8)
  ->  HashAggregate  (cost=0.00..5.10 rows=1 width=8)
        Group Key: y
        ->  Exchange (Gather Exchange)  (cost=0.00..5.10 rows=1 width=4)
            ->  Decode  (cost=0.00..5.10 rows=1 width=4)
                ->  Seq Scan on bbb  (cost=0.00..5.00 rows=1 width=4)
                      Filter: (x = 1)
                      Shard Selector(Eagerly):
                        ->: l0 [1]
Optimizer: HQO version 1.3.0
(10 rows)
```
Solutions :
- Concevez une clé de distribution appropriée pour éviter le biais de données.
- Si la logique métier entraîne intrinsèquement un biais de données, modifiez la logique de l'application en conséquence.
Cause : GROUP BY multi-étapes à cardinalité élevée

Dans Hologres V3.0 et versions ultérieures, les agrégations multi-étapes sur des données à cardinalité élevée peuvent provoquer des erreurs OOM lorsque les colonnes GROUP BY ne s'alignent pas avec la clé de distribution (la clé de distribution n'est pas un sous-ensemble de la clé GROUP BY). Chaque instance concurrente maintient une grande table de hachage, créant une forte pression sur la mémoire. Pour atténuer ce problème, définissez le paramètre suivant :
```
-- Use a GUC parameter to set the maximum number of rows in the aggregation hash table. The following SQL statement indicates that the partial_agg_hash_table can have a maximum of 8192 rows. The default value is 0, which indicates no limit.
SET hg_experimental_partial_agg_hash_table_size = 8192;
```

Résoudre les erreurs OOM lors de l'importation et de l'exportation des données

Des erreurs OOM peuvent survenir lors des transferts de données dans Hologres, y compris entre les tables internes, lors des interactions avec les tables externes et lors des importations depuis MaxCompute.

Solution 1 : utiliser Serverless Computing pour les importations et les exportations

Utilisez Serverless Computing pour compléter les ressources de votre instance lors des tâches d'importation et d'exportation, évitant ainsi la contention des ressources. Pour une vue d'ensemble, consultez Serverless computing. Pour les instructions d'utilisation, consultez Utiliser Serverless Computing.

Solution 2 : contrôler la concurrence de balayage pour les tables larges ou les colonnes larges

Lors des importations depuis MaxCompute, des erreurs OOM peuvent survenir en raison de tables larges ou de colonnes larges combinées à une concurrence de balayage élevée. Utilisez les paramètres suivants pour contrôler la concurrence.

Contrôler la concurrence de balayage pour les tables larges (scénario courant)

Remarque

Appliquez les paramètres suivants conjointement avec votre instruction SQL. Priorisez les deux premiers paramètres. Si une erreur OOM persiste, réduisez davantage leurs valeurs.

-- Set the maximum concurrency for accessing foreign tables. The default value equals the instance's vCPU count. The maximum value is 128. Do not set a large value to prevent queries on foreign tables, especially in data import scenarios, from affecting other queries and causing system busy errors. This parameter is effective in Hologres V1.1 and later.
SET hg_foreign_table_executor_max_dop = 32;

-- Adjust the batch size for each read from a MaxCompute table. The default value is 8192.
SET hg_experimental_query_batch_size = 4096;

-- Set the maximum concurrency for executing DML statements when accessing foreign tables. The default value is 32. This parameter is optimized for data import and export scenarios to prevent import operations from consuming excessive system resources. This parameter is effective in Hologres V1.1 and later.
SET hg_foreign_table_executor_dml_max_dop = 16;

-- Set the split size for accessing MaxCompute tables. This parameter can adjust concurrency. The default value is 64 MB. If the table is large, increase this value to prevent too many splits from affecting performance. This parameter is effective in Hologres V1.1 and later.
SET hg_foreign_table_split_size = 128;

Contrôler la concurrence de balayage pour les colonnes larges
Si vous avez déjà ajusté les paramètres pour les tables larges mais que vous rencontrez toujours des erreurs OOM, vérifiez si vos données incluent des colonnes larges. Si tel est le cas, ajustez les paramètres suivants pour résoudre le problème.
```
-- Adjust the shuffle parallelism for wide columns to reduce data accumulation.
SET hg_experimental_max_num_record_batches_in_buffer = 32;

-- Adjust the batch size for each read from a MaxCompute table. The default value is 8192.
SET hg_experimental_query_batch_size=128;
```

Cause : données dupliquées excessives dans une table externe

Lorsqu'une table externe contient une quantité substantielle de données dupliquées, les performances d'importation se dégradent et peuvent provoquer des erreurs OOM. Par exemple, une table de 100 millions de lignes comportant 80 millions de doublons est hautement dupliquée. Évaluez la duplication en fonction de votre contexte métier.

Solution : dédupliquez les données avant l'importation, ou importez-les par lots plus petits.

Quelles sont les causes de l'erreur « The shards are incomplete, the workers or shards are unhealthy » ?

Cette erreur n'est généralement pas causée directement par un problème de mémoire insuffisante (OOM). Elle survient lorsque l'utilisation du CPU de l'instance Hologres est excessivement élevée, ce qui entraîne l'état « unhealthy » (malsain) des nœuds Worker ou des Shards.

Pour résoudre ce problème :

Vérifiez les métriques de surveillance de l'instance Hologres pour confirmer si l'utilisation du CPU est élevée.
Si l'utilisation du CPU est élevée, attendez que la charge de travail diminue, puis réessayez la requête.
Si l'erreur persiste, vérifiez si des requêtes complexes ou une concurrence excessive saturant le CPU en sont la cause. Optimisez les requêtes gourmandes en ressources ou réduisez la concurrence pour diminuer l'utilisation du CPU.