衡量PostgreSQL检查点统计信息

检查点可能是高并发写操作的PostgreSQL主要影响因素。识别这个领域中问题的第一步是监视它们发生的频率，这使得最近在数据库中添加了一个更易于使用的界面。

检查点是数据库执行的定期维护操作，以确保它在内存中缓存的所有内容都与磁盘同步。这样做的目的是，一旦完成了一个，就不必担心数据库的预写日志中会有更旧的条目。这意味着更短的恢复时间。

检查点的问题是它们可能非常密集，因为要完成一个检查点需要将数据库缓冲区缓存中更改的数据都写入磁盘。postgresql8.3中添加了许多特性，这些特性允许您更好地监视检查点开销，并通过将活动分散到较长的时间段来降低检查点开销。我写了一篇关于这些变化的文章，叫做检查点和背景，详细介绍了发生了什么变化，但是读起来很枯燥。

 您可能想知道的是如何监视生产系统上的检查点，以及如何判断它们是否经常发生。即使情况有所改善，即使在当前的PostgreSQL版本中，磁盘I/O变得非常繁重的“检查点峰值”仍然是可能的。而且，将默认配置调整为非常低的磁盘空间和快速的崩溃恢复而不是性能，这并没有帮助。checkpoint_segments参数是检查点发生频率的一个输入，默认值为3，它只在48MB的写入之后强制执行检查点。   

您可以通过两种方式找到检查点频率。您可以打开日志检查点并查看日志中发生的情况。您还可以使用pg_stat_bgwriter视图，该视图提供检查点的两个源（时间传递和写入发生）的计数，以及它们所做工作的统计信息。 

使之更容易实现的主要问题是，直到最近，还不可能重置pg_stat_bgwriter内部的计数器。这意味着您必须拍摄一个带有时间戳的快照，稍等片刻，再拍摄另一个快照，然后减去所有值以从数据中获取任何有用的统计信息。真是一种痛苦。太痛苦了，我写了一个补丁让它更简单。在数据库的当前开发版本中，现在可以调用pg_stat_reset_shared（'bgwriter'）并再次将这些值返回0。这就允许遵循PostgreSQL上常见的做法。在8.3之前，有一个名为stats_reset_start的参数可以打开。每次重启服务器的内部统计信息。这意味着您可以调用pg_postmaster_start_time（）函数，与当前时间进行比较，并始终以系统上任何可用统计信息的操作/秒为单位进行精确计数。

它仍然不是自动的，但现在重置这些共享的部分是可能的，你可以自己做。第一个关键是将统计信息清除集成到服务器启动序列中。这样的脚本可以工作：

pg_ctl start -l $PGLOG -w
psql -c "select pg_stat_reset();"
psql -c "select pg_stat_reset_shared('bgwriter');"

注意start命令中的“-w”-这将使pg_ctl等到服务器完成启动后才返回，如果您想立即对其执行语句，这一点至关重要。如果您已经这样做了，并且您的服务器启动时间基本上与后台writer stats开始收集时相同，那么现在可以使用以下有趣的查询：

SELECT
total_checkpoints,
seconds_since_start  total_checkpoints  60 AS minutes_between_checkpoints
FROM
(SELECT
EXTRACT(EPOCH FROM (now() - pg_postmaster_start_time())) AS seconds_since_start,
(checkpoints_timed+checkpoints_req) AS total_checkpoints
FROM pg_stat_bgwriter
) AS sub;

并得到一个关于检查点在您的系统上发生的确切频率的简单报告。输出如下：

total_checkpoints           | 9
minutes_between_checkpoints | 3.82999310740741

你对这些信息所做的就是盯着平均时间间隔，看看它是否太快了。通常，您希望检查点不超过每五分钟发生一次，而在一个繁忙的系统中，您可能需要将它推到10分钟或更长时间才能跟上。在这个例子中，每3.8分钟可能太快了——这是一个需要更高检查点分段的系统。使用此技术来测量检查点间隔，可以让您知道是否需要增加检查点段和检查点超时参数来达到该目标。你现在可以手动计算这些数字，一旦9.0发布，你可以考虑让它完全自动化——只要你不介意每次服务器重启时你的统计数据都会消失。在pg_stat_bgwriter中，还有一些其他有趣的方法来分析后台writer为您提供的数据，但是今天我不会放弃我所有的技巧。

请点击文章底部“阅读原文”查看原文内容！