Los procesadores pueden sobrecalentarse. Utilizar `dmesg` para ver si la velocidad de reloj de la CPU era limitada debido al sobrecalentamiento.
La restricción también se puede establecer externamente en el nivel del centro de datos. Usted puede utilizar `turbostat` para controlarlo bajo una carga.
## RAM {#ram}
Para pequeñas cantidades de datos (hasta ~200 GB comprimidos), es mejor usar tanta memoria como el volumen de datos.
Para grandes cantidades de datos y al procesar consultas interactivas (en línea), debe usar una cantidad razonable de RAM (128 GB o más) para que el subconjunto de datos en caliente quepa en la memoria caché de páginas.
Incluso para volúmenes de datos de ~ 50 TB por servidor, el uso de 128 GB de RAM mejora significativamente el rendimiento de las consultas en comparación con 64 GB.
Siempre deshabilite las páginas enormes transparentes. Interfiere con los asignadores de memoria, lo que conduce a una degradación significativa del rendimiento.
``` bash
$ echo 'never' | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
```
Utilizar `perf top` para ver el tiempo pasado en el kernel para la administración de memoria.
Las páginas enormes permanentes tampoco necesitan ser asignadas.
Dar preferencia a una gran cantidad de servidores con discos duros locales sobre un número menor de servidores con estantes de discos conectados.
Pero para almacenar archivos con consultas raras, los estantes funcionarán.
## RAID {#raid}
Al usar HDD, puede combinar su RAID-10, RAID-5, RAID-6 o RAID-50.
Para Linux, el software RAID es mejor (con `mdadm`). No recomendamos usar LVM.
Al crear RAID-10, seleccione el `far` diseño.
Si su presupuesto lo permite, elija RAID-10.
Si tiene más de 4 discos, utilice RAID-6 (preferido) o RAID-50, en lugar de RAID-5.
Cuando use RAID-5, RAID-6 o RAID-50, siempre aumente stripe\_cache\_size, ya que el valor predeterminado generalmente no es la mejor opción.
``` bash
$ echo 4096 | sudo tee /sys/block/md2/md/stripe_cache_size
```
Calcule el número exacto a partir del número de dispositivos y el tamaño del bloque, utilizando la fórmula: `2 * num_devices * chunk_size_in_bytes / 4096`.
Un tamaño de bloque de 1024 KB es suficiente para todas las configuraciones RAID.
Nunca ajuste el tamaño del bloque demasiado pequeño o demasiado grande.
Puede usar RAID-0 en SSD.
Independientemente del uso de RAID, utilice siempre la replicación para la seguridad de los datos.
Habilite NCQ con una cola larga. Para HDD, elija el programador CFQ, y para SSD, elija noop. No reduzca el ‘readahead’ configuración.
Si está utilizando IPv6, aumente el tamaño de la caché de ruta.
El kernel de Linux anterior a 3.2 tenía una multitud de problemas con la implementación de IPv6.
Utilice al menos una red de 10 GB, si es posible. 1 Gb también funcionará, pero será mucho peor para parchear réplicas con decenas de terabytes de datos, o para procesar consultas distribuidas con una gran cantidad de datos intermedios.
Nunca debe usar scripts escritos manualmente para transferir datos entre diferentes clústeres de ZooKeeper, ya que el resultado será incorrecto para los nodos secuenciales. Nunca utilice el “zkcopy” utilidad por la misma razón: https://github.com/ksprojects/zkcopy/issues/15
Si desea dividir un clúster ZooKeeper existente en dos, la forma correcta es aumentar el número de sus réplicas y, a continuación, volver a configurarlo como dos clústeres independientes.
No ejecute ZooKeeper en los mismos servidores que ClickHouse. Porque ZooKeeper es muy sensible a la latencia y ClickHouse puede utilizar todos los recursos del sistema disponibles.
> El servidor ZooKeeper no eliminará archivos de instantáneas y registros antiguos cuando utilice la configuración predeterminada (consulte autopurge), y esto es responsabilidad del operador.
Esta bomba debe ser desactivada.
La configuración ZooKeeper (3.5.1) a continuación se usa en Yandex.Entorno de producción de Métrica al 20 de mayo de 2017: