web-dev-qa-db-ja.com

postgresql pg_dumpのメモリ不足

pg_dumpのリソースの使用を何らかの形で制限することは可能ですか？

問題は、DBase全体が775GBであり、2つの非常に大きなテーブルがあることです。

pg_largeobjectテーブルは– 390GB

pg_largeobject statistics:
Index scans              778313505
Index tuples fetched    1079812292
Tuples inserted          201022148
Table size                  395 GB
Indexes size               6900 MB

Hive.lob_messages – 265GB。

Index scans             194377937
Index tuples fetched    183894199
Tuples inserted          16902844
Table size  8127 MB
Toast table size     272573947904
Indexes size              3090 MB

すべての場合において、私はこのpg_dumpコマンドを実行しています：

pg_dump -U postgres -d Hive -Fc -v -f /nfs/Hive_dump_10/Hive_full_20191016_1945.dmp 2> /nfs/Hive_dump_10/Hive_full_20191016_1945.log

すべてのデータをダンプするためにpg_dumpを実行しようとすると、「メモリ不足」によってkillされます。私のPostgre SQLサーバーには20GBのRAMがあり、pg_dumpを開始したとき、約30分後に強制終了しました。メモリ不足と言った。

20GBのRAMとpg_dumpを含むDBは、次の* .log行によって強制終了されます。

pg_dump: reading large objects

Kern.log：

Oct 15 09:00:18 Hive-psql kernel: [21504626.583951] Out of memory: Kill process 30663 (pg_dump) score 750 or sacrifice child
Oct 15 09:00:18 Hive-psql kernel: [21504626.584000] Killed process 30663 (pg_dump) total-vm:19151692kB, anon-rss:16873728kB, file-rss:0kB, shmem-rss:0kB

これは、私の3回が20GBのRAMでpgダンプを試したことを示すZABBIX監視ツールです。 enter image description here

したがって、問題に対処するために、すべてのリソース、+ 20 GBのRAM（合計で40GB）を追加しました。これは、次の* .log行によって3時間以内に終了します。

pg_dump: dumping contents of table "Hive.lob_messages"

そしてkern.logは言う：

Oct 16 23:19:01 Hive-psql kernel: [15614.408113] Out of memory: Kill process 2693 (pg_dump) score 840 or sacrifice child
Oct 16 23:19:01 Hive-psql kernel: [15614.408169] Killed process 2693 (pg_dump) total-vm:38363104kB, anon-rss:34020140kB, file-rss:24kB, shmem-rss:0kB

再びZABBIXウィンドウ、合計40GB： enter image description here

そのためのリソースはもうありません。だから私のオプションは何ですか？私のDBは毎日大きくなります、ありがとう。追加の20GBで十分で、60GBのRAMで十分だと思います。しかし、これは問題ない状況なのでしょうか。私のDBのサイズが約2TBなどになった場合の対処法...

他の質問、Hive.lob_messagesテーブルは大丈夫ですか？テーブルサイズとトーストテーブルサイズは異なります。

postgresqlbackupmemorypg-dump
1
Gumuliokas

グラフが示すのは、pg_dumpがおそらく19:45から始まり、20：00まで通常のメモリ消費が発生していることです。 20:00に、突然メモリが割り当てられ、おそらくメモリ不足状態が発生する23:15まで、ほとんど解放されないようです。

コメントから、カーネルは言う：

Hive-psql kernel: [15614.408169] Killed process 2693 (pg_dump) total-vm:38363104kB, anon-rss:34020140kB, file-rss:24kB, shmem-rss:0kB

約36GBのpg_dumpのanon-rssは、実際にpg_dumpが過剰に割り当てられていることを示しています。それほど多くのメモリを必要とするpg_dumpに問題があります。

データベースには確かに多くのラージオブジェクトがありますが、それらのいくつかは非常に大きくなる可能性があります（オブジェクトあたりの理論上の最大値は2TB）。

  • SELECT oid FROM pg_largeobject_metadata ORDER BY 1でカーソルを開き、1000エントリのチャンクで読み取ります。これは決して爆破してはなりません。

  • ラージオブジェクトごとに、lo_readでループして、内容を16384バイトのバッファーにフェッチします。

テーブル自体の重量が390 GBであるという事実は、pg_dumpが大量の割り当てを行う理由にはなりません。

しかし、pg_dumpが「ラージオブジェクトの取得」で初めて殺されたとき

Pg_dumpがこれを-vオプション付きで表示すると仮定すると（ところで、渡されたオプションについては言及しませんでした）、代わりに"reading large objects"が表示されます。

1
Daniel Vérité

Postgresのpg_dumpは、バックアッププロセスをスピードアップするためにメモリ割り当てチェックを犠牲にしました。メモリ不足の問題を考慮に入れるために、pg_dumpを書き直す必要があります。私がしたことは、pg_dumpに非BLOBフィールドをバックアップさせ、それからBLOBフィールドを個別にバックアップするプログラムを書きました。私も復元プログラムを書かなければなりませんでした。

0
cris