benchmarksql加载大量数据出现报警checkpoints are occurring too frequently frequently

原因

检查点发生的太频繁,max_wal_size参数过小或者checkpoint_warning过大均会导致该报错
这两个值默认如下

postgres=# show max_wal_size ;
 max_wal_size 
--------------
 1GB
(1 row)

postgres=# show checkpoint_warning ;
 checkpoint_warning 
--------------------
 30s
(1 row)

尽量不要修改checkpoint_warning参数的大小,如果发现max_wal_size已经很大了仍然报错才会减小checkpoint_warning值,建议修改范围为30s~60s

解释

其中max_wal_size设置自动检查点之间要增长的预写式日志的最大数量,是一个软限制,在特殊情况下,预写式日志的大小可能会超过max_wal_size,如大负载、archive_command失效或者wal_keep_segments设置过高,增加max_wal_size这个参数会增加崩溃恢复所需的时间,PG默认的配置是保守的为了在大型服务器与在小型资源有限的开发机器上都好用。
当max_wal_size设置的较小而负载较高时,倾向于产生wal的速度比可以存档的速度更快,而且比标准检查点进程的同步速度更快,另一个参数min_wal_size定义了收缩预写式日志的最小尺寸,只要在归档时预写式日志的磁盘使用量低于这个设置,旧的预写日志就会在一个检查点被回收供将来使用,而不是被删除,对于确保预留足够的预写式日志空间来处理预写式日志使用量的峰值非常有用。
对于大多数普通负载的实例,增加max_wal_size的值使得能够容纳一小时的日志,但是因为太高的话会增加崩溃恢复所需的时间,可以设置成16GB,min_wal_size设置成2GB,这样系统可以在批处理作业和其他不寻常的情况下处理预写式日志使用量的峰值

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值