[hackers-jp: 30] Re: [HACKERS] Experimental patch for inter-page delay in VACUUM

[井久保 寛明]

井久保です。

On Mon, 10 Nov 2003 18:48:55 +0900
TANIDA Yutaka <tanida ＠ sra.co.jp> wrote:

> > # 途中からの sync 云々の話は、斜め読みでは、ついていけないので後で読もう...。
> 
> 　これは恐ろしく端折ると「一部でsync()を使うけど、これだとPostgreSQL以外
> の書き込みまで行われるので、パフォーマンス劣化の原因だ」と言うことだと思
> います。

何が書いてあるか、なんとなく知っていると読みやすいので、助かります。

sync() は、チェックポイントを実行したときなどに動くやつですね。
あらためて考えると、ログなどを出力するプロセスがたくさんいると、
パフォーマンスがかなり落ちますね。


> > このパッチ、出されてみると、あって然るべきものですね。
> 
> どうでしょう。私も最初は画期的だと思ったのですが、よくよく考えると時間が
> 長くなっている分VACUUMがロックを占有する時間も長いんですよね。そっちの影
> 響の方が気になります。

主に使われるのは オンライン VACUUM 時で、ページを移る際のページロックを
手放したタイミングで sleep しているので、大丈夫なんじゃないですか？
# コードは見てないです。ニュアンスからそうかなと。

VACUUM のコードは、まだ追いかけたことがないので、他にどんなロックを
取るのか知りません。他に何かロックを所有していると、確かに気になりす。


テーブルロックをとるFULL VACUUM なら問題大有りですね。
それでも、こちらにも同じパラメータをつけるっていう議論を
していたようですが。


本来は、sleep なんかのごまかしじゃなくて、スケジューラのようなもので
やるべき話なんですよね。きっと。


> > pg_dump には、負荷を調整する機能があるんでしたっけ？ 
> > たぶん、なかったですよね。
> 
> 無いですね。むしろこちらの方が切実だと思いますが、独特の実装を持つVACUUM
> にそう簡単にはいかないでしょうねぇ。

pg_dump を引き受けたバックエンドプロセスの優先度(nice値)を下げたり、
データを要求する側に sleep を入れたりするっていうのはどうでしょう？
かなり乱暴な方法ですが、MVCCもあることだし、ロックの影響は小さい
ような気がするんですが。

---
井久保 寛明 (Hiroaki Ikubo)
ＮＴＴデータ先端技術 (株) ソリューション部
E-mail: ikubo ＠ intellilink.co.jp (E-mail: ikuboh ＠ nttdata.co.jp)