[pgsql-jp: 32323] Re: 数万アクセスに対する対処について

[Satoshi Nagayasu]

永安です。

> 永安さん、今日は。小野です。
> 
> マシンスペックが、CPU：SPARC64 V１個、Mem：２Ｇ、でＷＥＢ＋
> ＤＢが同居する形のマシン上で以下のテストをしてみました。
> ・あるテーブルの１行を更新するクエリを投げるＰＨＰを作成
> ・そのプログラムを起動するＰＨＰをbodyのonLoadで実行するように
> 　し、３００フレーム分割する
> ・これを２台のＰＣで同時に呼び出す事で６００アクセスを擬似的に
> 　起こす
> ＴＯＰコマンドで確認したところ、CPUは100%、メモリは2G中1Gくらい
> 使ってました。
> ＤＢに対するアクセスは１５回／１秒くらいになってました。

上記のテストは実際のアプリケーション(と同じもの)で試したのでしょうか？

CPUを使っていたのが、PostgreSQLなのかPHPなのかApacheなのかが
分からないと何とも言えませんが、CPU 1個だと結構厳しそうな気がしますね。
DBとWebサーバを分けるのであれば、2CPUあればいけるかもしれません。

「15回/1秒」という性能がI/O boundだとCPU増やしても意味ありませんが。

「あるテーブルの1行を更新」というのが、実際のアプリケーションと
あまり関係のない処理なのでしたら、
まずは、「実際のアプリケーション」で「上記スペックマシン」の
「DB単体サーバ」としての限界性能を探った方がいいと思います。

また、updateだけではなく、適度にselectなども混ぜた方がいいと思います。
要するに、よりリアルなシミュレーションを、ということですが。

# DBサーバ単体で評価する場合には、Perlなどで子プロセスを
# 100個くらい作ってsleepしておいて、
# シグナルを受けたら子プロセスが DBI でコネクションを張って
# クエリを流し始めるような形を使うと簡単でいいと思います。
# まぁCで書いてもいいんですけど。

> あまり詳しくないので初歩的な話しですが、PG_QUERYを呼び出すと
> Fork&Exceが発生するのですか。
> それともPG_CONNECTION毎でしょうか。

すみません。先ほどは間違えましたが、
pg_connect のたびに fork が発生します。

> CPUは2枚でもいけそうなのかな。
> 4枚さしてMem2Gだと400万くらいしそう・・・。

CPUを増やすと、その分処理できる(バックエンド)プロセスは増えるのですが、
むやみにCPU（とバックエンドプロセス）を増やすと、
今度は多数のバックエンドプロセスからI/O処理が集中して、
ディスクアクセスが律速に（なって、CPUが無駄に）なる確率が高くなります。

ので、両方（CPUとI/O）を適度にバランスさせる必要があると思います。
もちろんメモリも、ですが。

# とは言え、PostgreSQLはI/O分散の処方箋がかなり貧弱なのですが。

-- 
NAGAYASU Satoshi <snaga ＠ snaga.org>