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

Kenji Ono ono @ fjct.fujitsu.com
2004年 2月 20日 (金) 09:47:46 JST


小野です。

> > マシンスペックが、CPU:SPARC64 V1個、Mem:2G、でWEB+
> > DBが同居する形のマシン上で以下のテストをしてみました。
> > ・あるテーブルの1行を更新するクエリを投げるPHPを作成
> > ・そのプログラムを起動するPHPをbodyのonLoadで実行するように
> >  し、300フレーム分割する
> > ・これを2台のPCで同時に呼び出す事で600アクセスを擬似的に
> >  起こす
> > TOPコマンドで確認したところ、CPUは100%、メモリは2G中1Gくらい
> > 使ってました。
> > DBに対するアクセスは15回/1秒くらいになってました。
> 
> 上記のテストは実際のアプリケーション(と同じもの)で試したのでしょうか?

ほぼ同じです。
一応、登録先テーブルをSELECTしてそこのテーブルのPRIMARY KEYをWHERE
条件に更新するものです。
 
> CPUを使っていたのが、PostgreSQLなのかPHPなのかApacheなのかが
> 分からないと何とも言えませんが、CPU 1個だと結構厳しそうな気がしますね。
> DBとWebサーバを分けるのであれば、2CPUあればいけるかもしれません。
> 
> 「15回/1秒」という性能がI/O boundだとCPU増やしても意味ありませんが。

IO系がほとんどだったような気がします・・・。
今担当がいないので計測したコマンドがわからないのですが、
20:21:54      41      11      30      19   20:21:55   80377  5368776
20:21:56      63      24      13       0   20:21:58   78482  5315913
20:21:59      66      21      13       0   20:22:00   73227  4967126
20:22:01      77      21       2       0   20:22:03   77898  5301164
20:22:04      81      19       0       0   20:22:05   71922  4941185
20:22:07      69      21      10       0   20:22:09   61381  4208151
20:22:10      71      20       9       0   20:22:11   77611  5338240
20:22:13      59      14      27       0   20:22:14   76060  5200373
20:22:15      36      23      42       0   20:22:16   71514  4905805
左から処理時間、IO、USR、SYS、だったような記憶があります。

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

勉強します。

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

確かに、今でもプロセスの起動時間はバラバラですが、常にpostmaster
が10個くらい立ってます。
これも同時アクセス数分くらいあがるようにチューニングしたほうが良
いのでしょうか。

なかなかおくが深いです。(^^;;



pgsql-jp メーリングリストの案内