pgbenchを使ったPostgreSQLの性能検証

pgbenchで性能検証

とある案件でAuroraのデータベースエンジンにPostgreSQLを採用することになり、思ったようにパフォーマンスが出ないといった事態に陥りました。

その際に簡単にPostgreSQLの性能検証が出来るものはないかと探したところpgbenchなるものを発見。

今回は、そのpgbenchについて簡単にまとめてみたいと思います。


実行環境

マシンMacbook Pro
OSCatalina 10.15.6
プロセッサ2.3 GHz デュアルコアIntel Core i5
メモリ16GB
psql (PostgreSQL)12.4
pgbench (PostgreSQL)12.4

pgbenchとは

pgbenchとはPostgreSQLに同梱されているベンチマークツールです。 pgbenchを使うと、PostgreSQLの性能を数値で把握することができます。また他のツールとの掛け合わせで検証結果を可視化することも可能です。

注意

pgbenchは厳密な意味でのベンチマークツールではないとのことです。TPCなどで「公式」に認められているような性能測定を行う目的には向いていないみたいなので、その点についてはご注意ください。

しかし「公式に認められているような性能測定」を必要としない場合においては、導入コストの低さ、機能も豊富でpgbench自体の性能も高いです。簡単かつ高い精度でPostgreSQLの性能検証を行いたい場合にはオススメのツールと言えます。

導入方法

MacであればPostgreSQLをインストールする際にbrew install PostgreSQLとかすると思いますがPostgreSQLに同梱されているため一緒にインスールされます。便利!

環境によってはmake installが必要な場合もあるみたいですが、ここでは割愛します。

使ってみる

pgbenchを使う際は、検証用のデータベースを作っておくと良いです。実際に使っているデータベースを用いて性能を見ることも出来ますが、ここではtest_dbという名前のデータベースがあるという前提で進めていきます。

初期化

はじめに、ベンチマークデータを初期化する必要があります。以下のコマンドを実行します。

ここで使うオプションの意味を簡単に説明します。

i初期化モードを呼び出すために必要です。
sこの倍率で生成される行数を積算します。例えば[-s 100]はpgbench_accountsテーブルに10,000,000行を生成することを意味します。デフォルトは1です。iオプションと一緒に使用します。
UDBログインユーザ名
hDBホスト名
dデバッグの出力。データベースの指定ではありません

Pオプションを指定するとパスワードを予め指定して実行することが出来ますが、psコマンドなどで見られる可能性があり セキュリティホールとなる場合があるため、推奨されません。

上記コマンドを実行するとtest_dbのpublicスキーマの中に以下4つのテーブルが出来ていることが確認できます。

  • pgbench_accounts
  • pgbench_branched
  • pgbench_history
  • pgbench_tellers

-s 100を指定したことにより pgbench_accountsテーブルには10,000,000レコードが入っていると思います。

この時、既に同じ名前のテーブルが存在している場合、既存のものは削除されてしまうためご注意ください。

ベンチマークの実行

コマンドに使用したオプション「-c」は同時接続数(コネクション数)を指定しています。
つまり、今回のベンチマークでは同時に10本のコネクションがPostgreSQLに張られることを想定しています。 10人のユーザが、とあるサイトに同時にアクセスするような環境をシミュレートしたということですね。

続いて、オプション「-t」は各接続が実行するトランザクションの数を指定しています。
1000を指定していますので、「10人のユーザが1000回ずつ、とあるサイトに同時にアクセスした」というような負荷のかけ方を再現しています。

ベンチマーク結果の見方

データサイズの規模を示すスケーリングファクタです。
ここの数字が大きければ大きいほどデータサイズが大きいことになります。

問い合わせ方法を示しています。
simpleとなっていますのでpsqlなどが利用している標準の方法で問い合わせたことがわかります。 この他にも拡張プロトコルなどを使った問い合わせ方法もあります。

上述にあるオプション「-c」の数となります。
実行時に10を指定したので同時接続が10であったことを示しています。

実行時に作成されるスレッド数を示しています。
オプション「-j」または「–jobs」で指定することが可能です。

上述にあるオプション「-t」の数となります。
実行時に1000を指定したので1クライアントあたり1000回のトランザクションを実行したことを示しています。

トランザクションが正常に実行された割合を示しています。
クライアント数10*トランザクション数1000=10000回となります。

1トランザクションの実行時間を示しています。pgbench9.5以前では表示されず9.6以降から実装されたものになります。

Transactions Per Secondの略称。
前者は接続確立にかかった時間も考慮した実行トランザクション数を示しています。 後者は接続確立にかかった時間を考慮しない実行トランザクション数を示しています。

トランザクションを発行して負荷をかけてみる

デフォルトのトランザクションスクリプトは、1トランザクションで以下の7コマンドを発行します。

オプション-Nを指定した場合、第4、第5コマンドはトランザクションに含まれず、-Sを指定するとSELECTのみが発行されます。

引用元: PostgreSQL 9.2.4文書 pgbench

独自スクリプトの利用

前述の様なデフォルトのトランザクションを発行しても意味が無いとは言いませんが、やはり実際のシステムの性能を測るためには現実に即したトランザクションを発行して性能を確かめておきたいものです。

pgbenchには利用者が用意した任意のSQLをトランザクションとして発行することが可能です。
具体的には実際に発行したいSQLを「任意の名前.pgbench」の形式でファイル保存し以下のように「-f」オプションを付けコマンドを実行します。

こうすることにより標準のデフォルトトランザクションではなくファイルに書かれたSQL文が実行されます。自前のSQLを発行することになるため予めデータベースや各種テーブルを用意しておく必要があります。

まとめ

導入から実践までを簡単にご紹介しましたが如何だったでしょうか? データベースの検証はいくつか方法がありますが、pgbenchを使うと簡単に性能検証をすることが出来ます。

データベースサーバのチューニングや、実際に発行されるクエリのチューニング結果をすぐに性能検証でき、数値化されるところがいいですね。

また本記事では割愛しましたがgnuplotなどの他のプログラムと組み合わせるとグラフとして可視化することも出来ます。うまく使えば、ボトルネックになりがちなデータベースのパフォーマンスを最大限引き出すことも出来るはずなので 是非使ってみてください。

参考記事