Utilisez toujours la `performance` mise à l'échelle gouverneur. Le `on-demand` gouverneur de mise à l'échelle fonctionne bien pire avec une demande constamment élevée.
Pour de petites quantités de données (jusqu'à ~200 GO en mode compressé), il est préférable d'utiliser autant de mémoire que le volume de données.
Pour de grandes quantités de données et lors du traitement de requêtes interactives (en ligne), vous devez utiliser une quantité raisonnable de RAM (128 Go ou plus) afin que le sous-ensemble de données chaudes s'intègre dans le cache des pages.
Même pour des volumes de données d'environ 50 To par serveur, l'utilisation de 128 Go de RAM améliore considérablement les performances des requêtes par rapport à 64 Go.
Ne désactivez pas de surcharge. Valeur `cat /proc/sys/vm/overcommit_memory` devrait être 0 ou 1. Exécuter
``` bash
$ echo 0 | sudo tee /proc/sys/vm/overcommit_memory
```
## Huge Pages {#huge-pages}
Toujours désactiver les pages énormes transparentes. Il interfère avec les allocateurs de mémoire, ce qui entraîne une dégradation significative des performances.
``` bash
$ echo 'never' | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
```
Utiliser `perf top` pour regarder le temps passé dans le noyau pour la gestion de la mémoire.
Lorsque vous utilisez RAID-5, RAID-6 ou RAID-50, augmentez toujours stripe\_cache\_size, car la valeur par défaut n'est généralement pas le meilleur choix.
$ echo 4096 | sudo tee /sys/block/md2/md/stripe_cache_size
```
Calculez le nombre exact à partir du nombre de périphériques et de la taille du bloc, en utilisant la formule: `2 * num_devices * chunk_size_in_bytes / 4096`.
Une taille de bloc de 1024 KO est suffisante pour toutes les configurations RAID.
Ne définissez jamais la taille du bloc trop petite ou trop grande.
Activer NCQ avec une longue file d'attente. Pour HDD, choisissez le planificateur CFQ, et pour SSD, choisissez noop. Ne pas réduire le ‘readahead’ paramètre.
La plupart des autres systèmes de fichiers devraient également fonctionner correctement. Les systèmes de fichiers avec allocation retardée fonctionnent mieux.
Utilisez au moins un réseau de 10 Go, si possible. 1 Go fonctionnera également, mais ce sera bien pire pour patcher des répliques avec des dizaines de téraoctets de données, ou pour traiter des requêtes distribuées avec une grande quantité de données intermédiaires.
Vous ne devez jamais utiliser de scripts écrits manuellement pour transférer des données entre différents clusters ZooKeeper, car le résultat sera incorrect pour les nœuds séquentiels. Ne jamais utiliser de l' “zkcopy” utilitaire pour la même raison: https://github.com/ksprojects/zkcopy/issues/15
Si vous souhaitez diviser un cluster Zookeeper existant en deux, le bon moyen est d'augmenter le nombre de ses répliques, puis de le reconfigurer en deux clusters indépendants.
N'exécutez pas ZooKeeper sur les mêmes serveurs que ClickHouse. Parce que ZooKeeper est très sensible à la latence et ClickHouse peut utiliser toutes les ressources système disponibles.
> Le serveur ZooKeeper ne supprime pas les fichiers des anciens snapshots et journaux lors de l'utilisation de la configuration par défaut (voir autopurge), et c'est la responsabilité de l'opérateur.