随着数据库从概念验证扩展到成熟的生产实例,数据库管理员和系统管理员总是会遇到各种各样的成长难题。
通常,Crunchy Data Support团队的工程师帮助支持企业项目,这些项目从小型概念验证系统开始,然后推广到大规模生产用途。当这些系统收到超出其原始概念验证大小的流量负载时,Postgres日志中可能会发现一个问题,如下所示:
日志:检查点出现的频率太高(间隔9秒)提示:请考虑增加配置参数";max_wal_size";.LOG:检查点出现的频率太高(间隔2秒)提示:考虑增加配置参数";max_wal_size";。
这是一个典型的数据库示例,该数据库没有针对高写入负载进行适当调整。在这篇文章中,我们将讨论这意味着什么,此错误的一些可能原因,以及一些相对简单的解决问题的方法。
首先,查看系统设置,并简要讨论此错误的含义。
Postgres日志提到了两个具体的东西,检查点和max_wal_size。调查Postgres实例以观察与这两个项目相关的任何设置,我们看到以下内容:
[LOCAL]:5433 user@exampib=#SELECT NAME,SELECT NAME,SELECT NAME FROM PG_SETTINGS WHERE NAME LIKE';%WAL_SIZE%';或NAME LIKE';%CHECKPOIN%';名称|设置-CHECKPOINT_COMPLETION_TARGET|0.9 CHECKPOINT_FLUSH_AFTER|32 CHECKPOINT_TIMEOUT|300 CHECKPOINT_WARNING|30 LOG_CHECKPOINTS|OFF MAX_WAL_SIZE|1024 MIN_WAL_SIZE|80(7行)。
MAX_WAL_SIZE设置要在自动检查点之间增长的最大预写日志记录(WAL)数量。这是一个软限制;在特殊情况下,WAL大小可能会超过max_wal_size,例如负载较重、ARCHIVE_COMMAND失败或WAL_KEEP_SEGMENTS设置过高。
还需要注意的是,增加此参数可能会增加崩溃恢复所需的时间。*默认值为1 GB(1024 MB)。
正如在前面的文章中所讨论的,PostgreSQL的默认配置值通常是保守的,因此在大型服务器上的工作效果与在资源受限的小型开发机器上的工作效果一样好。因此,对于生成我们已经看到的错误消息的系统而言,此处观察到的max_wal_size的默认值可能太低。
接下来,让我们看看为什么max_wal_size的这个较低值可能与问题的原因相关。
显然,此问题的确切原因会因情况而异,但一般来说,当max_wal_size较低,并且数据库有大量快速更新或插入时,它生成WAL的速度往往会快于存档速度,也快于标准检查点进程所能跟上的速度。
因此,如果您在Postgres实例上监控磁盘使用情况(您应该这样做!)。您可能还会注意到,保留这些WAL文件后,pg_wal目录的大小会急剧增加。
Max_wal_size有一个Partner参数,与之相反的是min_wal_size。MIN_WAL_SIZE的参数定义收缩WAL的最小大小。只要WAL磁盘使用率在存档时保持在此设置以下,旧的WAL文件始终会在检查点回收以供将来使用,而不是删除。这对于确保预留足够的WAL空间来处理WAL使用量峰值非常有用,例如在运行大型批处理作业时。此默认值为80 MB。
PostgreSQL在日志文件中很有帮助地告诉我们应该做什么:增加max_wal_size。
因此,如建议的那样,编辑实例配置文件以增加max_wal_size值以匹配系统的工作负载。
对于大多数用例,理想值是增加max_wal_size的值,以便它可以保存至少一个小时的日志。但是,这里需要注意的是,您不希望将此值设置得非常高,因为这可能会增加故障恢复所需的时间。如果需要,还可以增加MIN_WAL_SIZE,以便系统可以在批处理作业和其他异常情况下处理WAL使用量峰值。在进行适当的配置更改并重新加载Postgres之后,我们可以验证是否应用了新设置,正如我们预期的那样:
名称|设置-CHECKPOINT_COMPLETION_TARGET|0.9CHECKPOINT_FLUSH_AFTER|32 CHECKPOINT_TIMEOUT|300CHECKPOINT_WARNING|30 LOG_CHECKPOINTS|OFF MAX_WAL_SIZE|16384 MIN_WAL_SIZE|4096(7行)。
有了这些新设置,并仔细监视日志文件和系统使用情况,将这样的系统从开发设备向上扩展到成熟的生产实例所带来的不断增长的痛苦将成为遥不可及的记忆。
有关配置PostgreSQL设置的更多信息和一些互动研讨会,请访问Crunchy Postgres开发人员门户。