min_chunk_bytes_for_parallel_parsing
- Tipo: inteiro sem sinal
- Valor padrão: 1 MiB
min_compress_block_size
min_compress_block_size. O padrão é 65.536.
O tamanho real do bloco, se os dados não comprimidos forem menores que max_compress_block_size, não será inferior a esse valor nem ao volume de dados de uma marca.
Vejamos um exemplo. Suponha que index_granularity tenha sido definido como 8192 durante a criação da tabela.
Estamos gravando uma coluna do tipo UInt32 (4 bytes por valor). Ao gravar 8192 linhas, o total será de 32 KB de dados. Como min_compress_block_size = 65.536, um bloco comprimido será formado a cada duas marcas.
Estamos gravando uma coluna de URL do tipo String (tamanho médio de 60 bytes por valor). Ao gravar 8192 linhas, a média será de pouco menos de 500 KB de dados. Como isso é maior que 65.536, um bloco comprimido será formado para cada marca. Nesse caso, ao ler dados do disco no intervalo de uma única marca, dados extras não serão descomprimidos.
Esta é uma configuração de nível especialista, e você não deve alterá-la se estiver apenas começando a usar o ClickHouse.
min_filtered_ratio_for_lazy_final
min_hit_rate_to_use_consecutive_keys_optimization
min_os_cpu_wait_time_ratio_to_throw
min_outstreams_per_resize_after_split
Resize ou StrictResize após a divisão ser realizada durante a geração do pipeline. Se o número resultante de streams for menor que esse valor, a operação de divisão não será realizada.
O que é um nó Resize
Resize é um processador no pipeline de consulta que ajusta o número de stream de dados que passam pelo pipeline. Ele pode aumentar ou diminuir o número de stream para equilibrar a carga de trabalho entre vários threads ou processadores. Por exemplo, se uma consulta exigir mais paralelismo, o nó Resize pode dividir um único stream em vários stream. Por outro lado, ele pode mesclar vários stream em menos stream para consolidar o processamento de dados.
O nó Resize garante que os dados sejam distribuídos uniformemente entre os stream, mantendo a estrutura dos blocos de dados. Isso ajuda a otimizar a utilização de recursos e a melhorar o desempenho da consulta.
Por que o nó Resize precisa ser dividido
status_mutex de ExecutingGraph::Node no nó Resize, que funciona como ponto central, sofre forte contenção, especialmente em ambientes com muitos núcleos, e isso leva a:
- Aumento da latência de ExecutingGraph::updateNode, impactando diretamente o desempenho da consulta.
- Ciclos excessivos de CPU são desperdiçados com contenção de spin-lock (
native_queued_spin_lock_slowpath), reduzindo a eficiência. - Redução da utilização da CPU, limitando o paralelismo e a taxa de transferência.
Como o nó Resize é dividido
- O número de streams de saída é verificado para garantir que a divisão possa ser realizada: os streams de saída de cada processador resultante da divisão atendem ou excedem o limite
min_outstreams_per_resize_after_split. - O nó
Resizeé dividido em nósResizemenores, com a mesma quantidade de portas, cada um lidando com um subconjunto de streams de entrada e de saída. - Cada grupo é processado de forma independente, reduzindo a contenção de lock.
Divisão do nó Resize com entradas/saídas arbitrárias
Resize após a divisão, algumas entradas são conectadas a NullSources e algumas saídas são conectadas a NullSinks. Isso permite que a divisão ocorra sem afetar o fluxo geral de dados.
Finalidade da configuração
min_outstreams_per_resize_after_split garante que a divisão de nós Resize seja realmente útil e evita a criação de um número muito pequeno de streams, o que poderia levar a um processamento paralelo ineficiente. Ao impor um número mínimo de streams de saída, essa configuração ajuda a manter o equilíbrio entre paralelismo e sobrecarga, otimizando a execução de consultas em cenários que envolvem divisão e mesclagem de streams.
Desativando a configuração
Resize, defina esta configuração como 0. Isso impedirá a divisão de nós Resize durante a geração do pipeline, permitindo que mantenham sua estrutura original sem serem divididos em nós menores.