- PR -

PostgreSQLのINSERT動作が遅い

1|2 次のページへ»
投稿者投稿内容
kei
ベテラン
会議室デビュー日: 2005/03/18
投稿数: 53
投稿日時: 2006-03-17 13:01
keiと申します。

LinuxにPostgreSQLをインストールし、大量のデータをINSERTさせているのですが、
ほとんど同じハード、ソフトで動作速度が極端に異なってしまっております。
postgreSQLを走らせたときのTOPコマンドで出てくるpostmasterというプロセスが
一方のサーバでは、殆どSTAT"R"滞在なのに対し、もう一方のサーバでは殆ど
STAT"D"滞在となっています。CPU使用率もSTAT"D"滞在の方は非常に低いです。
※STAT R:実行可能 S:停止 D:割り込み不可の停止

なぜなのか調査しているのですが、解決に至っておりません。
ちなみに、ハードの購入時期は１年ほど間があります。
チップセット等が変更になっていて、それが影響していたりするのでしょうか。

ベンチマークテストの実行時間、スコアはほぼ同じになっています。

以下より比較データです。

■ラックサーバ１（処理が早いほう）１年ぐらい前に購入
HARD:IBM eServer xSeries 336 8837PKU
OS:RedHat Enterprise ES3
Kernel:2.4.21-4.ELsmp
MEM:1Gbyte
SWAP:2Gbyte
PostgreSQL:postgresql-8.0.1

・SQLデータ更新処理
　perl sql_access_update.pl（SQLデータベースのみを更新するスクリプトです）
　0m45.902s
　TOPコマンドでのプロセス状況
　PS STAT CPU
　-----------------------------------
　perl R,S 10.2〜11.8％（殆どSTAT"R"に滞在していました。）
　postmaster R,D 6.1〜9.0％（殆どSTAT"R"に滞在していました。）
　※STAT R:実行可能 S:停止 D:割り込み不可の停止

・ベンチマークテスト結果
　TEST BASELINE RESULT INDEX

　Dhrystone 2 using register variables 116700.0 4375458.5 374.9
　Double-Precision Whetstone 55.0 731.7 133.0
　Execl Throughput 43.0 2452.8 570.4
　File Copy 1024 bufsize 2000 maxblocks 3960.0 171622.0 433.4
　File Copy 256 bufsize 500 maxblocks 1655.0 45774.0 276.6
　File Copy 4096 bufsize 8000 maxblocks 5800.0 428930.0 739.5
　Pipe Throughput 12440.0 582058.4 467.9
　Pipe-based Context Switching 4000.0 77496.3 193.7
　Process Creation 126.0 6572.8 521.7
　Shell Scripts (8 concurrent) 6.0 314.1 523.5
　System Call Overhead 15000.0 507955.5 338.6
　 =========
　 FINAL SCORE 375.9

■ラックサーバ２（処理が遅いほう）新しく購入
HOST:sstsv9
HARD:IBM eServer xSeries 336 8837PKT
OS:RedHat Enterprise ES3
Kernel:2.4.21-4.ELsmp
MEM:1Gbyte
SWAP:2Gbyte
PostgreSQL:postgresql-8.0.1

・SQLデータ更新処理
　perl sql_access_update.pl（SQLデータベースのみを更新するスクリプトです）
　15m21.325s（１５分もかかっています！！！）
　TOPコマンドでのプロセス状況
　PS STAT CPU
　-----------------------------------
　perl S,R 0.6〜1.0％（殆どSTAT"S"に滞在していました。）
　postmaster D,R 0.3〜1.2％（殆どSTAT"D"に滞在していました。）
　※STAT R:実行可能 S:停止 D:割り込み不可の停止
　★現用ラックサーバに比べて、CPU使用率が低く、postmasterのSTATが現用サーバが
　　殆どR滞在に対して、新サーバは殆どD滞在と、異なる動きが見られました。
　　それに合わせて、perlプロセスも同じような動きになってました。

・ベンチマークテスト結果
　TEST BASELINE RESULT INDEX

　Dhrystone 2 using register variables 116700.0 4271409.6 366.0
　Double-Precision Whetstone 55.0 754.6 137.2
　Execl Throughput 43.0 2900.5 674.5
　File Copy 1024 bufsize 2000 maxblocks 3960.0 167468.0 422.9
　File Copy 256 bufsize 500 maxblocks 1655.0 43698.0 264.0
　File Copy 4096 bufsize 8000 maxblocks 5800.0 414312.0 714.3
　Pipe Throughput 12440.0 579316.8 465.7
　Pipe-based Context Switching 4000.0 74413.1 186.0
　Process Creation 126.0 7585.5 602.0
　Shell Scripts (8 concurrent) 6.0 307.7 512.8
　System Call Overhead 15000.0 507963.5 338.6
　 =========
　 FINAL SCORE 380.9


以上よろしくお願いします。

せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2006-03-19 06:39
１）Postgres ですが、カーネルパラメータや、設定ファイルは双方のサーバともまったく同一のものでしょうか？
２）VACUUM は双方ともおこなっていますよね？
３）提示されている以外のプロセスが動作しているということはありませんか？

ちなみに、
コード:
・ベンチマークテスト結果
　TEST                                        BASELINE     RESULT      INDEX

　Dhrystone 2 using register variables        116700.0  4271409.6      366.0
　Double-Precision Whetstone                      55.0      754.6      137.2
　Execl Throughput                                43.0     2900.5      674.5
　File Copy 1024 bufsize 2000 maxblocks         3960.0   167468.0      422.9
　File Copy 256 bufsize 500 maxblocks           1655.0    43698.0      264.0
　File Copy 4096 bufsize 8000 maxblocks         5800.0   414312.0      714.3
　Pipe Throughput                              12440.0   579316.8      465.7
　Pipe-based Context Switching                  4000.0    74413.1      186.0
　Process Creation                               126.0     7585.5      602.0
　Shell Scripts (8 concurrent)                     6.0      307.7      512.8
　System Call Overhead                         15000.0   507963.5      338.6
　                                                                 =========
　     FINAL SCORE                                                     380.9

こんな感じで [CODE] でかこってあげると見やすくなります。
kei
ベテラン
会議室デビュー日: 2005/03/18
投稿数: 53
投稿日時: 2006-03-22 11:19
せん様
ご回答ありがとうございました。

カーネルパラメータや、設定ファイル等はすべて同一にしています。
今回させている処理は、新規でデータベース、テーブルを作成し、そこへ５万行
ぐらいのデータを１件ずつINSERTしていくというものです。
VACUUM処理は行っていません。
プロセスも見てみましたが、特に変なプロセスが動いているということも
ありませんでした。

pgbenchを動かしてみると、大きく違いが出てしまっています。
結果は以下の通りでした。

コード:
[postgres@sstsv6 pgbench]$ pgbench bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 421.567388 (including connections establishing)
tps = 483.980254 (excluding connections establishing)

[postgres@sstsv9 pgbench]$ pgbench bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 42.524600 (including connections establishing)
tps = 43.015933 (excluding connections establishing)


遅いほうはTOPのステータスでpostmasterが殆ど「D」に滞在しており、
これが根本的に処理を遅くしていると思うのですが、原因がわからず
困り果てております。

じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-03-22 11:57
DB サーバーは別端末にあるんですよね?
postmaster 起動時のオプションは特に何もなしですか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
kei
ベテラン
会議室デビュー日: 2005/03/18
投稿数: 53
投稿日時: 2006-03-22 13:01
じゃんぬねっと様

DBサーバは同じサーバ内にそれそれインストールしてあります。
postmasterの起動時のオプションは特に指定していません。

pg_ctl -w start
のみです。

postgresql-8.1.3を入れて試してみましたが、結果は同じでした。
冬寂
ぬし
会議室デビュー日: 2002/09/17
投稿数: 449
投稿日時: 2006-03-22 13:29
引用:

keiさんの書き込み (2006-03-22 11:19) より:
VACUUM処理は行っていません。

んーっと・・・VACUUMと、ANALYZEについて調べてみては？

後、insertした時にはindexを更新するはずなのでindexを調べてみると何か分かるかもしれません。
kei
ベテラン
会議室デビュー日: 2005/03/18
投稿数: 53
投稿日時: 2006-03-22 14:03
冬寂様
返信ありがとうございます。

データベースの使い方としては、DB、テーブルをまったく新規に作成して、
INSERTしたデータを参照するだけという形のものになっており、特にDELETE
など更新処理等を行っていないため、VACUUM処理は不要と考えています。
毎回DROP　DATABASEしてDBを作り直しておますので。

実際に、早く動く方のマシンもVACUUM処理を行っていません。
INDEXも使っていないんですよね。

チップセットとの相性とか、ハードディスクのRAIDの設定とか関係するので
しょうか？
せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2006-03-22 22:20
毎回 DATABASE の DROP & CREATE ですか。
じゃぁ VACUUM は関係ないですね。

Postgers のログになにかでていないか、
あとは、PG_DATA（だったかな？）がある場所、実際のデータベースのファイルが
存在するディスクの書込み／読み込みが遅いのかもしれません。


まさかと思いますが、１、２サーバとも同じ設定をしていて、両方とも１を見ている、
なんて事は無いですよね？
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）