Skip to main content
Esta página não se aplica ao ClickHouse Cloud. O procedimento descrito aqui é automatizado nos serviços do ClickHouse Cloud.

Governador de escalonamento da CPU

Sempre use o governador de escalonamento performance. O governador on-demand funciona muito pior sob carga constantemente alta.

Limitações da CPU

Os processadores podem superaquecer. Use dmesg para verificar se a frequência de clock da CPU foi reduzida devido ao superaquecimento. A limitação também pode ser imposta externamente no nível do datacenter. Você pode usar turbostat para monitorá-la sob carga.

RAM

Para pequenos volumes de dados (até ~200 GB comprimidos), o ideal é usar uma quantidade de memória equivalente ao volume de dados. Para grandes volumes de dados e ao processar consultas interativas (online), use uma quantidade razoável de RAM (128 GB ou mais), para que o subconjunto de dados mais acessados caiba no cache de páginas. Mesmo para volumes de dados de ~50 TB por servidor, usar 128 GB de RAM melhora significativamente o desempenho das consultas em comparação com 64 GB. Não desative o overcommit. O valor de cat /proc/sys/vm/overcommit_memory deve ser 0 ou 1. Execute
Use perf top para observar o tempo gasto no kernel com o gerenciamento de memória. As huge pages permanentes também não precisam ser alocadas.

Usando menos de 16 GB de RAM

A quantidade recomendada de RAM é de 32 GB ou mais. Se o seu sistema tiver menos de 16 GB de RAM, você poderá encontrar várias exceções de memória, porque as configurações padrão não são adequadas para essa quantidade de memória. Você pode usar o ClickHouse em um sistema com pouca RAM (até mesmo com 2 GB), mas essas configurações exigem ajustes adicionais e só permitem ingestão em baixa taxa. Ao usar o ClickHouse com menos de 16 GB de RAM, recomendamos o seguinte:
  • Reduza o tamanho do mark cache no config.xml. Ele pode ser configurado para apenas 500 MB, mas não pode ser definido como zero.
  • Reduza o número de threads de processamento de consultas para 1.
  • Reduza o max_block_size para 8192. Valores tão baixos quanto 1024 ainda podem ser viáveis.
  • Reduza max_download_threads para 1.
  • Defina input_format_parallel_parsing e output_format_parallel_formatting como 0.
  • desative a gravação em log tables, pois isso faz com que a tarefa de mesclagem em segundo plano reserve RAM para executar mesclagens de log tables. Desative asynchronous_metric_log, metric_log, text_log, trace_log.
Observações adicionais:
  • Para liberar a memória armazenada em cache pelo allocator de memória, você pode executar o comando SYSTEM JEMALLOC PURGE.
  • Não recomendamos usar integrações com S3 ou Kafka em máquinas com pouca memória, porque elas exigem uma quantidade significativa de memória para buffers.

Subsistema de armazenamento

Se o seu orçamento permitir usar SSD, use SSD. Se não, use HDD. HDDs SATA de 7200 RPM servem. Dê preferência a muitos servidores com discos rígidos locais em vez de um número menor de servidores com shelves de disco conectados. Mas, para armazenar arquivos históricos com consultas pouco frequentes, os shelves funcionarão.

RAID

Ao usar HDDs, você pode combiná-los em RAID-10, RAID-5, RAID-6 ou RAID-50. No Linux, o RAID por software é melhor (com mdadm). Ao criar um RAID-10, selecione o layout far. Se o orçamento permitir, escolha RAID-10. O LVM por si só (sem RAID ou mdadm) é aceitável, mas criar um RAID com ele ou combiná-lo com o mdadm é uma opção menos testada e com maior chance de erros (selecionar o tamanho de chunk errado; desalinhamento dos chunks; escolher o tipo de RAID errado; esquecer de limpar os discos). Se você tem segurança ao usar LVM, não há problema em usá-lo. Se você tiver mais de 4 discos, use RAID-6 (preferencialmente) ou RAID-50, em vez de RAID-5. Ao usar RAID-5, RAID-6 ou RAID-50, sempre aumente stripe_cache_size, já que o valor padrão geralmente não é a melhor opção.
Calcule o número exato com base no número de dispositivos e no tamanho do bloco, usando a fórmula: 2 * num_devices * chunk_size_in_bytes / 4096. Um tamanho de bloco de 64 KB é suficiente para a maioria das configurações de RAID. O tamanho médio de gravação do clickhouse-server é de aproximadamente 1 MB (1024 KB) e, portanto, o tamanho de stripe recomendado também é de 1 MB. Se necessário, o tamanho do bloco pode ser otimizado definindo-o como 1 MB dividido pelo número de discos sem paridade no array RAID, de modo que cada gravação seja paralelizada em todos os discos sem paridade disponíveis. Nunca defina o tamanho do bloco como muito pequeno nem muito grande. Você pode usar RAID-0 em SSD. Independentemente do uso de RAID, sempre use replicação para garantir a segurança dos dados. Habilite NCQ com uma fila longa. Para HDD, escolha o scheduler mq-deadline ou CFQ e, para SSD, escolha noop. Não reduza a configuração de ‘readahead’. Para HDD, habilite o cache de gravação. Certifique-se de que fstrim esteja habilitado para discos NVME e SSD no seu sistema operacional (geralmente isso é implementado usando um cronjob ou serviço do systemd).

Sistema de arquivos

Ext4 é a opção mais confiável. Defina noatime nas opções de montagem. O XFS também funciona bem. A maioria dos outros sistemas de arquivos também deve funcionar sem problemas. FAT-32 e exFAT não são compatíveis devido à falta de hard links. Não use sistemas de arquivos comprimidos, porque o ClickHouse faz a própria compressão, e melhor. Não é recomendável usar sistemas de arquivos criptografados, porque você pode usar a criptografia nativa do ClickHouse, que é superior. Embora o ClickHouse possa funcionar com NFS, essa não é a melhor opção.

Kernel do Linux

Não use um kernel do Linux desatualizado.

Rede

Se você estiver usando IPv6, aumente o tamanho do cache de rotas. O kernel Linux anterior à versão 3.2 tinha vários problemas na implementação de IPv6. Use, se possível, uma rede de pelo menos 10 GB. Uma rede de 1 Gb também funcionará, mas será bem pior para atualizar réplicas com dezenas de terabytes de dados ou para processar consultas distribuídas com grande volume de dados intermediários.

Huge Pages

Sempre defina transparent huge pages como madvise. Em kernels mais antigos (anteriores ao 5.9), THP configurado como always pode causar uma degradação significativa de desempenho — o kernel gasta tempo demais com a desfragmentação da memória, especialmente em sistemas com 64 GB+ de RAM. O kernel 5.9 introduziu a compactação proativa, que lida muito melhor com THP, mas o ClickHouse ainda exibe um aviso na inicialização se THP estiver configurado como always, portanto madvise é a configuração recomendada independentemente da versão do kernel.
Se quiser alterar permanentemente a configuração de transparent huge pages, edite o /etc/default/grub para adicionar transparent_hugepage=madvise à opção GRUB_CMDLINE_LINUX_DEFAULT:
Depois disso, execute o comando sudo update-grub e reinicie o sistema para que a alteração entre em vigor.

Configuração do hipervisor

Se você estiver usando OpenStack, defina
em nova.conf. Se estiver usando libvirt, defina
na configuração XML. Isso é importante para que o ClickHouse consiga obter informações corretas com a instrução cpuid. Caso contrário, você poderá ter falhas de Illegal instruction quando o hipervisor estiver em execução em modelos de CPU antigos.

ClickHouse Keeper and ZooKeeper

O ClickHouse Keeper é recomendado para substituir o ZooKeeper em clusters do ClickHouse. Consulte a documentação do ClickHouse Keeper Se você quiser continuar usando o ZooKeeper, o ideal é usar uma versão recente do ZooKeeper – 3.4.9 ou posterior. A versão disponível em distribuições Linux estáveis pode estar desatualizada. Você nunca deve usar scripts escritos manualmente para transferir dados entre diferentes clusters do ZooKeeper, porque o resultado será incorreto para nós sequenciais. Nunca use o utilitário “zkcopy” pelo mesmo motivo: https://github.com/ksprojects/zkcopy/issues/15 Se você quiser dividir um cluster do ZooKeeper existente em dois, a forma correta é aumentar o número de suas réplicas e depois reconfigurá-lo como dois clusters independentes. Você pode executar o ClickHouse Keeper no mesmo servidor que o ClickHouse em ambientes de teste ou em ambientes com baixa taxa de ingestão. Para ambientes de produção, sugerimos usar servidores separados para ClickHouse e ZooKeeper/Keeper, ou colocar os arquivos do ClickHouse e os arquivos do Keeper em discos separados. Isso porque o ZooKeeper/Keeper é muito sensível à latência de disco, e o ClickHouse pode utilizar todos os recursos disponíveis do sistema. Você pode ter observers do ZooKeeper em um ensemble, mas os servidores do ClickHouse não devem interagir com observers. Não altere a configuração minSessionTimeout; valores altos podem afetar a estabilidade do ClickHouse ao reiniciar. Com as configurações padrão, o ZooKeeper é uma bomba-relógio:
O servidor ZooKeeper não excluirá arquivos de snapshots e logs antigos ao usar a configuração padrão (consulte autopurge), e isso é responsabilidade do operador.
Essa bomba deve ser desarmada. A configuração do ZooKeeper (3.5.1) abaixo é usada em um grande ambiente de produção: zoo.cfg:
Versão do Java:
Parâmetros da JVM:
Inicialização do Salt:

Software antivírus

Se você usa um software antivírus, configure-o para ignorar as pastas com os arquivos de dados do ClickHouse (/var/lib/clickhouse); caso contrário, o desempenho poderá ser reduzido e você poderá encontrar erros inesperados durante a ingestão de dados e as mesclagens em segundo plano.
Última modificação em 3 de julho de 2026