资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/Oracle2PG系列之检查点引起的故障案例

Oracle2PG系列之检查点引起的故障案例

IT那活儿 / 1867人阅读
Oracle2PG系列之检查点引起的故障案例
点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！ 

1

最近碰到个案例,某Oracle数据库迁移到PG的过程中,压测发现一波巨量IO将PG库给冲hang住了,一通检查发现是PG全量检查点捣的鬼,今天我们一起来总结一下。

2

先普及一下基础知识，一般数据库的最小存储单元都是数据块(block/page),当客户端修改数据时意味着,数据库引擎需要将对应的物理数据块读到数据库的buffer cache中进行修改,此时这个数据块与物理文件中的数据块将不在一致，称为脏块。
由于脏块分布随机,持久化到存储的成本巨大,让客户端等待这个脏块完成持久化完成无疑TPS会非常差。
为了改进这个问题各大数据库厂商普遍采用预写式(write ahead log,也有取名redo,都是一个意思)来记录这些脏块的修改动作(record),将这些record持续性顺序的持久化到磁盘,脏块将在后续异步持久化到存储中。
传统HDD顺序IO的性能优于随机IO几十倍，这即保证了数据修改不会丢失，性能也得到得了巨大提升。
参考oracle文档图：
需要注意：当脏块持久化不及时，buffer cache中堆积了巨量脏块时，如果发生宕机,数据库再次启动时为了维持一致性，需要调用wal的record来恢复这些脏块。这就需要数据库判断哪些是脏块,通常数据库厂商采用检查点(checkpoint)点来进行标记。
Buffer cache中的脏块持久化到数据文件中后，将标记上checkpoint position,并与wal record进行关联，position之前的wal将不再需要,position之后的wal record用来对脏块进行一致性恢复。
参考oracle文档图：
注意：在Oracle中,其采用SCN来记录Checkpoint position。
Oracle在古老的8i版本之前,采用一次性将buffer cache中的脏块全量持久化到数据文件中并更新checkpoint position，称为全量检查点(full checkpoint)。这种方法比较简单粗暴,产生的问题也很直观,当产生全量检查点时，巨量的脏块持久化IO会对数据库TPS产生剧烈影响，甚至于hang、宕机等、问题多多。
Oracle针对这个问题后续采用了增量检查点(Incremental checkpoint),在buffer cache中对脏块按顺序进行链表记录,增量检查点按链表持续推进position，数据库实例异常宕机时，仅需对最新position之后的脏块使用wal record进行一致性恢复，这会大大缩短恢复时间，且将全量检查点的巨量脏块持久化IO进行平滑拆分提高数据库稳定性,同时提供了Fast Mtrr等参数进一步帮助用户来控制一致性恢复时间。
以上我们就搞清了Oracle检查点相关的知识。

3

接下来就来探讨PG的检查点：
PG的文档中描述其在发生检查点时，需要将全量脏块刷新到磁盘中,且提到会引起IO过载的问题。注意PG目前的版本中还不支持增量检查点。
再来看一下模拟压测故障的案例：使用pgbench进行TPS压力测试,发现在开始checkpoint后, iostat中write开始剧烈上升,同时pgbench的TPS直线下降,数据库基本无响应。
如下：
pg checkpointlog：
注意：这里为了加大全量检查点的力度设置检查点周期为1分钟。
检查点期间iostat中磁盘写压力较大，IO响应出现延迟。
同时pidstat观察到postgres walwrite进程的io在checkpoint发起后直线下降。由于事务wal日志落盘不及时大量的会话等待于WALWriteLock,数据库hang。
以上就复现了生产压测时的故障现象。
针对于此,PG建议通过设置checkpoint_timeout与max_wal_size来控制检查点的周期,同时设置checkpoint_completion_target来控制检查点周期间,刷脏的负荷。
具体如下：

根据如上优化后,生产环境经过多轮压测调整，TPS稳定运行24小时，基本达到理想效果。

4

最后我们总结一下, Oracle中有详细的lgwr日志、ckpt日志、dbwr日志等等便于我们排查问题，而PG的日志信息较少，排查问题相对困难，这方面还有待改进,本文就到此为止。

 



END



  



本文作者：胡 杰

本文来源：IT那活儿（上海新炬王翦团队）

GPU云服务器 云服务器 系列之 系列之二 架构之坑系列 人工智能引起的

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129530.html

相关文章

  • 无人值守时代，运维如何保障发布质量？

    摘要：导读阿里巴巴千亿交易背后，如何尽量避免发布故障在面对实际运维过程中遇到的问题该如何解决近日，在大会上，阿里巴巴运维技术专家少荃，给我们带来了解决方案和思路。在阿里，这些屏幕包括监控发布单机器故障预警等。 导读：阿里巴巴千亿交易背后，如何尽量避免发布故障？在面对实际运维过程中遇到的问题该如何解决？近日，在GOPS大会上，阿里巴巴运维技术专家少荃，给我们带来了解决方案和思路。 showIm...

    Yu_Huang 评论0 收藏0

  • 无人值守时代，运维如何保障发布质量？

    摘要：摘要阿里巴巴千亿交易背后，如何尽量避免发布故障在面对实际运维过程中遇到的问题该如何解决阿里巴巴运维技术专家少荃，给我们带来了解决方案和思路。在阿里，这些屏幕包括监控发布单机器故障预警等。无人值守发布无人值守发布主要是把上述过程自动化智能化。 摘要： 阿里巴巴千亿交易背后，如何尽量避免发布故障？在面对实际运维过程中遇到的问题该如何解决？阿里巴巴运维技术专家少荃，给我们带来了解决方案和思路...

    LancerComet 评论0 收藏0

  • [译]GC专家系列3-GC调优

    摘要：原文链接本篇是专家系列的第三篇。但是，请记住调优是不得已时的选择。缩短耗时的单次执行与相比，耗时有较明显的增加。创建文件过程中，进程会中断，因此不要在正常运行时系统上做此操作。因此校验结果并根据具体的服务需要，决定是否要进行调优。 原文链接：http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collecti...

    leap_frog 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<