Troubleshoot OOM errors in Hologres - Hologres: Central de Documentação do Alibaba Cloud

Um erro OOM (Out of Memory) ocorre quando uma consulta excede a memória disponível no Hologres. Este tópico explica como monitorar o uso de memória, identificar erros OOM e resolvê-los.

Analisar o consumo de memória

Visualize o consumo de memória
- Consumo total: O console do Hologres exibe o consumo de memória agregado em todos os nós. Para obter mais informações, consulte Métricas de monitoramento.
- Consumo por consulta: O campo memory_bytes fornece uma estimativa do consumo de memória por consulta. Esse valor pode ser impreciso. Para obter mais informações, consulte Obter e analisar logs de consultas lentas.
Lidar com alto uso de memória

Monitore o uso geral de memória no console do Hologres (consulte Métricas de monitoramento). O uso sustentado acima de 80% é considerado alto. O Hologres pré-aloca memória para metadados e cache, portanto, um uso de 30-50% em estado ocioso é normal. O uso próximo de 100% degrada a estabilidade e o desempenho.
- Causas
  - Alto consumo de memória por metadados
    
    A memória de metadados cresce conforme o volume de tabelas e pode causar alto uso mesmo quando nenhuma tarefa está em execução. Mantenha cada Table Group com menos de 10.000 tabelas (incluindo partições, excluindo tabelas externas). Muitos shards em um Table Group aumentam a fragmentação e a sobrecarga de metadados.
  - Alto consumo de memória por computação
    
    O alto uso de memória em consultas geralmente resulta da varredura de grandes volumes de dados ou de operações complexas, como múltiplas funções COUNT DISTINCT, operações JOIN complexas, GROUP BY em várias colunas ou funções de janela.
  - Alto uso de memória no módulo Other
    
    Quando o monitoramento de memória mostra um aumento repentino no uso de memória do módulo Other, acompanhado de alta utilização geral de memória, a causa pode ser o parâmetro experimental hg_experimental_enable_hash_partitioned_sort_v2. Esse parâmetro ativa um algoritmo de ordenação particionada por hash para filtragem de números de linha de janela. O algoritmo possui problemas conhecidos de consumo de recursos e faz com que memória não classificada se acumule na categoria do módulo Other.
    
    Solução
    
    Desative o parâmetro experimental executando a seguinte instrução SQL:
```
SET hg_experimental_enable_hash_partitioned_sort_v2 = off;
```
    Após desativar esse parâmetro, monitore o uso de memória da instância. A memória atribuída ao módulo Other deve diminuir para níveis normais.
- Principais impactos
  - Estabilidade
    
    O consumo excessivo de memória, especialmente por metadados, reduz a memória disponível para consultas e pode causar erros esporádicos como SERVER_INTERNAL_ERROR, ERPC_ERROR_CONNECTION_CLOSED ou Total memory used by all existing queries exceeded memory limitation.
  - Desempenho
    
    O alto uso de memória devido a metadados excessivos esgota o espaço de cache, reduzindo as taxas de acerto do cache e aumentando a latência das consultas.
- Soluções
  - Se o alto uso de memória for causado por metadados excessivos: Use a tabela hg_table_info para gerencie suas tabelas. Para obter mais informações, consulte Consultar e analisar estatísticas de tabelas. Exclua dados ou tabelas não utilizados e reduza partições desnecessárias para liberar memória.
  - Se o alto uso de memória for causado por computação: Otimize o SQL separadamente para casos de uso de escrita e consulta. Para obter mais informações, consulte Resolver erros OOM durante consultas e Resolver erros OOM durante importação e exportação de dados.
  - Solução geral: Aumente os recursos de computação e armazenamento. Lista de instâncias.

Identificar erros OOM

Um erro OOM ocorre quando a memória de computação excede seu limite alocado (por exemplo, 20 GB ou mais). Uma mensagem de erro típica:

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

Interprete a mensagem de erro da seguinte forma:

queries=(query_id, memory_used_by_query)

Cada entrada, como queries=(2031xxxx,184yy), mostra o consumo de memória por consulta. Por exemplo, queries=(2031xxxx,18441803528) significa que a consulta query_id=2031xxxx consumiu aproximadamente 18 GB em um único nó. As 5 consultas que mais consomem memória são listadas. Para obter mais informações, consulte Obter e analisar logs de consultas lentas.
Used/Limit: xy1/xy2

Mostra compute_memory_used_on_node / compute_memory_limit_on_node em bytes. Used é o total de memória de computação consumida por todas as consultas em execução naquele nó. Por exemplo, Used/Limit: 33288093696/33114697728 significa que as consultas usaram 33,2 GB, excedendo o limite de 33,1 GB e acionando o OOM.
quota/sum_quota: zz/100

zz é a porcentagem do total de recursos da instância alocada para um grupo de recursos. Por exemplo, quota/sum_quota: 50/100 significa que o grupo de recursos usa 50% do total de recursos da instância.

Causas básicas de erros OOM

O Hologres prioriza a computação em memória para obter eficiência ideal nas consultas. Diferentemente de sistemas que descarregam dados no disco quando a memória é insuficiente, o Hologres gera um erro OOM diretamente quando uma consulta excede a memória disponível.

Alocação e limites de memória

Uma instância do Hologres opera como um sistema distribuído, composto por vários nós cuja quantidade varia conforme as especificações da instância. Para obter mais detalhes, consulte Gerenciamento de instâncias.

Cada nó normalmente possui 16 vCPUs e 64 GB de memória. Um erro OOM ocorre se qualquer nó individual esgotar sua memória. Os 64 GB são particionados para computação de consultas, processos de backend, cache e metadados. Antes da versão V1.1.24, a memória de computação era limitada a 20 GB. A partir da V1.1.24, a memória disponível é alocada dinamicamente para consultas quando o consumo de metadados é baixo.

Resolver erros OOM durante consultas

Causas.
- Planos de execução incorretos: Podem ocorrer devido a estatísticas imprecisas, ordem de junção inadequada ou outros problemas de otimização.
- Alta concorrência de consultas: Muitas consultas consumindo substancialmente memória simultaneamente.
- Consultas complexas: Consultas inerentemente complexas ou aquelas que varrem grandes volumes de dados.
- Operações UNION ALL: Consultas contendo UNION ALL podem aumentar o paralelismo do executor, levando a um maior uso de memória.
- Alocação insuficiente de grupo de recursos: Um grupo de recursos está configurado, mas com recursos inadequados alocados.
- Skew de dados ou shard pruning: Podem causar carga desequilibrada e alta pressão de memória em nós específicos.

Análise e soluções:

Causa: Alocação insuficiente de grupo de recursos

Solução: Use o recurso Serverless Computing para complementar os recursos dedicados da sua instância com capacidade de computação adicional. Para obter uma visão geral e instruções de uso, consulte Serverless computing e Trabalhar com serverless computing.

No Hologres V3.0 e posterior, as Query Queues reexecutam automaticamente consultas com OOM em recursos de serverless computing. Controlar consultas grandes.

Causa: Plano de execução incorreto

Tipo 1: Estatísticas imprecisas

Execute EXPLAIN <SQL> para visualizar o plano de execução. rows=1000 indica estatísticas ausentes ou imprecisas, resultando em um plano de execução ineficiente que consome recursos excessivos e aciona um erro 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)

As soluções incluem o seguinte:

Execute o comando ANALYZE <tablename> para atualize as estatísticas da tabela.
Ative o auto analyze para atualize estatísticas automaticamente. Para obter mais informações, consulte ANALYZE e AUTO ANALYZE.

Tipo 2: Ordem de junção incorreta

Em um Hash Join, a tabela menor deve ser o lado de construção (build side). Use EXPLAIN <SQL> para verificar o plano de execução. Se a tabela maior construir a tabela hash, a ordem de junção é ineficiente e pode causar OOM. Motivos comuns:

Estatísticas de tabela desatualizadas. Por exemplo, as estatísticas da tabela superior não foram atualizadas, resultando em rows=1000.

No plano de execução, o nó Result no lado esquerdo do Hash Left Join tem uma contagem estimada de linhas de apenas 1.000, enquanto o lado de construção do Hash à direita tem uma contagem estimada de linhas tão alta quanto 6.754.108.416 (aproximadamente 6,75 bilhões). Essa grande discrepância indica que a tabela grande foi usada para construir a tabela Hash.

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)

O otimizador falhou ao gerar um plano de execução ideal.

Soluções:

Execute ANALYZE <tablename> em todas as tabelas envolvidas na junção para garantir estatísticas atualizadas. Isso ajuda o otimizador a determinar a ordem correta de junção.

Se a ordem de junção permanecer incorreta após executar ANALYZE <tablename>, ajuste um parâmetro GUC. Defina optimizer_join_order = query para forçar o otimizador a seguir a sequência de junção especificada na instrução SQL. Essa abordagem é particularmente adequada para consultas complexas.

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.

Você também pode ajustar a política de ordem de junção conforme necessário.

Parâmetro

Descrição

defina optimizer_join_order = <value>

Este parâmetro controla o algoritmo de Join Order do otimizador. Valores válidos:

query: Não realiza transformação de Join Order. As junções são executadas estritamente na ordem especificada na consulta SQL. Esta configuração incorre na menor sobrecarga do otimizador.
greedy: Emprega um algoritmo guloso para explorar possíveis Join Orders. Esta opção resulta em sobrecarga moderada do otimizador.
exhaustive (padrão): Usa um algoritmo de planejamento dinâmico para transformação de Join Order. Visa gerar o plano de execução ideal, mas apresenta a maior sobrecarga do otimizador.

Tipo 3: Estimativa incorreta da tabela hash

Em um hash join, a entrada menor deve construir a tabela hash. No entanto, a complexidade da consulta ou estatísticas imprecisas podem fazer com que o sistema selecione uma relação maior como entrada de construção, criando uma tabela hash superdimensionada que aciona OOM.

Hash (cost=727353.45..627353.35 , rows=970902134 width=94) representa a entrada de construção, e rows=970902134 indica o volume estimado de dados para construir a tabela hash. Se a tabela real contiver menos dados, a estimativa está imprecisa.

O nó Hash na parte inferior do plano de execução tem uma contagem estimada de linhas tão alta quanto rows=970902134 (aproximadamente 970 milhões de linhas), o que é um sintoma típico de que o volume de dados do Build Side foi severamente superestimado ou selecionado incorretamente.

-> 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)

Soluções:

Verifique as estatísticas: Confirme se as estatísticas da tabela da subconsulta estão atuais e precisas. Caso contrário, execute ANALYZE <tablename> para atualizá-las.
Desative a estimativa da tabela hash: Desligue a estimativa da tabela hash do mecanismo de execução usando o seguinte parâmetro:

Nota
Este parâmetro tem como padrão off. No entanto, ele pode ter sido ativado em certos cenários de ajuste. Se estiver atualmente ativado, certifique-se de defini-lo novamente como off.
```
SET hg_experimental_enable_estimate_hash_table_size =off;
```

Tipo 4: Broadcasting de uma tabela grande

O broadcasting copia dados para todos os shards e é eficiente apenas para tabelas pequenas com poucos shards. Durante junções, a entrada de construção é transmitida para cada shard. Um conjunto de dados grande ou contagem excessiva de shards pode consumir memória substancial, causando erros OOM.

Por exemplo, uma tabela de 80 milhões de linhas pode mostrar apenas 1 linha estimada no plano de execução. O broadcasting real de todas as 80 milhões de linhas consome memória excessiva, acionando 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

Soluções:

Verifique se a contagem estimada de linhas no plano de execução corresponde à realidade. Caso contrário, execute ANALYZE tablename para atualize as estatísticas.
Desative o broadcasting e reescreva-o como um operador de redistribuição usando o seguinte parâmetro GUC.
```
SET optimizer_enable_motion_broadcast = off;
```

Causa: Alta concorrência de consultas
Se o QPS tiver picos significativos, ou se o erro OOM mostrar HGERR_detl memory usage for existing queries=(2031xxxx,184yy)(2021yyyy,85yy)(1021121xxxx,6yy)(2021xxx,18yy)(202xxxx,14yy); com cada consulta usando memória mínima, a alta concorrência é a causa provável. Soluções:
- Reduza a concorrência de escrita: Se as operações de escrita estiverem contribuindo, reduza a concorrência delas. Para obter mais informações, consulte Resolver erros OOM durante importação e exportação de dados.
- Implemente separação de leitura/escrita: Implante uma arquitetura de separação de leitura/escrita com instâncias primárias e secundárias (armazenamento compartilhado).
- Aumente as especificações de computação da sua instância.
Causa: Consulta complexa
Se uma única consulta acionar OOM devido à sua complexidade ou grande volume de dados, considere estas abordagens:
- Pré-compute dados: Grave dados pré-computados no Hologres para evitar operações ETL em larga escala dentro do Hologres.
- Adicione condições de filtro.
- Otimize o SQL: Use técnicas como Fixed Plan ou otimização de Count Distinct. Para obter mais informações, consulte Otimizar o desempenho de consultas de tabelas internas.
Causa: UNION ALL

Conforme mostrado abaixo, quando uma instrução SQL contém muitas subconsultas UNION ALL, o executor as processa simultaneamente. Isso pode sobrecarregar a memória e causar um erro OOM.
```
subquery1 UNION ALL subquery2 UNION ALL subquery3 ...
```
Solução: Force a execução serial usando os seguintes parâmetros para mitigar erros OOM. Esteja ciente de que isso resultará em um desempenho de consulta mais lento.
```
SET hg_experimental_hqe_union_all_type=1;
SET hg_experimental_enable_fragment_instance_delay_open=on;
```
Causa: Configuração inadequada de grupo de recursos
Um erro OOM relata: memory usage for existing queries=(3019xxx,37yy)(3022xxx,37yy)(3023xxx,35yy)(4015xxx,30yy)(2004xxx,2yy); Used/Limit: xy1/xy2 quota/sum_quota: zz/100. Se zz for pequeno — por exemplo, 10 (apenas 10% dos recursos alocados) — as consultas nesse grupo têm memória limitada, aumentando a probabilidade de 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.
```
Solução: Redefina a cota do grupo de recursos. Aloque pelo menos 30% do total de recursos da instância para cada grupo de recursos.
Causa: Skew de dados ou shard pruning
Se o uso geral de memória estiver baixo, mas o OOM ainda ocorrer, o skew de dados ou o shard pruning podem estar concentrando a pressão de memória em nós específicos.

Nota
Shard pruning é uma técnica de otimização de consulta que varre apenas um subconjunto de shards, em vez de todos eles.
- Verifique se há skew de dados: Use a seguinte consulta SQL. O hg_shard_id é um campo oculto integrado em cada tabela que indica o shard onde cada linha reside.
```
SELECT hg_shard_id, count(1) FROM t1 GROUP BY hg_shard_id;
```
- Inspecione o shard pruning: Examine o plano de execução em busca de indicações de Shard Pruning. Por exemplo, se o seletor de shard mostrar l0[1], significa que apenas os dados de um shard específico foram selecionados para a consulta.
```
-- 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)
```
Soluções:
- Projete uma chave de distribuição apropriada para evitar skew de dados.
- Se a lógica de negócios causar inerentemente skew de dados, modifique a lógica do aplicativo adequadamente.
Causa: GROUP BY multiestágio de alta cardinalidade

No Hologres V3.0 e posterior, agregações multiestágio em dados de alta cardinalidade podem causar OOM quando as colunas GROUP BY não estão alinhadas com a chave de distribuição (a chave de distribuição não é um subconjunto da chave GROUP BY). Cada instância concorrente mantém uma grande tabela hash, criando alta pressão de memória. Para mitigar isso, defina o seguinte parâmetro:
```
-- 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;
```

Resolver erros OOM durante importação e exportação de dados

Erros OOM podem ocorrer durante transferências de dados no Hologres, incluindo entre tabelas internas, interações com tabelas externas e importações do MaxCompute.

Solução 1: Use Serverless Computing para importações e exportações

Use o Serverless Computing para complementar os recursos da sua instância em tarefas de importação e exportação, evitando contenção de recursos. Para obter uma visão geral, consulte Serverless computing. Para instruções de uso, consulte Trabalhar com serverless computing.

Solução 2: Controle a concorrência de varredura para tabelas ou colunas largas

Em importações do MaxCompute, erros OOM podem surgir de tabelas ou colunas largas combinadas com alta concorrência de varredura. Use os seguintes parâmetros para controlar a concorrência.

Controle a concorrência de varredura para tabelas largas (cenário comum)

Nota

Aplique os seguintes parâmetros juntamente com sua instrução SQL. Priorize os dois primeiros parâmetros. Se um erro OOM persistir, reduza ainda mais seus valores.

-- 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;

Controle a concorrência de varredura para colunas largas

Se você já ajustou parâmetros para tabelas largas, mas ainda encontra erros OOM, verifique se seus dados incluem colunas largas. Nesse caso, ajuste os seguintes parâmetros para resolver o problema.

-- 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;

Causa: Dados duplicados excessivos em uma tabela externa

Quando uma tabela externa contém dados duplicados substanciais, o desempenho da importação degrada e pode causar erros OOM. Por exemplo, uma tabela de 100 milhões de linhas com 80 milhões de duplicatas é altamente duplicada. Avalie a duplicação com base no contexto do seu negócio.

Solução: Deduplique os dados antes da importação ou importe em lotes menores.

O que causa o erro "The shards are incomplete, the workers or shards are unhealthy"?

Esse erro geralmente não é causado diretamente por um problema de falta de memória (OOM). Ele ocorre quando o uso da CPU da instância do Hologres está excessivamente alto, o que faz com que os nós Worker ou Shards entrem em um estado não saudável.

Para resolver este problema:

Verifique as métricas de monitoramento da instância do Hologres para confirmar se o uso da CPU está elevado.
Se o uso da CPU estiver alto, aguarde a carga de trabalho diminuir e tente execute a consulta novamente.
Se o erro persistir, verifique se consultas complexas ou concorrência excessiva estão causando saturação da CPU. Otimize consultas que consomem muitos recursos ou reduza a concorrência para diminuir o uso da CPU.