为什么在将 Amazon RDS for PostgreSQL 实例升级到版本 11 或更高版本后，写入延迟每五分钟会出现一次峰值？

解决方法

对于空闲的 Amazon RDS for PostgreSQL 实例，您可能会在 Amazon CloudWatch 指标写入延迟中看到每五分钟出现一次峰值。这与升级到 PostgreSQL 版本 11 或更高版本后，增强监控指标写入总量激增至大约 64MB 有关。升级后，wal_segment_size 参数的值变为 64MB。在版本 10 或更早版本中，这些峰值可能并不明显，这是因为 wal_segment_size 的值是 16MB。有关详细信息，请参阅 Amazon RDS - 文档历史记录中的 2018 年 9 月 7 日更新。

Amazon RDS for PostgreSQL 中的 archive_timeout 配置设置为 5 分钟。在这种设置下，存档进程每五分钟会复制要存档到 Amazon Simple Storage Service (Amazon S3) 的 Write-Ahead 日志记录 (WAL) 分段。当系统空闲时，此复制进程通常是唯一的 I/O 操作，因此在 CloudWatch 图表中可能看起来非常明显。但当系统繁忙时，可能就不会看到这种情况了。例如，假设您在某个 db.t3.small 实例上运行以下工作负载 30 分钟。此示例模拟了 RDS for PostgreSQL 实例上拥有 20GB Amazon Elastic Block Store (Amazon EBS) 卷的系统繁忙用例场景：

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

在这样的工作负载下，CloudWatch 写入延迟指标不会出现峰值。

但是假设您的用例是这样时：

• 有一个 I/O 请求需要 10 毫秒才能完成，还有另外九个 I/O 请求，每个请求需要 1 毫秒才能完成。这些请求的平均延迟计算方法如下：
  平均延迟 = (10 + (9\ * 1))/10 = 1.9 毫秒
• 有一个 I/O 请求需要 10 毫秒才能完成，没有其他 I/O 请求。这种情况下，平均延迟的计算方法如下：
  平均延迟 = 10/1 = 10 毫秒

上面这两个用例都包含一个需要 10 毫秒才能完成的 I/O 请求。但是，当计算平均延迟时，速度慢的请求会更显眼。这是因为第二个用例中与速度慢的请求一起运行的 I/O 请求较少。如果由于块大小过大，空闲系统有一个缓慢的 I/O 请求，则仅根据该请求计算延迟。在具有多个 I/O 请求的繁忙系统中，大多数请求块的大小较小，平均延迟会根据所有这些请求计算得出。

此类情况下，在空闲的 Amazon RDS for PostgreSQL 系统中，就可能会看到每五分钟出现一次写入延迟峰值。如果您的数据库实例运行繁忙的工作负载，则可能看不到这样的峰值。

**示例：**假设有两个 t2.small Amazon Elastic Compute Cloud (Amazon EC2) 实例，每个实例有 8 个 gp2 卷。

在 crontab 上运行以下命令。该命令在第一个 Amazon EC2 实例中每五分钟创建一个 64MB 大小的文件，块的大小为 64MB：

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

**注意：**请将命令中的 big_file.txt 替换为您的文件名。

还是在 crontab 上运行以下命令。该命令在第二个 Amazon EC2 实例中每分钟创建 100 个文件，每个文件的数据块大小为 8KB：

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

**注意：**请将命令中的 small_file.txt 替换为您的文件名。

您可能会注意到，第二个 EC2 实例在 CloudWatch 中显示的写入延迟峰值高于第一个 EC2 实例。

相关信息

使用 PostgreSQL 的最佳实践