[pgsql-jp: 38402] Re: pgbenchの結果のブレ

[Tatsuo Ishii]

石井です．

> こんにちは、海外です。
> 
> SE-PostgreSQLによる強制アクセス制御のコストを測定するため、
> pgbench を用いてベンチマークを行ってみました。
> 
> しかし、その結果にやや腑に落ちない点があります。(nativeの
> PostgreSQL・SE-PostgreSQLの双方において)
> 何かヒントになるような点、ご存知であれば教えて頂けないで
> しょうか？
> 
> 奇妙な測定結果とは、何回か測定を繰り返した際に、極端にTPS
> の低い結果が出るというものです。
> 例えば、以下の結果は native-PostgreSQL 8.2.4 のデフォルト
> 設定で、Scaling Factor=10、クライアント数=8 で実行した場
> 合の TPS ですが、1000前後のTPSに混じって、16.45という非常
> に小さな値が混じっています。
> 
>  1回目 1124.34559
>  2回目  115.35148
>  3回目 1078.44326
>  4回目   16.45351 *
>  5回目  991.73143
>  6回目  786.34511
>  7回目  428.79003
>  8回目 1098.39565
>  9回目 1111.29632
> 10回目 1088.30951
> (平均 = 783.9462、標準偏差 = 435.4632464)
> 
> この様な特異値(?)はどのように解釈すべきものなのでしょうか？
> それとも、pgbenchの実行方法・実行環境に起因する何かがあるの
> でしょうか？
> 
> 参考までに、測定の結果得られた平均値と標準偏差を以下に記します。
> クライアント数が多くなるほど標準偏差が大きくなる傾向があるようです。
> 
>  #    SE-PostgreSQL     native-PostgreSQL
>  1   582.94 ( 25.58)     610.42 ( 73.07)
>  2   873.54 ( 77.91)     926.09 ( 92.41)
>  3   960.91 ( 56.04)     997.22 (134.55)
>  4   950.13 ( 52.23)    1100.72 ( 33.79)
>  5   883.68 (203.26)     803.13 (482.88)
>  6   793.14 (274.12)    1012.29 (110.66)
>  7   730.24 (407.75)     958.13 (328.88)
>  8   864.67 (285.68)     783.95 (435.46)
> 
> ※ 結果は10回の平均値、カッコ内標準偏差
> ※ クライアント数を 1〜8 の間で変化させて測定
> ※ PostgreSQLの設定パラメータは全て 8.2.4 の標準値
> ※ pgbenchのScaling Factorは10

おそらくPostgreSQLのチェックポイント処理の影響と思われます．
pgbenchの-tパラメータ（トランザクション数）を調整し，pgbenchの走行時間
を10-30分以上になるようにしてみてはどうでしょう？

ちなみに，今開発中の8.3のpgbenchでは，単なるトータルのTPSではなくて処
理遅延を計測できるようになっています．これとスクリプトを組み合わせて時
間とともに性能がどう変化するか見ることができるようにした方がいます．以
下で紹介していますので，ご参考までに．

http://itpro.nikkeibp.co.jp/article/COLUMN/20070409/267852/?ST=lin-server&P=6

そのスクリプトを動かすと，以下のようなグラフが得られ，

http://itpro.nikkeibp.co.jp/article/COLUMN/20070409/267852/tps.jpg

チェックポインとの影響であろうと思われる激しい性能の落ち込みを見ること
ができます．

ところで，SE-PostgreSQLのアーキテクチャは良く分からないのですが，オー
バヘッドを見るだけならば，更新を含まないクエリの方がはっきり出るという
ことはないですか？それであれば，pgbenchに-Sオプションを付けて実行すれ
ば目的を達成できます．ただし，その場合はキャッシュのウォーミングアップ
の影響が強く出るので，-t には 1000以上程度指定するのがお勧めです．
--
Tatsuo Ishii
SRA OSS, Inc. Japan