PostgreSQLチェックポイントログの説明
PostgreSQLチェックポイントとは何か、それがいつ発生するかを知っています。
_log_checkpoints = on_パラメータによって生成されたログに関する追加情報が必要です。その点をいくつか説明してください。
2017-09-09 16:31:37 EEST [6428-6524] LOG: checkpoint complete: wrote 30057 buffers (22.9%); 0 transaction log file(s) added, 0 removed, 47 recycled; write=148.465 s, sync=34.339 s, total=182.814 s; sync files=159, longest=16.143 s, average=0.215 s
- 共有バッファーの22.9％が書き込まれていることを知っています（1024 MBの_
shared_buffers_があるため、234 MBが書き込まれます）。 - 47個のWALファイルがリサイクルされていることを知っています。つまり、それらのファイルからの実際のデータはすでにディスク上にあるので、クラッシュリカバリには必要ありません。
質問A。しかし、_write=148.465 s_および_sync=34.339_はどうでしょうか。違いはなんですか？ writeとは何ですか、またその時間がfsync()オペレーションよりはるかに長いのはなぜですか？
質問B。 _sync files_とは何ですか？どのファイル：WALファイル？ _sync files_が159であるのに、47のリサイクルファイルしかないのはなぜですか？これらの関係は何ですか？
ありがとうございました！
あなたの質問A：「書き込み」と「同期」は、彼らが言うことを正確に意味します。これは、Postgresバッファプールからのダーティページの（ファイルシステムI/Oバッファのように）バッファリングされた一連の書き込みで、その後にfsync()（通常）が続き、ファイルシステムバッファが実際にディスクに書き込まれるようにします。書き込みは抑制され、バックグラウンドで行われるため、書き込みに時間がかかる場合があります。
あなたの質問Bへ：sync filesは、チェックポイントの影響を受けたOSファイルの数を示します。各テーブルとインデックスは独自のファイルに格納されるため、この数から、チェックポイントの影響を受けたデータベースオブジェクトの数がわかります。 WALは、WALバッファーがフラッシュされるとき、つまりチェックポイントの前に同期されます。それが「先読み」と呼ばれる理由です。
書き込みと同期のフェーズは、（残念ながら）かなり異なることを意味します。チェックポイントの中間フェーズでは、共有バッファからすべてのダーティバッファを書き出します。これは、主にcheckpoint_completion_targetによって規制される、調整された方法で行われます。ここで報告される時間は、それらのバッファーの書き込みに費やした時間と、バッファーが書き込まれるレートを調整するためにスリープに費やした時間です。したがって、「書き込み」時間のすべてが積極的に書くことに費やされたわけではありません。書き込みフェーズに費やされた時間2.5分は、他の設定が何であるかを知らなければ意味がありません。
同期フェーズでは、書き込んだばかりのファイル（および他のプロセスが書き込んだ可能性のあるデータファイル）をすべて同期します。このステージは調整されておらず、できるだけ速く同期されます。これに34秒かかり、1つのファイルが16.143秒かかったということは、IOハードウェアがスローしているワークロードに対応していないことを示しています。
159個の同期ファイルとは、最後のチェックポイントの終了以降にダーティ化されていたため、このチェックポイントが終了する前に同期する必要があったデータファイルの数を指します。 47はデータファイルではなくWALファイルを参照します。 WALファイルには、データファイルに加えられた変更への参照が含まれています。 47のWALファイルに159のデータファイル（または、15,900のデータファイル）への参照を含めるのは非常に簡単です。ただし、リサイクルされるWALファイルは2つのチェックポイント前のファイルであるため、47と159の関係は類推であり、具体的な数ではありません。