Hologres:Detectar e gerenciar a distorção de carga de trabalho

Causa 1: Redistribuição desigual de shard após failover de worker

Quando um worker falha — por exemplo, devido a um erro de falta de memória (OOM) — o sistema move temporariamente os shards desse worker para outros workers. Após a recuperação do worker, alguns shards são movidos de volta, mas a redistribuição pode ser desigual.

Como os workers são compartilhados entre todos os bancos de dados de uma instância enquanto hg_worker_info exibe apenas o banco de dados atual, verifique cada banco de dados separadamente e some os resultados para obter a contagem total de shards por worker na instância.

Diagnóstico

SELECT worker_id, COUNT(1) AS shard_count
FROM hologres.hg_worker_info
GROUP BY worker_id;

Saída de exemplo para uma instância com seis workers:

 worker_id  | shard_count
------------+-------------
 bca90a     |      4
 ea405b     |      4
 tkn4vc     |      4
 bqw5cq     |      3
 mbbrf6     |      3
 hsx66f     |      1
(6 rows)

As contagens de shards diferem significativamente entre os workers — hsx66f tem apenas 1 shard enquanto outros têm 3 ou 4, uma proporção de 4:1. Workers com menos shards geralmente exibem menor utilização de CPU no console do Hologres.

Correção

Reinicie a instância. Isso aciona um rebalanceamento completo de shards entre todos os workers. Sem uma reinicialização, workers ociosos só recebem shards adicionais se outro worker falhar novamente.

Causa 2: Distorção de dados

Quando a maioria das linhas de uma tabela se concentra em um número pequeno de shards, os workers que possuem esses shards processam uma quantidade desproporcional de dados. Isso faz a utilização de CPU deles aumentar abruptamente enquanto outros workers ficam subutilizados.

Diagnóstico

Etapa 1: Verifique a distorção de dados na tabela.

SELECT hg_shard_id, COUNT(1)
FROM <table_name>
GROUP BY hg_shard_id
ORDER BY 2;

Saída de exemplo mostrando uma tabela com distorção — o shard 39 contém aproximadamente cinco vezes mais linhas que os demais:

hg_shard_id | count
-------------+--------
          53 |  29130
          65 |  28628
          66 |  26970
          70 |  28767
          77 |  28753
          24 |  30310
          15 |  29550
          39 | 164983

Etapa 2: Identifique o worker responsável pelo shard com distorção.

Substitua <tablename> e <shard_id> pelos valores da etapa anterior:

SELECT DISTINCT b.table_name, a.worker_id, a.table_group_name, a.shard_id
FROM hologres.hg_worker_info a
JOIN (
    SELECT property_value, table_name
    FROM hologres.hg_table_properties
    WHERE property_key = 'table_group'
) b
ON a.table_group_name = b.property_value
AND b.table_name = '<tablename>'
AND shard_id = <shard_id>;

Saída de exemplo:

table_name  | worker_id  | table_group_name  | shard_id
------------+------------+-------------------+----------
 table03    | bca90a00ef | db2_tg_default    |       39

Se a utilização de CPU de bca90a00ef for muito maior que a dos outros workers, a distorção de dados é a causa.

Correção

1. Reconfigure a chave de distribuição para que as linhas se distribuam de forma mais uniforme entre os shards. Para instruções detalhadas, consulte Otimizar o desempenho de consultas em tabelas internas do Hologres.

2. Divida tabelas com distorção severa. Se os dados forem intrinsecamente distorcidos — por exemplo, uma tabela de pedidos de livestreaming em que poucos streamers principais representam a grande maioria do volume bruto de mercadoria (GMV) — divida a tabela pela dimensão distorcida em vez de tentar redistribuí-la.

Causa 3: Contagem de shards não alinhada com a contagem de workers

Contagens de shards que não são múltiplos da contagem de workers causam alocação desigual por design: alguns workers sempre recebem um shard extra.

Diagnóstico

SELECT table_group_name, worker_id,
       COUNT(1) AS shard_count, warehouse_id
FROM hologres.hg_worker_info
GROUP BY table_group_name, worker_id, warehouse_id
ORDER BY table_group_name DESC;

Saída de exemplo para uma instância com dois workers:

table_group_name | worker_id  | shard_count  | warehouse_id
------------------+------------+--------------+-------------
 tg2              | ea405b4a9c |           1  |           1
 tg2              | bca90a00ef |           2  |           2
 tg1              | ea405b4a9c |           5  |           1
 tg1              | bca90a00ef |           6  |           2
 db2_tg_default   | bca90a00ef |           4  |           2
 db2_tg_default   | ea405b4a9c |           4  |           1
 db2_tg_internal  | bca90a00ef |           1  |           2
(7 rows)

Interpretando a saída:

• tg2 tem 3 shards entre 2 workers (1 vs. 2) — não é múltiplo de 2, portanto um worker sempre terá mais.

• tg1 tem 11 shards entre 2 workers (5 vs. 6) — mesmo problema.

• db2_tg_default tem 8 shards entre 2 workers (4 vs. 4) — distribuição uniforme.

Correção

Defina a contagem de shards de cada table group como um múltiplo do número de workers. Estime o valor correto com base nos requisitos do seu negócio e, em seguida, reconfigure ou expanda a instância de acordo.