SQLベースのベンチマークを行う際に、実施していただきたい5つの項目

Primary tabs

本稿について

本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい5つの項目をご紹介します。
Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。

1. メモリ自動設定をやめる

自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。
IRIS単独のベンチマークであれば、下記を目途に、明示的に設定を行ってください。
実メモリ64GB未満:実メモリの50%
実メモリ64GB以上:実メモリの70%

詳細はこちらです。

また、Linuxの場合、ヒュージ・ページ有効化の設定を行ってください。設定値の目安ですが、IRIS起動時のメッセージから、確保される共有メモリサイズ(下記だと749MB)を読み取り、その値めがけて設定するのが簡単です。

# iris start iris
Starting IRIS
Using 'iris.cpf' configuration file
Starting Control Process
Allocated 749MB shared memory: 512MB global buffers, 64MB routine buffer
# cat /proc/meminfo
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

ページサイズが2048kBですので、750MB(丸めました)を確保するには750/2=375ページ必要になります。構成を変えると必要な共有メモリサイズも変わりますので、再調整してください。

# echo 375 > /proc/sys/vm/nr_hugepages
# iris start iris
Starting IRIS
Using 'iris.cpf' configuration file
Starting Control Process
Allocated 750MB shared memory using Huge Pages: 512MB global buffers, 64MB routine buffer

メモリ関連の設定値は、パフォーマンスに大きく影響しますので、比較対象のDBMSが存在するのであればその設定値、自動構成の場合はその最大許容値に合わせてください。

2. データベース関連ファイルの配置

特にクラウド上でのベンチマークの場合、ストレージのレイアウトがパフォーマンスに大きな影響を与えます。クラウドではストレージごとのIOPSが厳格に制御されているためです。

こちらに細かな推奨事項が掲載されていますが、まずは下記のように、アクセス特性の異なる要素を、それぞれ別のストレージに配置することをお勧めします。

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        850G  130G  720G  16% /irissys/data      (IRIS本体のインストール先、ユーザデータべース)
/dev/sdd        800G  949M  799G   1% /irissys/wij       (ライトイメージジャーナルファイル)
/dev/sde        200G  242M  200G   1% /irissys/journal1  (ジャーナルファイル)
/dev/sdf        100G  135M  100G   1% /irissys/journal2  (予備のジャーナルファイル保存エリア)

サイズはシナリオ次第です。WIJに割り当てているサイズが大きめなのは、IOPS性能がファイルシステムの容量に比例するクラウドを使用するケースを強調するためです。

3. テーブルへのインデックス追加 

IRISのテーブルへのインデックス追加は自動ではありません。
多くのRDBMS製品と同様に、CREATE TABLE命令の実行時に、プライマリキー制約やユニーク制約が指定されている場合、インデックが追加されますが、それ以外のインデックスはCREATE INDEX命令で明示的に追加する必要があります。

どのようなインデックスが有用なのかは、実行するクエリに依存します。
一般に、ジョインの結合条件(ON句)となるフィールド、クエリの選択条件(WHERE句)となるフィールドが対象となります。
こちらを参照ください。

4. 統計情報の取得 

IRISはクエリの実行プランを最適化するために、テーブルデータに関する統計情報を使用します。
統計情報の取得処理(TuneTable/TuneSchema)は、初期データロード後に明示的に実行する必要があります。

TuneTable(テーブル対象)/TuneSchema(スキーマ対象)を実行すると、既存のクエリプランがパージされるので、次回の初回クエリ実行時はクエリ解析・プラン生成にかかる分だけ時間が多めにかかります。
また、TuneTable/TuneSchema実行後にインデックスを追加した場合には、そのテーブルに対してTuneTableを再実行してください。

管理ポータル及びCLIから実行可能です。
ベンチマーク環境であれば、(統計情報の更新を繰り返し実行する可能性が高いことを考慮すると)下記のObjectScriptのCLIで一括で実施するのが効果的です。

MYDB>d $SYSTEM.SQL.TuneSchema("MySchema",1,1)

5. Query ソース保存有効化

実行プランがコード化されたものがソースコードとして保存されます。デフォルトでは無効です。
本稿では扱っていませんが、後の解析で有用になることもありますので、念のため有効化しておきます。

一通りのベンチマークを実行

この時点での実行結果は思った結果が得られないかもしれません。
ベンチマークプログラムによるレコードのINSERTにより、ユーザデータベースの自動拡張、一時データべースの自動拡張、WIJの自動拡張が、クエリにより、クエリプランの作成、インデックスの不足によるテーブルフルスキャンなどが発生している可能性があるためです。
(ベンチマーク実施により蓄積したデータの消去後の)2回目以降は、インデックスの不足以外の問題は解消されているので、パフォーマンスが向上するかもしれません。
また、これとは逆にジャーナルは、随時蓄積していきますので、ベンチマーク実施を繰り返すうちに、いずれはディスクの空き容量を圧迫します。
適宜ジャーナルファイルを削除してください。運用環境では絶対禁止の方法ですが、データの保全が必要のないベンチマーク環境でしたら、最新のジャーナルファイル以外をO/Sシェルでrmしてしまって構いません。

これ以後の、細かな確認作業はさておき、まずは上記5つの項目の実施をスタートラインとすることをお勧めします。