DEFLATE_QPL でベンチマークを実行する

ホストマシンが QPL の必要な前提条件を満たしていることを確認してください
cmake ビルドでは、deflate_qpl はデフォルトで有効になっています。誤って変更した場合は、ビルドフラグ ENABLE_QPL=1 を再確認してください
一般的な要件については、ClickHouse の一般的なビルド手順を参照してください

ファイル一覧

qpl-cmake 配下の benchmark_sample フォルダーには、Python スクリプトでベンチマークを実行するための例があります。 client_scripts には、一般的なベンチマークを実行するための Python スクリプトが含まれています。たとえば、次のとおりです。

client_stressing_test.py: [1~4] 台のサーバーインスタンスに対してクエリのストレステストを実行する Python スクリプトです。
queries_ssb.sql: Star Schema Benchmark のすべてのクエリを一覧化したファイルです
allin1_ssb.sh: ベンチマークのワークフロー全体を自動で一括実行するシェルスクリプトです。

database_files には、lz4/deflate/zstd コーデックに応じたデータベースファイルが保存されます。

Star Schema のベンチマークを自動実行する:

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

完了したら、このフォルダ内のすべての結果を確認してください:./output/ 失敗した場合は、以下のセクションを参照してベンチマークを手動で実行してください。

定義

[CLICKHOUSE_EXE] は、clickhouse 実行ファイルのパスを指します。

環境

CPU: Sapphire Rapid
OS 要件については QPL のシステム要件を参照してください
IAA のセットアップについては Accelerator Configuration を参照してください
Python モジュールをインストールします:

pip3 install clickhouse_driver numpy

[IAA の自己チェック]

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

想定される出力は以下のとおりです。

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

何も出力されない場合は、IAA の準備がまだ整っていません。IAA の設定をもう一度確認してください。

生データを作成する

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

dbgen を使用して、以下のパラメーターで1億行のデータを生成します。 -s 20 *.tbl などのファイルは、./benchmark_sample/rawdata_dir/ssb-dbgen 配下に出力される想定です。

データベースのセットアップ

LZ4コーデックを使用したデータベースのセットアップ

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

ここでは、コンソールに Connected to ClickHouse server というメッセージが表示されるはずです。これは、クライアントがサーバーとの接続の確立に成功したことを意味します。以下の Star Schema Benchmark に記載されている 3 つの手順を完了してください。

ClickHouse でテーブルを作成する
データを挿入する。ここでは、入力データとして ./benchmark_sample/rawdata_dir/ssb-dbgen/*.tbl を使用してください。
“star schema” を非正規化された “flat schema” に変換する

IAA Deflate コーデックを使用してデータベースをセットアップする

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

上記のlz4と同じ3つの手順を実行します ZSTD コーデックを使用してデータベースをセットアップする

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

上記の lz4 と同じ 3 つの手順を完了してください [self-check] 各コーデック (lz4/zstd/deflate) について、データベースが正常に作成されていることを確認するため、以下のクエリを実行してください：

SELECT count() FROM lineorder_flat

次のような出力が表示されるはずです:

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

[IAA Deflate コーデックのセルフチェック] クライアントから初めて挿入またはクエリを実行した際、ClickHouseサーバーのコンソールには次のログが出力されるはずです:

Hardware-assisted DeflateQpl codec is ready!

これが見つからず、代わりに以下のような別のログが表示される場合:

Initialization of hardware-assisted DeflateQpl codec failed

これは、IAA デバイスの準備が整っていないことを意味します。IAA の設定をもう一度確認してください。

単一インスタンスでのベンチマーク

ベンチマークを開始する前に、C6 を無効にし、CPU 周波数ガバナーを performance に設定してください

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

ソケット間でのメモリバインドの影響をなくすため、numactl を使ってサーバーを一方のソケットに、クライアントをもう一方のソケットにバインドします。
単一インスタンスとは、1 台のサーバーに 1 台のクライアントが接続されている構成を意味します

次に、LZ4/Deflate/ZSTD それぞれについてベンチマークを実行します。 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

これで、想定どおり3件のログが出力されるはずです：

lz4.log
deflate.log
zstd.log

パフォーマンスメトリクスの確認方法: ここではQPSに注目します。QPS_Final というキーワードで検索し、統計情報を収集してください

複数インスタンスでのベンチマーク

スレッド数が多すぎることによるメモリボトルネックの影響を抑えるため、複数インスタンスでベンチマークを実行することを推奨します。
マルチインスタンスとは、それぞれ専用のクライアントが接続された複数 (2 台または 4 台) のサーバー構成を指します。
1 つのソケット内のコアは均等に分割し、それぞれのサーバーに割り当てる必要があります。
マルチインスタンスでは、コーデックごとに新しいフォルダーを作成し、単一インスタンスと同様の手順でデータセットを挿入する必要があります。

違いは 2 つあります。

クライアント側では、テーブルの作成時およびデータの挿入時に、割り当てられたポートを指定して clickhouse を起動する必要があります。
サーバー側では、ポートが割り当てられた特定の XML 設定ファイルを指定して clickhouse を起動する必要があります。マルチインスタンス用にカスタマイズされた XML 設定ファイルは、すべて ./server_config 配下に用意されています。

ここでは、1 ソケットあたり 60 コアあるものとし、2 インスタンス構成を例に説明します。 1 つ目のインスタンス用のサーバーを起動します 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&

[2つ目のインスタンス用のサーバーを起動] 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&

2つ目のインスタンスのテーブル作成 && データ挿入テーブルの作成:

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

データの挿入：

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

[TBL_FILE_NAME] は、./benchmark_sample/rawdata_dir/ssb-dbgen 配下で正規表現 *. tbl に一致する名前のファイル名を表します。
--port=9001 は、config_lz4_s2.xml/config_zstd_s2.xml/config_deflate_s2.xml でも定義されている、サーバーインスタンスに割り当てられたポートを表します。さらにインスタンスを増やす場合は、s3/s4 インスタンスに対応する値 9002/9003 に置き換える必要があります。指定しない場合、デフォルトのポートは 9000 で、これは最初のインスタンスですでに使用されています。

2 インスタンスでのベンチマーク 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

ここで、client_stressing_test.py の最後の引数 2 はインスタンス数を表しています。インスタンスを増やすには、これを 3 または 4 に置き換える必要があります。このスクリプトは最大 4 インスタンスまで対応しています。すると、想定どおり 3 つのログが出力されるはずです:

lz4_2insts.log
deflate_2insts.log
zstd_2insts.log

パフォーマンスメトリクスを確認する方法: ここではQPSに注目します。QPS_Final をキーワードとして検索し、統計情報を収集してください 4インスタンスのベンチマーク設定は、上記の2インスタンスの場合と同様です。レビュー用の最終レポートには、2インスタンスのベンチマークデータを使用することを推奨します。

ヒント

新しいClickHouseサーバーを起動する前に、バックグラウンドでClickHouseプロセスが実行されていないことを毎回確認し、古いプロセスがあれば終了してください:

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

./client_scripts/queries_ssb.sql 内のクエリ一覧を公式の Star Schema Benchmark と比較すると、含まれていないクエリが 3 つあることがわかります: Q1.2/Q1.3/Q3.4。これは、これらのクエリでは CPU 使用率が非常に低く < 10% であるため、性能差を十分に示せないためです。

はじめに

ビルド

ネイティブプロトコル

コントリビューション

ロードマップ

DEFLATE_QPL でベンチマークを実行する

ファイル一覧

Star Schema のベンチマークを自動実行する:

定義

環境

生データを作成する

データベースのセットアップ

単一インスタンスでのベンチマーク

複数インスタンスでのベンチマーク

ヒント

​ファイル一覧

​Star Schema のベンチマークを自動実行する:

​定義

​環境

​生データを作成する

​データベースのセットアップ

​単一インスタンスでのベンチマーク

​複数インスタンスでのベンチマーク

​ヒント

ファイル一覧

Star Schema のベンチマークを自動実行する:

定義

環境

生データを作成する

データベースのセットアップ

単一インスタンスでのベンチマーク

複数インスタンスでのベンチマーク

ヒント