谢予，目前在高校做助理研究员。个人兴趣在并行计算和数据挖掘。
朱君鹏，博士研究生。主要研究方向为数据库管理系统，尤其是内存数据库、事务处理系统、软硬件协同设计、日志系统。
随着数据库从概念验证扩展到成熟的生产实例，数据库管理员和系统管理员总是会遇到各种各样的问题。
通常，Crunchy Data团队的工程师会帮助支持一些企业项目，这些项目一开始是小型的概念验证系统，然后被推广到大规模的生产使用。当这些系统收到的流量负载增加到超过其最初的概念验证规模时，可能会在Postgres日志中观察到如下问题。
这是一个典型的例子，说明数据库没有针对高写入负载进行适当地调优。在这篇文章中，我们将讨论这意味着什么，一些可能导致这种错误的原因，以及一些相对简单的方法来解决这个问题。
系统设置
首先，看一下系统设置，简单讨论一下这个错误的含义。Postgres日志中提到了两个具体的东西，checkpoints和max_wal_size。查看Postgres实例是否有与这两个项目相关的设置，我们看到以下内容。
max_wal_size设置自动检查点之间要增长的预写式日志(WAL)的最大数量。这是一个软限制；在特殊情况下，预写式日志的大小可能会超过max_wal_size，例如大负载、archive_command失效或wal_keep_segments设置过高。
还需要注意的是，增加max_wal_size这个参数会增加崩溃恢复所需的时间。默认值是1GB（1024MB）。
正如在之前的文章中所讨论的那样，PostgreSQL的默认配置值通常是保守的，以便在大型服务器上与在小型、资源有限的开发机器上一样好用。正因为如此，max_wal_size的默认值很可能对产生以上错误信息的系统来说太低了。定义问题
接下来，我们来看看为什么max_wal_size的这个值设置过小可能是这个问题的原因。很明显，造成这个问题的具体原因会因情况不同而不同，但一般来说，当max_wal_size设置较小，而数据库有大量的更新或插入快速发生时，它将倾向于产生WAL的速度比它可以存档的速度更快，而且比标准检查点进程的同步速度更快。因此，如果你的Postgres实例上有磁盘使用监控（你应该这样做!），你可能也会观察到pg_wal目录的大小随着这些预写式日志文件的保留而急剧增加。max_wal_size有一个成对的参数--与之相对的min_wal_size。min_wal_size的参数定义了收缩预写式日志的最小尺寸。只要在归档时预写式日志的磁盘使用量低于这个设置，旧的预写式日志文件就会在一个检查点被回收供将来使用，而不是被删除。这对于确保预留足够的预写式日志空间来处理 预写式日志使用量的峰值非常有用，例如在运行大型批处理作业时。默认值为80 MB。如何解决
PostgreSQL在日志文件中的信息指导了我们具体应该怎么做：增加max_wal_size。按照建议，编辑实例配置文件，增加max_wal_size的值以匹配系统的工作负载。对于大多数实例来说，理想的是增加max_wal_size的值，使其至少可以容纳一个小时的日志。但是，这里需要注意的是，你可能不希望将这个值设置得过高，因为它会增加崩溃恢复所需的时间。如果需要的话，还可以增加min_wal_size，这样系统就可以在批处理作业和其他不寻常的情况下处理预写式日志使用量的峰值。在做了适当的配置更改，并重新加载Postgres后，我们可以验证新的设置是否如我们所期望的那样被应用。
有了这些新的设置，再加上对日志文件和系统使用情况的监控，将一个系统从开发设备升级到一个成熟的生产实例所带来的痛苦将成为遥远的记忆。请点击文章底部“阅读原文”查看原文！
PostgreSQL中文社区欢迎广大技术人员投稿
投稿邮箱：press@postgres.cn
