TECH BLOG
技術ブログ

チェックポイント処理と checkpoint_completion_target

PostgreSQL では、チェックポイントと呼ばれる「メモリからディスクへの書き込み処理」があるのですが、これがシステムのボトルネックとなる可能性の高い処理となっています。
そのため、チェックポイント処理の負荷と処理時間を制御するために、checkpoint_completion_target というパラメータが用意されています。

checkpoint_completion_target を 1 に近づけると、チェックポイント処理の負荷が小さくなりますが、その分、チェックポイント処理の処理時間が長くなります。
checkpoint_completion_target を 0 に近づけると、チェックポイント処理の付加が大きくなりますが、その分、チェックポイント処理の処理時間が短くなります。

チェックポイント処理の負荷がシステムに影響しない様に、checkpoint_completion_target は 0.9 程度にするのがよい、というのが一般的です。

チェックポイントが発生する契機

チェックポイント処理が発生する契機は

• PostgreSQL がシャットダウンするとき
• CHECKPOINT コマンドが実行されたとき
• （前回のチェックポイント処理を起点として）max_wal_size 以上の WAL ファイルが発生しようとするとき
• 前回のチェックポイント処理から、checkpoint_timeout 秒が経過したとき

などがあります。

checkpoint_completion_target の影響範囲

ここで疑問なのですが、発生条件が違うチェックポイント処理に対して、checkpoint_completion_target が影響するのかどうか、ということです。
例えば、「前回のチェックポイント処理から、max_wal_size 以上の WAL ファイルが発生する」という、いわゆる「WAL 溢れ」を契機としたチェックポイント処理は、緊急的なチェックポイント処理となりますので、のんびりとチェックポイント処理を行っている場合ではありません。
そのため、WAL 溢れを契機としたチェックポイント処理では checkpoint_completion_target の影響がないのでは、という疑問が浮かびました。
疑問が浮かんだからには、早速検証して確認したいと思います。

検証結果

PostgreSQL 14.6 で、おおよそ 3 GB の WAL ファイルを発生させて、チェックポイント処理のディスク書き込み量を確認しました。
結果を下記に記載します。

縦軸がチェックポイント処理中のディスク書き込み量（バイト）となります。
横軸がチェックポイント処理が開始してからの経過時間（秒）となります。
凡例の「0.1」「0.5」「0.9」は、checkpoint_completion_target の値となります。

グラフの値が途中で切れているところは、そこでチェックポイント処理が完了したということになります。

CHECKPOINT コマンド実行を契機としたチェックポイント処理のディスク書き込み量

• CHECKPOINT コマンドを実行した場合については、checkpoint_completion_target の影響はなさそうです。

WAL 溢れを契機としたチェックポイント処理のディスク書き込み量

• checkpoint_completion_target の値によって、チェックポイント処理の実行時間が変動しています。
• ディスクの書き込み量については、0.1 の場合には多く発生しています。0.5 と 0.9 では特に変動は無いように見えます。
• 書き込みの総量は同じ（3 GB）なので、0.5 と 0.9 で変動がないのは理屈に合わないような気がしますが・・。

時間経過を契機としたチェックポイント処理のディスク書き込み量

• WAL 溢れを契機とした場合よりも、より顕著に checkpoint_completion_target の影響が出ていることが分かりました。
• checkpoint_completion_target が 0.1 と 0.9 で、チェックポイント処理の時間が 10 倍ほど違うことが分かります（パラメータの説明通りですね！）

契機ごとのチェックポイント処理のディスク書き込み量

checkpoint_completion_target = 0.9 で、CHECKPOINT コマンドを実行、WAL 溢れ、時間経過のそれぞれのディスク書き込み量も比較しました。

• WAL 溢れを契機としたチェックポイント処理では、ディスク書き込み量にスパイク（急激に増加する箇所）が発生するようです。
• 時間経過を契機としたチェックポイント処理は、その他のものよりディスク書き込み量の負荷は低く推移していることが分かります。

まとめ

最近ではサーバスペックの向上により、数十 GB 以上の shared_buffers を設定して運用することも珍しくありません。
shared_buffers が大きくなると、それだけダーティなデータも増えることなり、その結果、チェックポイント処理で書き出されるデータ量も増えることになります。
そのため、チェックポイント処理の負荷を制御する方法を理解しておくことは、PostgreSQL を安全に運用することにも繋がります。

次回以降のどこかで、shared_buffers とチェックポイント処理の負荷の関係性なども検証していきたいと思います。