PostgreSQL 检查点日志解释

Question

我知道 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

1. 我知道 22.9% 的共享缓冲区被写入（我有 1024 MB，shared_buffers所以这意味着 234 MB 被写出）。
2. 我知道有 47 个 WAL 文件被回收，即崩溃恢复不再需要它们，因为来自它们的真实数据已经在磁盘上。

质疑。但是write=148.465 s和sync=34.339呢？有什么不同？什么是write，为什么它的时间远远超过fsync()操作？

问题B。什么是sync files？哪些文件：WAL 文件？为什么sync files是159个，而回收的文件只有47个？它们之间有什么关系？

谢谢！

Answer 1

对于你的问题A：“写入”和“同步”的意思正是他们所说的；它是从 Postgres 缓冲池中一系列缓冲（如文件系统 I/O 缓冲区）写入脏页的序列，然后fsync()（通常）确保文件系统缓冲区实际上已写入磁盘。写入会受到限制并在后台发生，因此可能需要更长的时间。

对于你的问题B：sync files告诉你有多少操作系统文件受到检查点的影响。由于每个表和索引都存储在自己的文件中，因此该数字可以让您了解有多少数据库对象受到检查点的影响。当 WAL 缓冲区被刷新时，即在检查点之前，WAL 被同步；这就是为什么它被称为“预写”。

Answer 2

写入和同步阶段意味着相当不同的事情（不幸的是）。在检查点的中间阶段，它从共享缓冲区中写出所有脏缓冲区。它以一种节流的方式执行此操作，主要由 checkpoint_completion_target 调节。此处报告的时间是写入这些缓冲区所花费的时间，以及为调节写入缓冲区的速率所花费的睡眠时间。所以并不是所有的“写作”时间都花在积极写作上。在写入阶段花费的时间长度，2.5 分钟，在不知道您的其他设置是什么的情况下并没有真正的意义。

在同步阶段，它同步所有刚刚写入的文件（以及其他进程可能写入的任何数据文件）。这个阶段是不受限制的，它会尽可能快地同步它们。这需要 34 秒，其中一个文件需要 16.143 秒，这表明您的 IO 硬件无法满足您投入的工作负载。

159个同步文件是指自上次检查点结束后被弄脏的数据文件数，因此需要在本次检查点结束前同步。47 指的是 WAL 文件，而不是数据文件。WAL 文件包含对数据文件所做更改的引用。47 个 WAL 文件很容易包含 159 个数据文件（或就此而言，15,900 个数据文件）的引用。但事情并没有那么简单，因为被回收的WAL文件都是之前两个checkpoint的文件，所以47和159的关系只是一个类比，不是具体的计数。