Pular para o conteúdo principal
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. 
$ echo 'performance' | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

​
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 
$ echo 0 | sudo tee /proc/sys/vm/overcommit_memory
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. 
$ echo 4096 | sudo tee /sys/block/md2/md/stripe_cache_size
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. 
$ echo 'madvise' | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
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: 
$ GRUB_CMDLINE_LINUX_DEFAULT="transparent_hugepage=madvise ..."
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 
cpu_mode=host-passthrough
em nova.conf. Se estiver usando libvirt, defina 
<cpu mode='host-passthrough'/>
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: 
# http://hadoop.apache.org/zookeeper/docs/current/zookeeperAdmin.html

# O número de milissegundos de cada tick
tickTime=2000
# O número de ticks que a fase de
# sincronização inicial pode levar
# Este valor não é muito motivado
initLimit=300
# O número de ticks que podem passar entre
# o envio de uma requisição e o recebimento de uma confirmação
syncLimit=10

maxClientCnxns=2000

# É o valor máximo que o cliente pode solicitar e que o servidor aceitará.
# É aceitável ter um maxSessionTimeout alto no servidor para permitir que os clientes usem um timeout de sessão alto, se desejarem.
# Mas solicitamos timeout de sessão de 30 segundos por padrão (você pode alterá-lo com session_timeout_ms na configuração do ClickHouse).
maxSessionTimeout=60000000
# o diretório onde o snapshot é armazenado.
dataDir=/opt/zookeeper/{{ '{{' }} cluster['name'] {{ '}}' }}/data
# Coloque o dataLogDir em um disco físico separado para melhor desempenho
dataLogDir=/opt/zookeeper/{{ '{{' }} cluster['name'] {{ '}}' }}/logs

autopurge.snapRetainCount=10
autopurge.purgeInterval=1

# Para evitar seeks, o ZooKeeper aloca espaço no arquivo de log de transações em
# blocos de preAllocSize kilobytes. O tamanho de bloco padrão é 64M. Um motivo
# para alterar o tamanho dos blocos é reduzi-lo caso snapshots
# sejam tirados com mais frequência. (Veja também snapCount).
preAllocSize=131072

# Os clientes podem enviar requisições mais rápido do que o ZooKeeper consegue processá-las,
# especialmente quando há muitos clientes. Para evitar que o ZooKeeper fique sem
# memória devido a requisições na fila, o ZooKeeper limitará os clientes de forma que
# não haja mais do que globalOutstandingLimit requisições pendentes no
# sistema. O limite padrão é 1000.
# globalOutstandingLimit=1000

# O ZooKeeper registra transações em um log de transações. Após snapCount transações
# serem gravadas em um arquivo de log, um snapshot é iniciado e um novo arquivo de log de transações
# é criado. O snapCount padrão é 100000.
snapCount=3000000

# Se esta opção for definida, as requisições serão registradas em um arquivo de trace chamado
# traceFile.ano.mes.dia.
#traceFile=

# O líder aceita conexões de clientes. O valor padrão é "yes". A máquina líder
# coordena as atualizações. Para maior throughput de atualização com um leve custo no
# throughput de leitura, o líder pode ser configurado para não aceitar clientes e focar
# na coordenação.
leaderServes=yes

standaloneEnabled=false
dynamicConfigFile=/etc/zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }}/conf/zoo.cfg.dynamic
Versão do Java: 
openjdk 11.0.5-shenandoah 2019-10-15
OpenJDK Runtime Environment (build 11.0.5-shenandoah+10-adhoc.heretic.src)
OpenJDK 64-Bit Server VM (build 11.0.5-shenandoah+10-adhoc.heretic.src, mixed mode)
Parâmetros da JVM: 
NAME=zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }}
ZOOCFGDIR=/etc/$NAME/conf

# TODO isso é bem feio
# Como descobrir quais jars são necessários?
# parece que o log4j exige que o arquivo log4j.properties esteja no classpath
CLASSPATH="$ZOOCFGDIR:/usr/build/classes:/usr/build/lib/*.jar:/usr/share/zookeeper-3.6.2/lib/audience-annotations-0.5.0.jar:/usr/share/zookeeper-3.6.2/lib/commons-cli-1.2.jar:/usr/share/zookeeper-3.6.2/lib/commons-lang-2.6.jar:/usr/share/zookeeper-3.6.2/lib/jackson-annotations-2.10.3.jar:/usr/share/zookeeper-3.6.2/lib/jackson-core-2.10.3.jar:/usr/share/zookeeper-3.6.2/lib/jackson-databind-2.10.3.jar:/usr/share/zookeeper-3.6.2/lib/javax.servlet-api-3.1.0.jar:/usr/share/zookeeper-3.6.2/lib/jetty-http-9.4.24.v20191120.jar:/usr/share/zookeeper-3.6.2/lib/jetty-io-9.4.24.v20191120.jar:/usr/share/zookeeper-3.6.2/lib/jetty-security-9.4.24.v20191120.jar:/usr/share/zookeeper-3.6.2/lib/jetty-server-9.4.24.v20191120.jar:/usr/share/zookeeper-3.6.2/lib/jetty-servlet-9.4.24.v20191120.jar:/usr/share/zookeeper-3.6.2/lib/jetty-util-9.4.24.v20191120.jar:/usr/share/zookeeper-3.6.2/lib/jline-2.14.6.jar:/usr/share/zookeeper-3.6.2/lib/json-simple-1.1.1.jar:/usr/share/zookeeper-3.6.2/lib/log4j-1.2.17.jar:/usr/share/zookeeper-3.6.2/lib/metrics-core-3.2.5.jar:/usr/share/zookeeper-3.6.2/lib/netty-buffer-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-codec-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-common-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-handler-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-resolver-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-transport-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-transport-native-epoll-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/netty-transport-native-unix-common-4.1.50.Final.jar:/usr/share/zookeeper-3.6.2/lib/simpleclient-0.6.0.jar:/usr/share/zookeeper-3.6.2/lib/simpleclient_common-0.6.0.jar:/usr/share/zookeeper-3.6.2/lib/simpleclient_hotspot-0.6.0.jar:/usr/share/zookeeper-3.6.2/lib/simpleclient_servlet-0.6.0.jar:/usr/share/zookeeper-3.6.2/lib/slf4j-api-1.7.25.jar:/usr/share/zookeeper-3.6.2/lib/slf4j-log4j12-1.7.25.jar:/usr/share/zookeeper-3.6.2/lib/snappy-java-1.1.7.jar:/usr/share/zookeeper-3.6.2/lib/zookeeper-3.6.2.jar:/usr/share/zookeeper-3.6.2/lib/zookeeper-jute-3.6.2.jar:/usr/share/zookeeper-3.6.2/lib/zookeeper-prometheus-metrics-3.6.2.jar:/usr/share/zookeeper-3.6.2/etc"

ZOOCFG="$ZOOCFGDIR/zoo.cfg"
ZOO_LOG_DIR=/var/log/$NAME
USER=zookeeper
GROUP=zookeeper
PIDDIR=/var/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
JAVA=/usr/local/jdk-11/bin/java
ZOOMAIN="org.apache.zookeeper.server.quorum.QuorumPeerMain"
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"
JMXLOCALONLY=false
JAVA_OPTS="-Xms{{ '{{' }} cluster.get('xms','128M') {{ '}}' }} \
    -Xmx{{ '{{' }} cluster.get('xmx','1G') {{ '}}' }} \
    -Xlog:safepoint,gc*=info,age*=debug:file=/var/log/$NAME/zookeeper-gc.log:time,level,tags:filecount=16,filesize=16M
    -verbose:gc \
    -XX:+UseG1GC \
    -Djute.maxbuffer=8388608 \
    -XX:MaxGCPauseMillis=50"
Inicialização do Salt: 
description "zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }} centralized coordination service"

start on runlevel [2345]
stop on runlevel [!2345]

respawn

limit nofile 8192 8192

pre-start script
    [ -r "/etc/zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }}/conf/environment" ] || exit 0
    . /etc/zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }}/conf/environment
    [ -d $ZOO_LOG_DIR ] || mkdir -p $ZOO_LOG_DIR
    chown $USER:$GROUP $ZOO_LOG_DIR
end script

script
    . /etc/zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }}/conf/environment
    [ -r /etc/default/zookeeper ] && . /etc/default/zookeeper
    if [ -z "$JMXDISABLE" ]; then
        JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=$JMXLOCALONLY"
    fi
    exec start-stop-daemon --start -c $USER --exec $JAVA --name zookeeper-{{ '{{' }} cluster['name'] {{ '}}' }} \
        -- -cp $CLASSPATH $JAVA_OPTS -Dzookeeper.log.dir=${ZOO_LOG_DIR} \
        -Dzookeeper.root.logger=${ZOO_LOG4J_PROP} $ZOOMAIN $ZOOCFG
end script

​
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.

​
Conteúdo relacionado

Última modificação em 10 de junho de 2026