[pgsql-jp: 38844] Re: pg_dump で時間がかかる
公手真之
kude ＠ itboost.co.jp
2007年 10月 9日 (火) 22:24:42 JST
藤澤様
公手です。
返事が遅くなり大変申し訳ありませんでした。
> > pg_dump -h localhost -U hoge -b -Fc hogedb > ファイル名
> と、リダイレクトされていますが、ここの「ファイル名」で指定する
> のは、ダンプのファイル名でしょうか？
その通りです。ダンプファイル名です。
-d スイッチの有無で時間を計ってみました。
170MBの小さなデータベース（ラージオブジェクトなし）ですが…
以下のような結果がでました。
※大きなサイズで試してみてください〜。
$ time pg_dump -b -Fc -d hogedb > /tmp/dumpA
real 0m6.702s
user 0m3.386s
sys 0m0.131s
$ time pg_dump -b -Fc hogedb > /tmp/dumpB
real 0m2.783s
user 0m1.117s
sys 0m0.093s
-d スイッチのないほうがかなり早いですね。
取得したダンプファイルのサイズも違いますね。
-d スイッチがない方がファイルサイズも小さいですね。
# ls -lak /tmp/dump*
-rw-rw-r-- 1 postgres postgres 992 10月 9 22:34 /tmp/dumpA
-rw-rw-r-- 1 postgres postgres 933 10月 9 22:34 /tmp/dumpB
On Tue, 9 Oct 2007 09:35:05 +0900 (JST)
藤澤 <qsecofr1 ＠ hotmail.com> wrote
> 公手様
>
> ご指摘、ありがとうございます。藤澤です。
>
>
> 「-d」のスイッチ、データベース名指定だと思っていました。
> 今、書籍で確認したところ、確かに、
> -d, --inserts データを(COPY文ではなく)INSERT文としてダンプ
> とありました。
> -d 指定をやめて、試してみます。
>
> あと、
> > pg_dump -h localhost -U hoge -b -Fc hogedb > ファイル名
> と、リダイレクトされていますが、ここの「ファイル名」で指定する
> のは、ダンプのファイル名でしょうか？
> pg_dumpall とは異なり、何も出力されなかったかと。。
>
>
> ／藤澤
>
>
>
> On Tue, 9 Oct 2007 09:18:00 +0900 (JST)
> 公手真之 <kude ＠ itboost.co.jp> wrote:
>
> > 藤沢様
> >
> > 公手ともうします
> >
> > > pg_dump -h localhost -d hogedb -U hoge -F c -c -v -f .\dump\hoge_dump.car
> >
> > -d オプションをやめてみたらどうなりますでしょうか？
> > -d オプションは確かダンプファイルをcopyでなくinsert形式で吐き出します。
> > pg_dumpの処理時間は短縮されないかもしれないですが、
> > -d オプションをつけてダンプしたファイルをrestoreするとめちゃくちゃ時間
> > がかかります。
> > ※以前 -d オプションはデータベースの指定オプションと勘違いしていました。
> >
> > pg_dump -h localhost -U hoge -b -Fc hogedb > ファイル名
> >
> > みたいな感じでどうですか？
> >
> > On Fri, 5 Oct 2007 22:32:41 +0900 (JST)
> > 藤澤 <qsecofr1 ＠ hotmail.com> wrote
> >
> > > 藤澤です。
> > >
> > >
> > > Windows の PostgreSQL 8.2.4 で pg_dump でバックアップを取ろうと
> > > していますが、時間がかかって泣きそうです。
> > >
> > >
> > > データベースのサイズを、
> > > select pg_database_size('hogedb');
> > > で確認すると 36.15 GB です。(起動時にVACUUMがかかった直後のサイズです。)
> > >
> > > このバックアップを
> > > pg_dump -h localhost -d hogedb -U hoge -F c -c -v -f .\dump\hoge_dump.car
> > > で取得しようとしたところ、9:30am にスタートして、22:00までかかって、
> > > 40GBまでダンプファイルのサイズが大きくなりました。
> > > ※事情により、途中で中断しました。
> > >
> > >
> > > 時間がどんどん経過して、焦ると同時に以下のような疑問が湧いています。
> > > --------------------------------------------------------------
> > > ★疑問１：pg_dump はこんなに時間がかかるのか？
> > >
> > > ★疑問２：ダンプファイルは、-F c (custam archive) を指定しているのに、
> > > データベースサイズより大きくなるのか？
> > > --------------------------------------------------------------
> > >
> > > 疑問１については、以下の情報を見ると、53GB のデータベースを pg_dump -F c
> > > で取得した時には、1時間20分ほどで終わっているようです。
> > > OSDL DBT-1 によるPostgreSQL8.1.4のバックアップ・リストア性能に関する考察
> > > http://ossipedia.ipa.go.jp/capacity/EV0612270347/
> > > * Windows かどうかの記述はありませんでしたが。。。
> > >
> > >
> > >
> > > データの特徴として、
> > > あるテーブルに、bytea 型の列が２つあり、それぞれに画像
> > > データ(いずれも約400KB)が格納されていて、それが4万件あります。
> > > (400KB + 400KB) × 40,000 = 約32GB
> > > つまり、データベースのほとんどは、このテーブルが占めています。
> > >
> > > データベースのチューニングは全く行っておらず、postgreSQL.conf の内容は
> > > 初期値のままです。
> > >
> > > pg_dump を行っている間にもデータの更新を行っていました。
> > >
> > >
> > > その他の環境は以下です。
> > > ------------------------------------------
> > > Windows Server 2003
> > > PostgreSQL 8.2.4
> > > ディスク： 30GB * 6 を、RAID5 構成 (1.3 TB)
> > > メモリ ： 2GB
> > > ------------------------------------------
> > >
> > >
> > >
> > > また、後日チャレンジしてみますが、情報をお持ちの方が居られましたら、
> > > よろしくお願いします。
> > >
> > >
> > > ／藤澤
> > >
> > >
> >
>
>
>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━ ＡＳＰとＩＴ人材派遣で企業のＩＴ化を推進する
━ 株式会社アイティーブースト
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ソリューション事業部 マネージャー 公手真之 Masashi KUDE
〒534-0024 大阪市都島区東野田町2-9-7 K2ビル8階
TEL：06-4801-5657 FAX：06-4801-5658
E-mail：kude ＠ itboost.co.jp URL：http://www.itboost.co.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
メール共有・管理ツール「メールディーラー」
http://www.maildealer.jp/
-----------------------------------------------------------------------
低価格・中機能 メール配信ＡＳＰ「配配メール」
http://www.haihaimail.jp
-----------------------------------------------------------------------
フルマネージド専用サーバー「エクスユニット」
http://www.xunit.jp/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
pgsql-jp メーリングリストの案内