[pgsql-jp: 41026] Re: pg_dumpの処理速度

2012年 1月 11日 (水) 17:56:20 JST

川原です。

永安様、ご回答ありがとうございます。

それではLOCK処理が遅くならない範囲でpg_dumpを分割するか、
PITR方式に切り替えるか検討したいと思います。

ありがとうございました。

--- On Wed, 2012/1/11, Satoshi Nagayasu <satoshi.nagayasu ＠ gmail.com> wrote:

> 永安です。
> 
> > 川原です。
> > 
> > 永安様、ご回答ありがとうございます。
> > 
> > pg_dumpは、AccessShareLockレベルのロックを全テーブルに
> > 対して獲得した後に、実際のデータをバックアップするようです。
> > 伝わりにくかった部分があったかもしれませんが、今回はその
> > ロックについてです。
> > 
> > 今回は、pg_dumpが獲得するロックがロック数が増えるたびに
> > 遅くなっているようなので、どうにかできないかと考えた次第です。
> > （例えばロック処理を行わずにpg_dumpできないかなど…）
> 
> なるほど。
> 
> 「ロック処理を行わず」という選択肢は、通常のpg_dumpにはありませんが、
> （ソースを書きかえればできますが・・・）
> 全テーブルを通した一貫性が特に必要ないのであれば、
> pg_dumpの-tオプションで個別にテーブル名を指定しながら、
> 10万回（？）テーブル単位でpg_dumpする、という方法でしょうか。
> 
> 動作確認はしてませんが、テーブル単位でpg_dumpすれば、
> 10万のテーブルに一括して（pg_dumpの）LOCK TABLEが走る事態は
> 避けられるように思います。
> 
> http://www.postgresql.jp/document/pg825doc/html/app-pgdump.html
> 
> テーブル名指定にはワイルドカードも使えるようなので、
> うまくすれば10回くらいのpg_dumpに分けてバックアップできるのでは。
> （テーブルのネーミングルール次第ですが・・・）
> 
> > 確かにロック獲得後のディスク書き出しがボトルネックになっている可能性は
> > 十分にあると思うのですが。
> > 
> >  > pg_dumpは他のユーザによるデータベースへのアクセス（読み書き）をブロックしません。
> > ちなみに、確かにマニュアルには永安様が仰ったとおり記載されておりますが、
> > TRUNCATEなどのDDLはブロックされたように記憶しております。
> 
> 確かに。
> 
> ACCESS EXCLUSIVEと競合するとありますので、
> 一部のDDL文やメンテ系コマンドとは競合しますね。
> 
> http://www.postgresql.jp/document/pg821doc/html/explicit-locking.html
> 
> 
> > 
> > --- On Wed, 2012/1/11, satoshi.nagayasu ＠ gmail.com <satoshi.nagayasu ＠ gmail.com> wrote:
> > 
> >> 永安です。
> >> 
> >> >> > LOCK処理が早くなれば、pg_dumpの並列化を独自に行って
> >> >> > 早くなれればいいなと考えております。
> >> 
> >> 素朴な疑問なのですが、本当にロックがボトルネックなのでしょうか？
> >> 
> >> ここで言っている「ロック」というのは、pg_dumpではなく、
> >> 業務トランザクションの「ロック」のことですよね。
> >> pg_dumpはロック競合しないはずなので、いまいち状況が
> >> 分からないのですが、
> >> 
> >> > pg_dumpは他のユーザによるデータベースへのアクセス（読み書き）をブロックしません。
> >> > http://www.postgresql.jp/document/8.2/html/app-pgdump.html
> >> 
> >> pg_dump時のディスク書き出しがボトルネックになっていたり
> >> しないのでしょうか？
> >> 
> >> いろいろ試す前に、まずは何がボトルネックになっているのかを
> >> 明確にしてからの方がよいのではないかと思います。
> >> 
> >> > Date: Tue, 10 Jan 2012 15:29:21 +0900 (JST)
> >> > From: <xrstt070 ＠ yahoo.co.jp>
> >> >
> >> > 川原です。
> >> >
> >> > ご回答ありがとうございます。
> >> >
> >> > すみません。環境をを記載しておりませんでした。
> >> > RHEL5上でPostgresql8.2を動作させております。
> >> >
> >> > ちなみに、バックアップ全体では2~3時間ほどかかっております。
> >> > 確かにそれに比べると15分は短いですね。。。
> >> > PITRの件、使えるか調査してみます。
> >> >
> >> > --- On Tue, 2012/1/10, TAKATSUKA Haruka <harukat ＠ postgresql.jp> wrote:
> >> >
> >> >> 高塚 と申します。
> >> >>
> >> >> 大きいデータの pg_dump の所要時間からすると +15分 は、微々たる
> >> >> 部分という気もします。全体でどのくらい時間を要しているのでしょうか。
> >> >>
> >> >> 本件はパラメータチューニングでどうにかなるものでは無さそうです。
> >> >>
> >> >> 全体を速くするなら pg_dump から PITR 方式に切り替えるのが有力です。
> >> >>
> >> >> # PostgreSQLバージョンやプラットフォームを提示いただけると
> >> >> # みなさん回答しやすいです
> >> >>
> >> >>
> >> >> On Tue, 10 Jan 2012 14:22:30 +0900 (JST)
> >> >> <xrstt070 ＠ yahoo.co.jp> wrote:
> >> >>
> >> >> > 川原と申します。いつもお世話になっております。
> >> >> >
> >> >> > 10万件超のテーブル数をもつデータベースをpg_dumpコマンドにて
> >> >> > バックアップを行った際に、最初のLOCK処理で15分程時間がかかる
> >> >> > のですが、パラメータチューニングなどで早くすることはできないでしょうか？
> >> >> > また、pg_dump全体を早くするチューニング方法はないでしょうか？
> >> >> >
> >> >> > 獲得しているロック数の推移をpg_locksにて確認してみたのですが、
> >> >> > 最初の数秒間は2000件/秒で、最後のほうになると40件/秒と遅くなっています。
> >> >> >
> >> >> > ロック関係ということで、deadlock_timeoutを長くしたりしたのですが、
> >> >> > 改善されません。
> >> >> >
> >> >> > LOCK処理が早くなれば、pg_dumpの並列化を独自に行って
> >> >> > 早くなれればいいなと考えております。
> >> >> >
> >> >> > 以上、宜しくお願いします。
> >> >>
> >> >>
> >> >
> >> >
> >> 
> >> 
> >> -- 
> >> --
> >> NAGAYASU Satoshi <satoshi.nagayasu ＠ gmail.com>
> >> 
> 
> 
> -- 
> NAGAYASU Satoshi <satoshi.nagayasu ＠ gmail.com>
>