-
ホストマシンが 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_dirdbgen を使用して、以下のパラメーターで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次のような出力が表示されるはずです:
┌[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.logIAA 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.logZSTD:
$ 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.logZSTD:
$ 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.logIAA 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% であるため、性能差を十分に示せないためです。