FAQ and troubleshooting for Hologres monitoring metrics - Hologres: Central de Documentação do Alibaba Cloud

Esta página aborda as perguntas mais frequentes sobre as métricas de monitoramento do Hologres, incluindo uso elevado 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 é muito alto?

Isso abrange todas as conexões SQL de uma instância — ativas e ociosas — provenientes de Java Database Connectivity (JDBC) ou PSQL. Se você se deparar com um dos seguintes erros, 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 SQL, e gerencie as conexões conforme necessário. Para mais detalhes, visualize Gerencie conexões. Em seguida, use uma conta de superusuário para encerrar conexões inesperadas ou ociosas.

O que fazer se a latência das consultas for muito alta?

Selecione as instruções SQL lentas no log de consultas e atualize as estatísticas. Para mais detalhes, consulte Get and analyze slow query logs. Em seguida, resolva o problema conforme o seu cenário:

QPS (consultas por segundo) baixo, mas SQL complexo: Otimize as instruções SQL e defina índices adequados. Consulte Optimize internal table query performance e Accelerate MaxCompute queries.
QPS alto: Se o SQL já estiver otimizado, mas você precisar de um QPS maior e menor latência, aumente a capacidade da instância. Consulte Instances.

Operações de gravação afetando o desempenho da consulta: 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 seguintes parâmetros 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 o uso elevado de memória e como resolver?

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

Quando o uso de memória sobe constantemente em direção aos 80%, isso geralmente indica um de dois cenários:

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

O uso contínuo de memória próximo a 80% pode causar problemas de estabilidade, como os erros SERVER_INTERNAL_ERROR, ERPC_ERROR_CONNECTION_CLOSED ou Total memory used by all existing queries exceeded memory limitation, além de degradação de desempenho, como taxa de acerto de cache reduzida e maior latência de consulta.

Para resolver isso:

Libere a memória ocupada por metadados e exclua dados não utilizados.
Remova índices desnecessários: Se os índices de bitmap ou dicionário não forem usados em sua carga de trabalho, remova-os usando ALTER TABLE. Analise os requisitos do seu 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.
- Cenários de baixa latência: Para obter o melhor desempenho, o hot data precisa 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 hot data, 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 aproveitar ao máximo a computação paralela multicore. Uma única consulta pode elevar o uso de CPU a 100%, o que significa apenas que os recursos de computação estão totalmente utilizados. Esse é um comportamento esperado, não um problema. O problema surge apenas quando o uso elevado de CPU causa lentidão nas consultas ou gravações. Consulte What do I do if CPU usage remains at 100% for a long time? para saber como diagnosticar e resolver esse problema.

Como resolver gravações lentas?

Se os comandos INSERT, INSERT ON CONFLICT ou UPDATE demorarem muito, a causa mais provável é que o SQL não utilize um Fixed Plan. O SQL sem Fixed Plan está sujeito a bloqueios de tabela: sob execução concorrente, cada instrução aguarda o bloqueio, o que causa 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 isso, reescreva o SQL para utilizar um Fixed Plan. O tipo de gravação na métrica Real-time Write RPS muda para SDK e o desempenho melhora. Para mais detalhes, consulte Accelerate SQL execution with fixed plans.

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

O uso elevado e contínuo de CPU (100% por 3 ou mais horas consecutivas, ou acima de 90% por 12 ou mais horas consecutivas) indica que a CPU se tornou um gargalo do sistema. Realize as seguintes verificações 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 aumento:

Para picos causados por SELECT: use o log de consultas lentas para encontrar consultas de longa duração e otimize-as.
Para picos causados por INSERT/UPDATE/DELETE: verifique se essas operações ignoram o Fixed Plan. O SQL sem Fixed Plan causa bloqueios de tabela e espera por bloqueios sob 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 a instância horizontalmente ou implemente a separação de leitura e gravação. Consulte Upgrade an instance ou Deploy primary and secondary instances for read/write splitting (shared storage).

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

Se o QPS e o RPS estiverem estáveis, mas a CPU apresentar um pico repentino, verifique a métrica Running Query Duration. Consultas em execução por mais de 30 minutos ou uma hora provavelmente consomem CPU continuamente. Execute o seguinte código para encontrá-las e cancele as consultas:

-- 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: Existem novas consultas PQE?

Verifique se novas consultas PQE apareceram no período 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 houver consultas PQE, otimize os operadores SQL para reduzir ou eliminar o uso de PQE. Consulte Optimize query performance.

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

Modificar índices de bitmap ou dicionário em uma tabela aciona um processo de compactação assíncrono em segundo plano que consome CPU. O uso de armazenamento geralmente 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 em execução há mais tempo que o esperado, por exemplo, mais de 1 hora. Verifique a página Active Query Tasks para visualizar o que está em execução no momento. Para mais detalhes, consulte Gerencie consultas.

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

Operações de gravação contínuas: Verifique a métrica Real-time Write RPS para ver se gravações em massa contínuas retêm recursos.

Idle in transaction: Um cliente abriu uma transação e executou uma operação DDL, mas não executou o commit. O status da consulta aparece como idle in transaction em pg_stat_activity. Para encontrar essas consultas:

-- 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 modifique o tempo limite para transações ociosas. Consulte Modifique o tempo limite de consulta ociosa. Cancele uma consulta travada:

SELECT pg_cancel_backend(<pid>);

SQL complexo com PQE: Execute EXPLAIN <sql> para verificar o plano de execução. Se a saída contiver External SQL (Postgres), a consulta usa PQE e pode ter execução lenta. Encerre a consulta, crie e otimize o SQL para reduzir o uso de PQE. Consulte Optimize internal table query performance.

DDL concorrente causando contenção de bloqueios: As operações DDL bloqueiam tabelas. A execução simultânea de várias instruções DDL cria contenção de bloqueios e longas esperas. Verifique se há DDLs 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 problemas de consultas com falha?

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 é a á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 resolva com base nos erros específicos. Consulte Visualize e analise logs de consultas lentas.

Como resolver a carga de CPU desigual entre os workers?

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

Data skew: Se um shard armazena muito mais dados que os outros, o worker atribuído a ele carrega uma carga desproporcional. Verifique se há skew:

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

Corrija o skew dos dados ou defina uma chave de distribuição adequada. Consulte Optimize query performance.

A 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 que outros. Defina uma contagem de shards adequada com base nas especificações da instância. Consulte Gerencie 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 a reinicialização de um worker: Quando um worker é encerrado devido a um erro de out of memory (OOM) ou outros motivos, o sistema migra rapidamente os shards desse worker para outros a fim de recuperar as consultas prontamente. Ao reiniciar o worker, o sistema realoca alguns shards para ele. Se a carga da instância estiver baixa, esse desequilíbrio é inofensivo. Se a carga estiver alta, reinicie a instância para redistribuir os shards de forma uniforme.