FAQ e solução de problemas para métricas de monitoramento do Hologres - Hologres: Central de Documentação do Alibaba Cloud

Esta página aborda perguntas frequentes sobre as métricas de monitoramento do Hologres, incluindo alto uso de CPU, pressão de memória, consultas lentas e desempenho de gravação.

Como visualizar e encerrar conexões quando o número de conexões está muito alto?

As conexões incluem todas as conexões SQL em uma instância — ativas e ociosas — provenientes de Java Database Connectivity (JDBC) ou PSQL. Se você encontrar um dos erros a seguir, a instância atingiu o limite de conexões:

FATAL: sorry, too many clients already connection limit exceeded for superusers
FATAL: remaining connection slots are reserved for non-replication superuser connections

Visualize as conexões atuais no HoloWeb ou por meio de SQL. Para mais detalhes, consulte Gerenciar conexões. Em seguida, use uma conta de superusuário para encerrar conexões inesperadas ou ociosas.

O que fazer se a latência da consulta estiver muito alta?

Comece identificando as instruções SQL lentas no log de consultas lentas. Para mais detalhes, consulte Obter e analisar logs de consultas lentas. Depois, resolva o problema conforme sua situação:

Baixo QPS (consultas por segundo), mas SQL complexo: Otimize as instruções SQL e defina índices adequados. Consulte Otimizar o desempenho de consultas em tabelas internas e Acelerar consultas do MaxCompute.
Alto QPS: Se o SQL já estiver otimizado, mas você precisar de maior QPS e menor latência, aumente a escala da instância. Consulte Instâncias.

Operações de gravação afetando o desempenho das consultas: Execute operações de gravação fora dos horários de pico de consultas ou reduza a concorrência de gravação. Para tabelas externas do MaxCompute, use os parâmetros a seguir para reduzir a concorrência:

-- Limit MaxCompute execution concurrency. Default: 128. A lower value prevents one query from affecting others.
SET hg_experimental_foreign_table_executor_max_dop = 32;

-- Reduce the batch size for each read from a MaxCompute table. Default: 8192.
SET hg_experimental_query_batch_size = 1024;

-- Read ORC files directly.
SET hg_experimental_enable_access_odps_orc_via_holo = on;

-- Increase the split size for large MaxCompute tables to reduce the number of concurrent tasks. Default: 64 MB.
SET hg_experimental_foreign_table_split_size = 512MB;

O que causa alto uso de memória e como resolver?

O Hologres utiliza um modelo de reserva de memória: mesmo sem consultas ativas, metadados, índices e caches de dados são carregados na memória para acelerar a recuperação. Um uso de memória entre 30% e 40% é normal quando não há consultas em execução.

Quando o uso de memória sobe continuamente em direção a 80%, isso geralmente indica uma das duas situações a seguir:

Volume de dados crescente: O número de tabelas e o total de dados excederam em muito os recursos de computação atuais. O uso de memória aumenta proporcionalmente à quantidade de metadados e índices.
Tabelas com excesso de índices: Tabelas com muitas colunas, sendo a maioria do tipo TEXT, e com índices bitmap ou dicionário excessivos consomem memória de forma desproporcional.

O uso sustentado de memória próximo a 80% pode causar problemas de estabilidade — erros como SERVER_INTERNAL_ERROR, ERPC_ERROR_CONNECTION_CLOSED ou Total memory used by all existing queries exceeded memory limitation — e degradação de desempenho, como redução na taxa de acerto de cache e maior latência nas consultas.

Para resolver esse problema:

Exclua dados não utilizados para liberar a memória ocupada por metadados.
Remova índices desnecessários: Se índices bitmap ou dicionário não forem utilizados em sua carga de trabalho, remova-os usando ALTER TABLE. Analise seus requisitos de negócio antes de remover qualquer índice.
Atualize os recursos de computação e armazenamento:
- Cenários gerais: 1 unidade de computação (CU) — 1 vCPU + 4 GB de memória — suporta de 50 a 100 GB de armazenamento de dados.
- Serviço de baixa latência: Para obter o melhor desempenho, os dados quentes devem caber no cache de memória. O cache ocupa 30% da memória total; portanto, uma instância de 1 CU fornece 1,3 GB para o cache de dados. Para 100 GB de dados quentes, você precisa de pelo menos 320 GB de memória (96 CUs ou mais).

Por que o uso de CPU de uma instância do Hologres atinge 100% com apenas uma tarefa?

O Hologres foi projetado para utilizar totalmente a computação paralela multinúcleo. Uma única consulta pode elevar o uso de CPU a 100%, o que significa que os recursos de computação estão sendo totalmente aproveitados. Esse é um comportamento esperado, não um problema. O problema surge apenas quando o alto uso de CPU causa lentidão em consultas ou gravações. Consulte O que fazer se o uso de CPU permanecer em 100% por muito tempo? para saber como diagnosticar e resolver essa situação.

Como resolver gravações lentas?

Se os comandos INSERT, INSERT ON CONFLICT ou UPDATE estiverem demorando muito, a causa mais provável é que o SQL não esteja utilizando um Fixed Plan. O SQL sem Fixed Plan está sujeito a bloqueios de tabela: durante a execução concorrente, cada instrução aguarda o bloqueio, causando longos tempos de execução. Na métrica de monitoramento Real-time Write RPS, essas operações aparecem como tipo de gravação insert.

Para resolver, reescreva o SQL para usar um Fixed Plan. O tipo de gravação na métrica Real-time Write RPS mudará para SDK, e o desempenho melhorará. Para mais detalhes, consulte Acelerar a execução de SQL com fixed plans.

O que fazer se o uso de CPU permanecer em 100% por muito tempo?

O uso elevado e sustentado de CPU — 100% por 3 horas consecutivas ou mais, ou acima de 90% por 12 horas consecutivas ou mais — indica que a CPU se tornou um gargalo do sistema. Realize as verificações a seguir em ordem.

Verificação 1: O QPS ou RPS aumentou significativamente?

Compare as métricas de QPS e RPS antes e depois do pico de CPU. Se houver uma tendência clara de alta:

Para picos impulsionados por SELECT: use o log de consultas lentas para encontrar consultas de longa duração e otimize-as.
Para picos impulsionados por INSERT/UPDATE/DELETE: verifique se essas operações estão ignorando o Fixed Plan. O SQL sem Fixed Plan causa bloqueios de tabela e esperas por bloqueio durante a execução concorrente.
```
-- Find INSERT/UPDATE/DELETE operations that did not use a Fixed Plan in the last 3 hours.
SELECT *
FROM hologres.hg_query_log
WHERE query_start >= now() - INTERVAL '3 h'
  AND command_tag IN ('INSERT', 'UPDATE', 'DELETE')
  AND 'HQE' = ANY(engine_type)
ORDER BY query_start DESC
LIMIT 500;
```
Se aplicável, reescreva essas instruções para usar um Fixed Plan. Se todo o SQL já estiver otimizado, escale horizontalmente a instância ou implante a divisão de leitura/gravação. Consulte Atualizar uma instância ou Implantar instâncias primárias e secundárias para divisão de leitura/gravação (armazenamento compartilhado).

Verificação 2: Existem consultas de longa duração?

Se o QPS e o RPS estiverem estáveis, mas a CPU apresentar picos repentinos, verifique a métrica Running Query Duration. Consultas em execução por mais de 30 minutos ou uma hora provavelmente estão consumindo CPU continuamente. Execute o comando a seguir para encontrá-las e cancelá-las:

-- Find long-running queries.
SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, pid::text
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY 1 DESC;

-- Cancel a query.
SELECT pg_cancel_backend(<pid>);

Verificação 3: Existem consultas com alto consumo de CPU?

Use o log de consultas lentas para encontrar as consultas que mais consomem CPU, memória e I/O:

-- Find high-resource queries in the last 3 hours.
SELECT
  status                                    AS "Status",
  duration                                  AS "Duration (ms)",
  query_start                               AS "Start time",
  (read_bytes / 1048576)::text || ' MB'     AS "Read volume",
  (memory_bytes / 1048576)::text || ' MB'   AS "Memory",
  (shuffle_bytes / 1048576)::text || ' MB'  AS "Shuffle",
  (cpu_time_ms / 1000)::text || ' s'        AS "CPU time",
  physical_reads                            AS "Disk reads",
  query_id                                  AS "Query ID",
  query
FROM hologres.hg_query_log
WHERE query_start > current_timestamp - INTERVAL '3 h'
  AND command_tag IN ('SELECT', 'INSERT', 'UPDATE', 'DELETE')
  AND duration > 1000
ORDER BY duration DESC,
         read_bytes DESC,
         shuffle_bytes DESC,
         memory_bytes DESC,
         cpu_time_ms DESC,
         physical_reads DESC
LIMIT 500;

Otimize as consultas identificadas.

Verificação 4: Novas consultas PQE estão aparecendo?

Verifique se novas consultas PQE surgiram no momento em que o uso de CPU aumentou:

-- Find queries that used PQE in the last 3 hours.
SELECT *
FROM hologres.hg_query_log
WHERE query_start > current_timestamp - INTERVAL '3 h'
  AND 'PQE' = ANY(engine_type)
ORDER BY query_start DESC
LIMIT 500;

Se existirem consultas PQE, otimize os operadores SQL para reduzir ou eliminar o uso de PQE. Consulte Otimizar o desempenho de consultas.

Verificação 5: Índices bitmap ou dicionário foram modificados recentemente?

A modificação de índices bitmap ou dicionário em uma tabela aciona um processo assíncrono de compactação em segundo plano que consome CPU. O uso de armazenamento normalmente aumenta primeiro e depois diminui conforme a compactação termina. Verifique se houve alterações recentes nos índices:

-- Find index modification records in the last 3 hours.
SELECT *
FROM hologres.hg_query_log
WHERE query_start >= now() - INTERVAL '3 h'
  AND command_tag IN ('CALL')
ORDER BY query_start DESC
LIMIT 500;

Como lidar com consultas de longa duração?

A métrica Running Query Duration mostra consultas que estão em execução há mais tempo do que o esperado — por exemplo, mais de 1 hora. Visualize a página Active Query Tasks para ver o que está em execução no momento. Para mais detalhes, consulte Gerenciar consultas.

Consultas de longa duração geralmente se enquadram em um dos quatro padrões a seguir:

Operações de gravação contínuas: Visualize a métrica Real-time Write RPS para identificar se gravações em massa contínuas estão retendo recursos.

Ocioso em transação: Um cliente abriu uma transação e executou uma operação DDL, mas não a confirmou. O status da consulta aparece como idle in transaction em pg_stat_activity. Para encontrar essas sessões:

-- Find long-running queries, including idle-in-transaction sessions.
SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, pid::text
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY 1 DESC;

Feche a transação no cliente ou defina um tempo limite para transações ociosas. Consulte Modificar tempo limite de consulta ociosa. Para cancelar uma consulta travada:

SELECT pg_cancel_backend(<pid>);

SQL complexo usando PQE: Execute EXPLAIN <sql> para verificar o plano de execução. Se a saída contiver External SQL (Postgres), a consulta está usando PQE e pode ser executada lentamente. Encerre a consulta e otimize o SQL para reduzir o uso de PQE. Consulte Otimizar o desempenho de consultas em tabelas internas.

DDL concorrente causando contenção de bloqueio: Operações DDL bloqueiam tabelas. Quando várias instruções DDL são executadas simultaneamente, elas criam contenção de bloqueio e longas esperas. Verifique se há DDL em andamento:

SELECT datname::text, usename, query, pid::text, state
FROM pg_stat_activity
WHERE state != 'idle';

Encerre quaisquer operações DDL bloqueantes para liberar os bloqueios e execute as instruções DDL sequencialmente.

Como solucionar falhas em consultas?

A métrica Failed Queries mostra o número de consultas com falha por segundo. Não use apenas o QPS para estimar o número total de falhas — o total corresponde à área sob a curva (intervalo de tempo x QPS). Use o log de consultas lentas para obter a contagem exata e os motivos das falhas e, em seguida, resolva com base nos erros específicos. Consulte Visualizar e analisar logs de consultas lentas.

Como resolver carga desigual de CPU entre workers?

No Hologres, os dados são particionados em shards. Um worker processa um ou mais shards por vez, e cada shard pode ser acessado por apenas um worker de cada vez. A carga desigual geralmente decorre de três causas:

Distorção de dados: Se um shard contiver muito mais dados do que os outros, o worker atribuído a ele suportará uma carga desproporcional. Verifique se há distorção:

SELECT hg_shard_id, count(1) FROM <table_name> GROUP BY hg_shard_id;

-- Example output showing skew: shard 39 holds significantly more rows than others.
-- hg_shard_id | count
-- -------------+--------
--           53 |  29130
--           65 |  28628
--           66 |  26970
--           70 |  28767
--           77 |  28753
--           24 |  30310
--           15 |  29550
--           39 | 164983

Trate os dados distorcidos ou defina uma chave de distribuição adequada. Consulte Otimizar o desempenho de consultas.

Contagem de shards não é múltipla da contagem de workers: Quando a contagem de shards em um grupo de tabelas não é um múltiplo inteiro da contagem total de workers, alguns workers recebem mais shards do que outros. Defina uma contagem de shards apropriada com base nas especificações da instância. Consulte Gerenciar grupos de tabelas e contagens de shards. Isso afeta principalmente instâncias grandes (mais de 256 núcleos). Para instâncias menores, a contagem padrão de shards é suficiente.

Redistribuição desigual após reinicialização de um worker: Quando um worker é encerrado devido a um erro de falta de memória (OOM) ou outros motivos, o sistema migra rapidamente os shards desse worker para outros workers a fim de recuperar prontamente as consultas. Quando o worker é reiniciado, o sistema realoca alguns shards para ele. Se a carga da instância for baixa, esse desequilíbrio é inofensivo. Se a carga for alta, reinicie a instância para redistribuir os shards uniformemente.