[pgsql-jp: 25750] Re: pg_dumpコマンドによるメモリ圧迫

Hiroki Takada takada @ rh.xdsl.ne.jp
2002年 4月 29日 (月) 15:24:07 JST


高田です.

こんにちは.

> そうですか。確かに以前は全く問題なっかったような気がします。もし処理能力に影
> 響を及ぼすとしたらホットバックアップの意味がないですよね。

以前とおっしゃられているのは,PostgreSQLのバージョンのことなのでしょうか.
何かシステムに変更がありましたか.例えば,PostgreSQLのバージョンを上げた
とか,扱うデータが大きくなってきたとか, OSをRedHat7.2に変更してファイル
システムがEXT3になったとかです.

> 
>  ◆OS情報
>   ・カーネルのバージョン ⇒ 2.4.7-10 on an i686
>   ※カーネルのアップグレード等は一切行っていません。
> 
>   ・ファイルテーブル数(file-max)の結果 ⇒ 8192
> 
>   ・freeコマンド実行結果
>                   total          used        free     shared    buffers
> cached
>    Mem:        255276     251244     4032     8440     10524  125136
>    -/+ buffers/cache:    115584   139692
>    Swap:       506008       54540    451468
>     ※常にスワップを使用している状態なので基本的にメモリは足りないとは
>        思います。
> 
> ◆PostgreSQL
>   ・バックアップ対象テーブル数  ⇒ 193
>   ・pg_dumpにより出力されたダンプファイル ⇒ 約22MB
>    ※pg_dumpコマンドはオプションなしで実行してます。
>       pg_dump データベース > ダンプファイル名
> 
>  ・pg_dump結果はDBクラスタと同じHDDに出力。
>  ・ネットワーク経由でpg_dumpを実行(TeraTerm上にて実施)
>  ・他にDBに接続しているものがない場合でも状況は同じです。
>  (接続数には関係ないと思われます。)
>

直感的にはメモリ不足とHDDのボトルネックが原因のように見えます.もし定
量的な裏づけが必要であれば,HDDのボトルネックについては以下の方法によ
りある程度確認することができます.

同じ構成(ハードウェア,OS,PostgreSQL)の試験用マシン(データが壊れても
よいマシン)にて,

1. 試験用ファイル作成
ddなどで適当に大きなサイズの試験用ファイルを作成します.

/bin/dd if=/dev/zero of=(試験用ファイルへのパス) bs=1024k count=1000

※ここでは1GBのファイルを作成しています.


2. 限界性能の測定
Xserverなど,できるだけ不要なプロセスは停止した状態で試験用ファイルを
読み書きし限界性能を確認します.

/bin/dd if=(試験用ファイルへのパス) of=(別の試験用ファイルへのパス) \
bs=50k count=20000 2> /dev/null & ; /usr/bin/vmstat -n 1

※(試験用ファイルサイズ)X2以上の空き容量があるパーティションで実行し
  てください.
※if=XXXXとof=XXXXは同じHDDから読み書きを行うよう指定してください.
※kernelがキャッシュしますので(試験用ファイルサイズ)は物理メモリサイ
  ズより十分に大きくしてください.

結果は,
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 1  0  0      0  28952  34912 185332   0   0     7    16  113   327   5   0  94
 0  0  0      0  28952  34912 185332   0   0     0     0  102   292   1   0  99
.....

と出力され,io/bi(ブロックデバイスからの入力ブロック数/読み込み),
io/bo(ブロックデバイスへの出力ブロック数)となります.

キャッシュの影響を排除するには平均値を用いると良いでしょう.


3. pg_dump時のHDDアクセス状況
件のpg_dumpを実行している状態で,

/usr/bin/vmstat -n 1

を実行します.io/bi,io/boが2の測定値に達していればHDDのボトルネッ
クである疑いが濃厚になります.

HDDボトルネックの対策は,

・十分に速いSCSIバス上のHDDであれば別のHDDを追加して,pg_dumpの出
  力はそちらに書き込むようにする.
・NICが十分に速い(マザーボードのchipset,NIC chip,Ethernetのメデ
  ィアタイプに依存します)のであれば,別のマシンでpg_dumpを実行する

などの方法が考えられます.

#個人的にはバックアップの時ぐらいはバックエンドを停止したいという
#のが本音ですが 

-- 
 ----------------------------------------------------
|   高田 浩生 (Hiroki Takada/takada @ rh.xdsl.ne.jp)   |
|                                                    |
|   My public key is available at the public key     |
|   servers. The message was signed as iso-2022-jp   |
|   char-set document in no PGP/MINE (RFC 2015)      |
|   format.                                          |
 ----------------------------------------------------





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