web-dev-qa-db-ja.com

大規模な管理作業（min_walおよびmax_wal）に最適なPostgresql 9.6

世界から切り離されたサーバーがあります。 48 GBのメモリと500 GBのSSDハードディスク、16コアCPUを備えたハイエンドシステムです。 pg_restoreは、テーブルが10個未満の単純なデータベースダンプで、バイナリデータやBLOBはなく、単純なテキスト（コメントシステム）のみです。ただし、1つのテーブルには約200 GBのデータがあるため、サイズは大きくなります。

このDBには他のジョブはありません。このメンテナンスタスクのみ。上記の構成でこの目的に最適な設定は何ですか？ PGSQLのドキュメント はあまり役に立ちません。私の特定の質問は、壁の設定についてです。

このサーバー全体を使用してpg_restore、このサーバーにはPG以外は何もありません。どの設定を使用する必要がありますか？これは私たちが今持っているものです：

maintenance_work_mem = 1500MB 
fsync = off
synchronous_commit = off
wal_level = minimal
full_page_writes = off
wal_buffers = 64MB
#-----  checkpoint_segments = 512
#-----  max_wal_size = (3 * checkpoint_segments) * 16MB
#-- min_wal_size = 100MB    # 80MB is the default
max_wal_size = 24576MB   # based on 512 checkpoint_segments 
max_wal_senders = 0
wal_keep_segments = 0
archive_mode = off
autovacuum = off

Topを使用すると、メモリは問題ではないことに注意してください。 CPUコアが100程度に急上昇し、その後ディップします。これは集中的な書き込みプロセスなので、理にかなっています。 min_wal_sizeを設定する必要があります-現在はコメントされています。

postgresqlperformancepostgresql-9.6maintenancepostgresql-performance
5
Khom Nazid

ダンプの復元が機能するかどうかだけをテストする必要があると思います。つまり、安全でない構成変更を行うことができます。まず、設定から始めましょう。

これらは良い呼び出しです：

fsync = off
synchronous_commit = off
full_page_writes = off
wal_level = minimal
autovacuum = off

これらの3つは、レプリケーションを使用している場合にのみ重要であり、すでにwal_levelを最小に設定しているため、それを使用していないため、重要ではありません。

wal_keep_segments = 0
archive_mode = off
max_wal_senders = 0

RAMは何にも使用されませんが、これをさらに増やします。

maintenance_work_mem = 3GB

wal_buffersはデフォルトのままにしておきます。

wal_buffers = -1

そしてshared_buffersをバンプします（wall_buffersは自動的に計算されます）：

shared_buffers: 4GB

集中する必要があるのは、復元中にチェックポイントがないか、できる限り少なくすることです。チェックポイントは、max_wal_sizeおよびcheckpoint_timeoutによって制御されます。最初にcheckpoint_timeoutを20hのようなものにバンプして、復元中に時間指定チェックポイントが発生しないようにします。

checkpoint_timeout = 20h

次に、max_wal_sizeを、ディスク容量が許す限り高い値に設定できます。復元されたDBが200GBおよびディスクが500GBの場合、max_wal_sizeを100GBに設定しても安全です。Postgresは最大2つのwalsのチェックポイント（2xmax_wal_size）を格納できるためです。

max_wal_size = 100GB

min_wal_sizeはあなたのケースではそれほど重要ではありませんが、おそらく10GBに増やすことができます

min_wal_size = 10GB

pg_restoreを--jobs=NUMと一緒に使用することもお勧めします。NUMはおそらくCPUコアの数ですが、これはSSDの速度にも依存するため、このパラメーターで遊ぶことができます。

Postgresの設定の他に、可能であれば、SATAドライブ（7200RPMで結構です）とシンボリックリンクpg_walディレクトリをそのSATAディスクに追加することをお勧めします。これはPostgresがWALを保存するディレクトリであり、それらは追加で記述されているため、SATAはそれらに対して十分高速です。これにより、SSDの負荷が軽減されますが、max_wal_sizeをさらに増やすこともできます（SATAディスクのサイズによって異なります）。

4
Strahinja Kustudic

Strahinjaの回答に+1を与えましたが、コメントに収まりそうにないので、回答を追加します。

Strahinjaからのアドバイスで私が唯一の問題は、ハードウェアとOSによって最適なWALサイズが異なる可能性があることです。サイズをデフォルトのままにしておくと、ダンプを復元するためにサイズをブーストするよりもパフォーマンスが向上するというベンチマークを見てきました。それは驚きでしたが、時々起こります。それらをブーストする場合は、推奨される専用ドライブのサイズの3分の1以下の値にサイズを設定することをお勧めします。

この目的で自動バキュームを無効にしても問題ありませんが、データベースでデータベーススーパーユーザーとしてVACUUM ANALYZE;を実行するまで、復元が完了したと見なさないでください。これにより、最初にフォアグラウンドクエリに負担がかかるのではなく、ヒントビットが設定され、可視性マップと空き領域マップが効率的に構築されます。統計は適切な計画に役立ちます。

また、システムで運用作業を開始する前に、構成を正常な運用構成に戻し、データベースサービスを再起動してください。

1
kgrittn