文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

从一道PG知识的选择题谈起,你悟到了些什么?

2024-11-30 03:43

关注

稍微懂点PG数据库的人不难回答,答案是A、B、C。一些Oracle DBA可能会觉得这个答案有点出乎意料。因为在Oracle数据库中,回写DB CACHE脏数据的只有DBWR。可能这些人不太清楚的CKPT负责回写部分脏数据是80年代早期关系型数据库的共同特点,Oracle数据库中,CKPT也曾经负责过写脏块。后来随着数据库规模的增大,CKPT的功能被独立出来了,只负责CKPT的推进工作,不再负责写脏块了。在Oracle数据库中,为了更快的将脏块回写,通过将DB CACHE分区,采用多个DBWR进程可以并发写脏块,从而满足大型数据库的需要。

PG在刷脏块的算法方面的设计比较传统,这种设计是从90年代一脉相承的,改起来成本较大,所以就一直沿用下来了。只不过让backend也去写脏块,这未免也有点太出乎一般人的想象了。这会产生几个比较奇怪的现象,一个是某条SQL语句,可能在执行计划相同、数据量相同的情况下,不同的时间执行,其执行效率有较大的不同。另外一个奇怪现象是某条SELECT语句可能会产生较多的写操作。实际上Oracle数据库中也会存在类似的现象,这种情况是由延迟块清理产生的。当一个大型事务结束后,ITL的状态清理可能并没有完成,如果马上有SELECT操作访问这些数据,那么执行SELECT的前台进程将负责完成这些块的清理,这时候select操作也会产生大量的写操作,产生大量的REDO,同时这条SELECT比起平时会慢很多。    

图片

通过pg_stat_bgwriter系统表中的buffers_backend和buffers_backend_fsync可以查询到系统中的backend写脏块和fsync的计数。

图片

从我们的一个D-SMART的PG数据库中看到一个十分神奇的情况,按理说被用来写脏块的bgwriter居然很小(buffers_clean),大多数脏块都是checkpointer和backend写的 。如果你去检查一下你们的PG数据库,可能bgwriter写脏块的比例也不是很高。

为什么会出现这种情况,为什么大量的写脏块工作不由本应该处理脏块的 bgwriter去做,而让Backend去写脏块呢?这方面的资料很少,我们只能从 PG的代码上去找找答案。首先我们看一下src/backend/storage/bufmgr.c,在这里可以看到backend从shared buffers中分配空闲buffer的算法。一般我们都能理解从shared buffers中查找空闲的buffer,如果找不到非脏的空闲块,那么就有可能找到一个存储了脏数据的数据块,这时候才需要backend去写脏块。在Oracle数据库中,前台进程是顺着lru链的冷端去查找空闲缓冲块的,如果前台进程发现了某个没有被Pin住的块是脏块,就会把这个数据块移到lru-w中,然后继续往下搜索,如果连续搜素到了N个脏块,无法获得所需要的空闲块的时候,就会发出一个free buffer requests的事件,让DBWR加快刷脏块,然后再去重试。从PG的代码上看,PG的大体思想类似,不过策略要复杂得多。    

图片

BufferAlloc里包含了backend查找某个buffer的顶层逻辑。不阅读一下还真没发现PG这方面的代码逻辑会搞得如此复杂。要想访问某个buffer,先要生成一个BUFFER TAG(关于这方面的详细算法请参考我2021年写过的一篇8000多字的长篇《PG SHARED BUFFER POOL的优化》)。然后查找这个BUFFER。    

图片

如果BUFFER存在,还有两种可能性,一种是成功的PIN住了这个BUFFER,那么就可以返回这个BUFFER了。不过BUFFER存在还有一种可能性是无法PIN住,无法PIN住的原因是可能被其他的会话PIN住了,也可能是一些其他的原因。这种情况,Oracle被称为read by other session或者buffer busy waits。这个部分不是我们今天分析的重点,我们继续往下看代码。    

图片

GetVictimBuffer函数通过时钟扫描算法去找一个空闲的buffer。这里就涉及到查找空闲shared buffers了。我们下钻到这个函数的代码中去继续分析。

图片

首先调用StrategyGetBuffer去找一个BUFFER。    

图片

如果发现找到的是一个脏块,那么就把脏块刷盘,这就是BACKEND也需要刷脏块的原因之一。作为数据库缓冲的算法,我们肯定应该尽可能的找到非脏块来复用,总是让BACKEND写脏块肯定会降低数据库的整体性能。    

StrategyGetBuffer函数在src/backend/buffer/freelist.c中定义。首先,它会检查是否有一个策略对象(strategy),如果有,就调用GetBufferFromRing函数,从策略对象的环形缓冲区(ring buffer)中获取一个缓冲区。如果获取成功,就返回这个缓冲区,并设置from_ring标志为true。如果没能正常找到free buffer,它会尝试唤醒bgwriter,让它刷新脏的缓冲区到磁盘,以便释放一些空间。接下来,backend会检查StrategyControl->firstFreeBuffer变量,如果大于等于0,就表示有空闲的缓冲区,那么就通过一个循环从空闲链表中获取一个缓冲区。这部分算法与Oracle的free buffer requests十分类似。

此时如果空闲链表为空,backend会进入另一个循环,尝试从victim pool中选择一个缓冲区,victim pool是一个循环队列,存储了最近被访问过的缓冲区的编号。从nextVictimBuffer的当前位置开始,顺时针扫描victim pool,寻找一个既不被锁定,也没有被引用,也不是脏的缓冲区。如果找到了,就返回这个缓冲区,并将其从victim pool中移除。如果没有找到合适的缓冲区,它会继续扫描victim pool,寻找一个既不被锁定,也没有被引用,但是是脏块的缓冲区。如果找到了,就将这个缓冲区的内容写入磁盘,然后返回这个缓冲区(这是代码中backend中另外一个写脏块的地方),并将其从victim pool中移除,并添加到策略对象的环形缓冲区中。

我们先不去吐槽PG在这块代码的质量问题,仅仅从算法来看,backend直接刷脏块的机会也应该是比较小的。那么为什么我们会在pg_stat_bgwriter中看到如此奇葩的数据呢?这里面其实也有一个十分有意思的逻辑。

首先是关于buffers_backend这个指标,本身这个指标就有一定的误导性,我们今天看的代码上包含了处写脏块的地方,其实不用看代码我们都能想到第三处,那就是VACUUM。因为backend中还包含了auto vacuum,vacuum操作等写脏块的统计数据,因此我们可能会被这个指标误导。PG社区中十多年前就有人希望PG代码中把这些情况区分开来,从而让buffers_clean更有指向性,不过没有获得PG社区核心研发的认同。    

另外一点是PG数据库的策略是尽可能让数据在内存中多存放一段时间,而不急着把脏数据写盘。因此在PG数据库中,还是将检查点进程作为写脏块的主力,如果你的系统中的buffers_alloc增长很缓慢的话,那么只要按照checkpointer的节奏慢慢写脏块就可以了,backend总是能够找到所需要的buffer,因此也就没必要让bgwriter去写脏块了。这种算法对于早些年比较缓慢的IO子系统来说是十分友好的,不过对于当今高性能的IO系统来说,不够高效,比较适合目前IO性能一般的云上小型数据库,而对于采用高性能IO设备的大型数据库来说,并不一定是很优化的。

基于上面的分析我们可以了解到,如果你看到你的系统中的buffers_clean总是为0或者总是慢速增长,那么并不说明系统存在问题,而是说明你的系统写负载还不算太高,bgwriter还犯不着去帮你刷盘而已。对于IO性能还不错的系统,或者说规模不算太大的数据库来说,PG的这种刷脏块的方法还是可以胜任的,在一些超大型系统中,可能这方面会成为瓶颈。我看到Polardb-PG、openGauss等基于PG代码的数据库产品中,对这方面都做了一些优化,引入了专门的机制来替换BGWRITER。目前还没有对这些代码进行分析,因此不知道这方面的改善如何。

今天分析PG这方面源代码的另外一个收获是从中学到一些PG的SHARED BUFFERS相关的优化策略的。首先shared buffers不能设置得太少,否则backend真正开始大量刷脏块了,那么SQL的性能是会受到很大的影响的。其次是CHECKPOINTER的相关参数设置要合理,根据底层IO的能力配置合适的参数,让CHECKPOINTER刷盘的速度能够跟得上buffers_alloc的速度。如果我们发现buffers_clean的增长比较快了,那么说明目前系统的负载对shared buffers 有一定的压力了,那么我们就需要考虑调整bgwriter相关的参数了。       

最后的源码链接是我两年多前写的一篇关于PG SHARED BUFFERS的内部结构的分析文章,文章很长,有8000多字,有兴趣的朋友可以阅读一下。文中有些观点可能和今天的文章有些不大一致了,如果存在这方面的观点,那么就以今天的文章为准吧。对PG数据库的理解都是一点一点的从模糊到清晰,从不大准确到相对准确的。认知的提升是从一个个案例,一段段源码的分析中逐渐完成的。

来源:白鳝的洞穴内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯