[pgsql-jp: 28424] Re: updateの性能を向上

Tamotsu Ebina ebina @ pluto.dti.ne.jp
2002年 12月 23日 (月) 17:13:53 JST


海老名@インフォテックです

7倍といっても2分程度かかっていると言うことですね。
こちらのテストに比べるとずいぶん遅い感じがします。

fsyncについては、少し旧聞ですが、
http://archives.postgresql.org/pgsql-hackers/2001-04/msg01129.php
に記事がありますが、fsyncはプラットフォーム、バージョンに依存するので
そちらのSoralis環境下で実際にテストするするしかないと思います。
私の環境では自由に使えるSolarisが無いのでテストできません。

信頼性を犠牲にして速度だけ求めるならfsync=falseもありかな?
当然こちらの方が数段速いです。

7.1ではSolarisのマルチプロセッサーでは逆にパフォーマンスが
IntelPCの1/10以下に落ちると同じアーカイブに記事が有りました。
これが7.2.1で解決しているのかは分かりません。

私もチューニングに苦労していますがポイントは、当たり前ですが
1)SQLの最適化
2)WALの最適化
ですね。
このパラメータをこう直せば飛躍的に速くなると言った魔法は無いようです。
(あればデフォルト値になっているはず)

以前指摘されたとおり、javaアプリケーションで
「テーブルから順に1件ずつ読んで該当のキーのレコードが他のテーブルに
登録されていなかったら別のテーブルにinsertする」
と言う処理は、このままのロジックで手続き型でプログラミングするより、
select文のwhere句で not exists in を使用した方が当然速くなりました。


正確に測定していませんが、
pg_config.h の BLCKSZ を16Kにするとランダムの更新処理は逆に遅くなりませんか?
こちらでのテストではバッチ的な連続insert処理では速くなりましたがランダム更新は
時間測定できていません。
一般的な話ですが、バッファサイズが大きくなれば
ランダムの検索・更新処理は遅くなりますよね?
8kと言う値が今までの経験値から
「いろいろな場合に最適と言うことでデフォルト値になっている」はず
と勝手に考え、私の方は元に戻しました。

それとPostgreSQL本体のバージョンアップはできませんか?
ソースをダウンロードしてmakeするだけなら30分もかからないと思いますが。
どういう点のパフォーマンスアップがされているのかリリースノートだけでは
よく分かりませんが、これも勝手な推量ですが改良されているのは確かだと
信じて、なるべく新しいバージョンを使用しています。


----- Original Message -----
From: <fukudami @ ntes.nec.co.jp>
To: <pgsql-jp @ ml.postgresql.jp>
Sent: Monday, December 23, 2002 7:34 AM
Subject: [pgsql-jp: 28421] Re: updateの性能を向上


> 福田です。
>
> 皆さんのご協力のおかげで、苦闘しながらなんとか性能を7倍程度まで
> もっていくことができました。ありがとうございます。
>
> 現在までに施した対処としては、
> ・indexを張り、全件検索を回避(まだ最適化が必要です)
> ・pg_config.h の BLCKSZ を16Kに変更
> ・shared_buffersを5120に変更
> ・sorrt_memを2048に変更
> ・max_connectionを128に変更
>
> なんか力技ばかりのようですが・・
>
> ここでもう一度皆さんのお知恵をお借りしたいのですが、wal_sync_methodの
> 最適化も有効であるとの情報を見つけました。FSYNC, FDATASYNC, OPEN_SYNC,
> OPEN_DATASYNCのうち、こちらで動かすマシンにおいてどれが最適なのか環境に
> よって異なることは承知していますが、時間の制約上、既にご存知の方が
> いらっしゃったら最適な設定をご教授いただけないでしょうか。(当然fsyncはONです)
> マシンのスペックは、一昨日のマシンとは変わって
> CPU:SPARC III(900MHz), メモリ:2GBで、




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