web-dev-qa-db-ja.com

並列pg_restoreコマンドが非並列の同等のものを完了するのに何時間もかかるのはなぜですか？

Pg_restoreを使用して、4つのジョブを使用する次のコマンドを使用して、ディレクトリバックアップから50 GBのデータベースを復元しました。

pg_restore -d analytics -U postgres  -j 4 -v "D:\Program Files\PostgreSQL\10\backups\Analytics_08_2018__7_53_21.36.compressed"

これはコマンドラインから実行しました。復元にかか​​った 2時間長い 非並列復元よりも。復元ジョブの最後にインデックスを作成するとハングするように見えた

pg_restore: launching item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: creating INDEX "public.nidx_bigrams_inc_hits"
pg_restore: finished item 2965 TABLE DATA trigrams
pg_restore: launching item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: creating INDEX "public.nidx_trigrams_inc_hits"
pg_restore: finished item 2823 INDEX nidx_unigrams_inc_hits
pg_restore: finished item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: finished item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: finished main parallel loop

これらのpg_restoreの「インデックスの作成」ジョブのそれぞれは、pg_stat_activityで「アイドル」のステータスを持っていました。別のpg_restoreジョブはコミット時に「アイドル」でした。

並列復元がデフォルトの復元よりもはるかに速く完了することを期待していましたが、約15分後に停止するまで、それが実行されているように見えました。このサーバーでは他に何も起こっていません。ジョブが完了する前にインデックスを確認したところ、インデックスは完全に見えました。つまり、インデックスは元のデータベースインデックスと同じサイズでした。非並列復元とは対照的に、並列復元ジョブのファイナライズ/コミットに時間がかかる特別な理由はありますか？災害復旧の状況ではその準備をしておき、ジョブの継続時間に頼ることができない場合は並行して除外したいと思います。

ちなみに、論理ではなくファイルシステムベースのバックアップを認識していますが、とりあえず論理にのみ関心があります。

postgresqlpostgresql-10parallelismpg-restore
1
mikelus

おそらくデータベースの競合だけです。

並列dumpを実行すると、postgresは一度に多くの異なるファイルに書き込むことができるため、負荷を分散させることができます。

並列処理restoreを実行すると、postgresは、jobs + 1接続から着信するすべての[重い]トラフィックを管理し、すべてがバッファキャッシュのデータページを一杯にしてディスクに書き込む必要があります。 。インデックスを作成するには、データページを読み込んでスキャンする必要があります。一度に多くのテーブルに対してこれを行うと、バッファキャッシュに多くのプレッシャーがかかります... more postgresで動作します。

また、指定したfourジョブ-データベース[サーバー]には、それをサポートするのに十分なCPU /コアがありますか？そうでない場合、余分なジョブはスピンアップされますが、[オペレーティングシステムレベルで競合します。これらのジョブは、[貧しい]マシンがすべてを実行しようとするときにメモリ不足に切り替えられるためです。」同時に"。小規模なサーバーでは、2つのジョブを実行することでメリットが得られる場合がありますが、それよりも多くのメリットがコストを上回ります。

2
Phill W.

これが発生するもう1つの理由は、pg_restoreでは、パスワードを複数回入力する必要があります（プロセスごとに1回）。たとえば、これがコマンドの場合：

pg_restore --jobs=8 --clean -d example -C --no-owner --no-acl -U example -h 127.0.0.1 -W db.dump 
Password: 
Password: 
Password: Password: Password: Password: Password: Password: Password: Password:

最後の行では、パスワードを入力し、続いてリターンキーを8回、または合計で10回入力する必要があります。

0
zachaysan