Exécuter un benchmark avec DEFLATE_QPL

Assurez-vous que votre machine hôte remplit les prérequis de QPL
deflate_qpl est activé par défaut lors de la compilation avec CMake. Si vous l’avez modifié par inadvertance, veuillez vérifier que l’indicateur de compilation est bien défini : ENABLE_QPL=1
Pour les exigences générales, veuillez consulter les instructions générales de compilation de ClickHouse

Liste des fichiers

Le dossier benchmark_sample dans qpl-cmake fournit des exemples pour exécuter le benchmark avec des scripts Python : client_scripts contient des scripts Python pour exécuter un benchmark typique, par exemple :

client_stressing_test.py : script Python pour le test de charge des requêtes avec [1~4] instances de serveur.
queries_ssb.sql : ce fichier répertorie toutes les requêtes du Star Schema Benchmark
allin1_ssb.sh : ce script shell exécute automatiquement l’ensemble du workflow du benchmark en mode all in one.

database_files signifie que les fichiers de base de données seront stockés selon le codec lz4/deflate/zstd.

Exécuter automatiquement le benchmark du Star Schema :

$ cd ./benchmark_sample/client_scripts
$ sh run_ssb.sh

Une fois l’opération terminée, veuillez vérifier tous les résultats dans ce dossier :./output/ En cas d’échec, veuillez exécuter manuellement le benchmark comme indiqué dans les sections ci-dessous.

Définition

[CLICKHOUSE_EXE] désigne le chemin vers le programme exécutable ClickHouse.

Environnement

CPU : Sapphire Rapid
Pour connaître les exigences relatives au système d’exploitation, consultez System Requirements for QPL
Pour la configuration d’IAA, consultez Accelerator Configuration
Installez les modules Python :

pip3 install clickhouse_driver numpy

[Vérification de l’IAA]

$ accel-config list | grep -P 'iax|state'

Résultat attendu :

    "dev":"iax1",
    "state":"enabled",
            "state":"enabled",

Si rien ne s’affiche, cela signifie que l’IAA n’est pas prête. Veuillez vérifier à nouveau la configuration de l’IAA.

Générer des données brutes

$ cd ./benchmark_sample
$ mkdir rawdata_dir && cd rawdata_dir

Utilisez dbgen pour générer 100 millions de lignes de données avec le paramètre : -s 20 Les fichiers tels que *.tbl devraient être générés dans ./benchmark_sample/rawdata_dir/ssb-dbgen :

Configuration de la base de données

Configurer la base de données avec le codec LZ4

$ cd ./database_dir/lz4
$ [CLICKHOUSE_EXE] server -C config_lz4.xml >&/dev/null&
$ [CLICKHOUSE_EXE] client

Ici, vous devriez voir le message Connected to ClickHouse server dans la console, ce qui signifie que le client a correctement établi la connexion avec le serveur. Suivez les trois étapes ci-dessous décrites dans Star Schema Benchmark

Créer des tables dans ClickHouse
Insérer les données. Utilisez ici ./benchmark_sample/rawdata_dir/ssb-dbgen/*.tbl comme données d’entrée.
Convertir le “schéma en étoile” en “schéma plat” dénormalisé

Configurez la base de données avec le codec IAA Deflate

$ cd ./database_dir/deflate
$ [CLICKHOUSE_EXE] server -C config_deflate.xml >&/dev/null&
$ [CLICKHOUSE_EXE] client

Répétez les trois étapes comme pour lz4 ci-dessus Configurez la base de données avec le codec ZSTD

$ cd ./database_dir/zstd
$ [CLICKHOUSE_EXE] server -C config_zstd.xml >&/dev/null&
$ [CLICKHOUSE_EXE] client

Effectuez les trois mêmes étapes que ci-dessus pour lz4 [self-check] Pour chaque codec (lz4/zstd/deflate), exécutez la requête ci-dessous afin de vous assurer que les bases de données ont bien été créées :

SELECT count() FROM lineorder_flat

Le résultat ci-dessous devrait s’afficher :

┌───count()─┐
│ 119994608 │
└───────────┘

[Vérification automatique du codec IAA Deflate] La première fois que vous exécutez une insertion ou une requête depuis le client, la console du serveur ClickHouse devrait afficher ce message de journal :

Hardware-assisted DeflateQpl codec is ready!

Si vous ne trouvez jamais ceci, mais voyez plutôt un autre log comme ci-dessous :

Initialization of hardware-assisted DeflateQpl codec failed

Cela signifie que les périphériques IAA ne sont pas prêts ; vous devez vérifier à nouveau la configuration d’IAA.

Benchmark sur une seule instance

Avant de démarrer le benchmark, veuillez désactiver C6 et régler le gouverneur de fréquence du CPU sur performance

$ cpupower idle-set -d 3
$ cpupower frequency-set -g performance

Pour éliminer l’impact des contraintes mémoire entre les sockets, nous utilisons numactl pour affecter le serveur à un socket et le client à un autre socket.
Une instance unique signifie qu’un seul serveur est connecté à un seul client

Exécutez maintenant le benchmark pour LZ4/Deflate/ZSTD, respectivement : LZ4:

$ cd ./database_dir/lz4 
$ numactl -m 0 -N 0 [CLICKHOUSE_EXE] server -C config_lz4.xml >&/dev/null&
$ cd ./client_scripts
$ numactl -m 1 -N 1 python3 client_stressing_test.py queries_ssb.sql 1 > lz4.log

IAA deflate :

$ cd ./database_dir/deflate
$ numactl -m 0 -N 0 [CLICKHOUSE_EXE] server -C config_deflate.xml >&/dev/null&
$ cd ./client_scripts
$ numactl -m 1 -N 1 python3 client_stressing_test.py queries_ssb.sql 1 > deflate.log

ZSTD:

$ cd ./database_dir/zstd
$ numactl -m 0 -N 0 [CLICKHOUSE_EXE] server -C config_zstd.xml >&/dev/null&
$ cd ./client_scripts
$ numactl -m 1 -N 1 python3 client_stressing_test.py queries_ssb.sql 1 > zstd.log

Trois logs devraient maintenant s’afficher comme prévu :

lz4.log
deflate.log
zstd.log

Comment vérifier les métriques de performance : Nous nous concentrons sur le QPS ; veuillez rechercher le mot-clé QPS_Final et relever les statistiques

Benchmark avec plusieurs instances

Pour réduire l’impact des limitations mémoire lorsqu’un trop grand nombre de threads est utilisé, nous recommandons d’exécuter le benchmark avec plusieurs instances.
Plusieurs instances signifie que plusieurs serveurs (2 ou 4) sont connectés chacun à leur client respectif.
Les cœurs d’un socket doivent être répartis équitablement et attribués aux différents serveurs.
Avec plusieurs instances, il faut créer un nouveau dossier pour chaque codec et insérer le jeu de données en suivant des étapes similaires à celles d’une instance unique.

Il y a 2 différences :

Côté client, vous devez lancer ClickHouse avec le port attribué lors de la création de la table et de l’insertion des données.
Côté serveur, vous devez lancer ClickHouse avec le fichier de config XML spécifique dans lequel le port a été attribué. Tous les fichiers de config XML personnalisés pour plusieurs instances sont fournis dans ./server_config.

Ici, nous supposons qu’il y a 60 cœurs par socket et prenons 2 instances comme exemple. Lancez le serveur pour la première instance LZ4 :

$ cd ./database_dir/lz4
$ numactl -C 0-29,120-149 [CLICKHOUSE_EXE] server -C config_lz4.xml >&/dev/null&

ZSTD:

$ cd ./database_dir/zstd
$ numactl -C 0-29,120-149 [CLICKHOUSE_EXE] server -C config_zstd.xml >&/dev/null&

IAA Deflate :

$ cd ./database_dir/deflate
$ numactl -C 0-29,120-149 [CLICKHOUSE_EXE] server -C config_deflate.xml >&/dev/null&

[Démarrer le serveur pour la deuxième instance] LZ4:

$ cd ./database_dir && mkdir lz4_s2 && cd lz4_s2
$ cp ../../server_config/config_lz4_s2.xml ./
$ numactl -C 30-59,150-179 [CLICKHOUSE_EXE] server -C config_lz4_s2.xml >&/dev/null&

ZSTD:

$ cd ./database_dir && mkdir zstd_s2 && cd zstd_s2
$ cp ../../server_config/config_zstd_s2.xml ./
$ numactl -C 30-59,150-179 [CLICKHOUSE_EXE] server -C config_zstd_s2.xml >&/dev/null&

IAA Deflate :

$ cd ./database_dir && mkdir deflate_s2 && cd deflate_s2
$ cp ../../server_config/config_deflate_s2.xml ./
$ numactl -C 30-59,150-179 [CLICKHOUSE_EXE] server -C config_deflate_s2.xml >&/dev/null&

Création des tables && insertion de données pour la deuxième instance Création des tables :

$ [CLICKHOUSE_EXE] client -m --port=9001

Insertion de données :

$ [CLICKHOUSE_EXE] client --query "INSERT INTO [TBL_FILE_NAME] FORMAT CSV" < [TBL_FILE_NAME].tbl  --port=9001

[TBL_FILE_NAME] représente le nom d’un fichier correspondant à l’expression régulière : *. tbl sous ./benchmark_sample/rawdata_dir/ssb-dbgen.
--port=9001 désigne le port attribué à l’instance de serveur, également défini dans config_lz4_s2.xml/config_zstd_s2.xml/config_deflate_s2.xml. Pour davantage d’instances, vous devez le remplacer par la valeur 9002/9003, qui correspond respectivement aux instances s3/s4. Si vous ne le définissez pas, le port utilisé par défaut est 9000, déjà attribué à la première instance.

Benchmark avec 2 instances LZ4 :

$ cd ./database_dir/lz4
$ numactl -C 0-29,120-149 [CLICKHOUSE_EXE] server -C config_lz4.xml >&/dev/null&
$ cd ./database_dir/lz4_s2
$ numactl -C 30-59,150-179 [CLICKHOUSE_EXE] server -C config_lz4_s2.xml >&/dev/null&
$ cd ./client_scripts
$ numactl -m 1 -N 1 python3 client_stressing_test.py queries_ssb.sql 2  > lz4_2insts.log

ZSTD:

$ cd ./database_dir/zstd
$ numactl -C 0-29,120-149 [CLICKHOUSE_EXE] server -C config_zstd.xml >&/dev/null&
$ cd ./database_dir/zstd_s2
$ numactl -C 30-59,150-179 [CLICKHOUSE_EXE] server -C config_zstd_s2.xml >&/dev/null& 
$ cd ./client_scripts
$ numactl -m 1 -N 1 python3 client_stressing_test.py queries_ssb.sql 2 > zstd_2insts.log

IAA deflate

$ cd ./database_dir/deflate
$ numactl -C 0-29,120-149 [CLICKHOUSE_EXE] server -C config_deflate.xml >&/dev/null&
$ cd ./database_dir/deflate_s2
$ numactl -C 30-59,150-179 [CLICKHOUSE_EXE] server -C config_deflate_s2.xml >&/dev/null&
$ cd ./client_scripts
$ numactl -m 1 -N 1 python3 client_stressing_test.py queries_ssb.sql 2 > deflate_2insts.log

Ici, le dernier argument : 2 de client_stressing_test.py correspond au nombre d’instances. Pour utiliser davantage d’instances, vous devez le remplacer par la valeur 3 ou 4. Ce script prend en charge jusqu’à 4 instances/ À présent, trois logs devraient s’afficher comme prévu :

lz4_2insts.log
deflate_2insts.log
zstd_2insts.log

Comment vérifier les métriques de performance : Nous nous concentrons sur le QPS ; veuillez rechercher le mot-clé : QPS_Final et recueillir les statistiques. La configuration du benchmark pour 4 instances est similaire à celle des 2 instances ci-dessus. Nous recommandons d’utiliser les données du benchmark sur 2 instances comme rapport final pour examen.

Conseils

Avant de lancer un nouveau serveur ClickHouse, assurez-vous qu’aucun processus ClickHouse ne s’exécute en arrière-plan ; vérifiez-le et arrêtez l’ancien :

$ ps -aux| grep clickhouse
$ kill -9 [PID]

En comparant la liste des requêtes dans ./client_scripts/queries_ssb.sql avec le Star Schema Benchmark officiel, vous constaterez que 3 requêtes n’y figurent pas : Q1.2/Q1.3/Q3.4 . En effet, l’utilisation du CPU est très faible (< 10 %) pour ces requêtes, ce qui ne permet pas de mettre en évidence des différences de performances.

Introduction

Compilation

Protocole natif

Contribuer

Feuille de route

Liste des fichiers

Exécuter automatiquement le benchmark du Star Schema :

Définition

Environnement

Générer des données brutes

Configuration de la base de données

Benchmark sur une seule instance

Benchmark avec plusieurs instances

Conseils

​Liste des fichiers

​Exécuter automatiquement le benchmark du Star Schema :

​Définition

​Environnement

​Générer des données brutes

​Configuration de la base de données

​Benchmark sur une seule instance

​Benchmark avec plusieurs instances

​Conseils

Liste des fichiers

Exécuter automatiquement le benchmark du Star Schema :

Définition

Environnement

Générer des données brutes

Configuration de la base de données

Benchmark sur une seule instance

Benchmark avec plusieurs instances

Conseils