WiredTiger存储引擎之二:一个Page的生命周期

前言

本系列文章将从逻辑正确、内容完整的角度全面介绍WiredTiger存储引擎。
本篇作为WiredTiger存储引擎介绍系列文章第二篇,包含如下内容:
  • Page的生命周期
  • Page的状态
  • Page相关参数与调优
通过第一篇介绍,我们了解到数据以page为单位加载到cache、cache里面又会生成各种不同类型的page及为不同类型的page分配不同大小的内存、eviction触发机制和reconcile动作都发生在page上、page大小持续增加时会被分割成多个小page,所有这些操作都是围绕一个page来完成的。
因此,有必要系统的分析一页page的生命周期、状态以及相关参数的配置,这对后续MongoDB的性能调优和故障问题的定位和解决有帮助。

Page的生命周期

Page的典型生命周期如下图所示:

图:page的生命周期

 

第一步:pages从磁盘读到内存;

第二步:pages在内存中被修改;

第三步:被修改的脏pages在内存被reconcile,完成后将discard这些pages。

第四步:pages被选中,加入淘汰队列,等待被evict线程淘汰出内存;

第五步:evict线程会将“干净“的pages直接从内存丢弃(因为相对于磁盘page来说没做任何修改),将

经过reconcile处理后的磁盘映像写到磁盘再丢弃“脏的”pages。

 

pages的状态是在不断变化的,因此,对于读操作来说,它首先会检查pages的状态是否为WT_REF_MEM,然后设置一个hazard指针指向要读的pages,如果刷新后,pages的状态仍为WT_REF_MEM,读操作才能继续处理。
与此同时,evict线程想要淘汰pages时,它会先锁住pages,即将pages的状态设为WT_REF_LOCKED,然后检查pages上是否有读操作设置的hazard指针,如有,说明还有线程正在读这个page则停止evict,重新将page的状态设置为WT_REF_MEM;如果没有,则pages被淘汰出去。

Page的各种状态

针对一页page的每一种状态,详细描述如下:
WT_REF_DISK:
初始状态,page在磁盘上的状态,必须被读到内存后才能使用,当page被evict后,状态也会被设置为这个。
WT_REF_DELETED:
page在磁盘上,但是已经从内存B-Tree上删除,当我们不在需要读某个leaf page时,可以将其删除。
WT_REF_LIMBO:
page的映像已经被加载到内存,但page上还有额外的修改数据在lookasidetable上没有被加载到内存。
WT_REF_LOOKASIDE:
page在磁盘上,但是在lookasidetable也有与此page相关的修改内容,在page可读之前,也需要加载这部分内容。
当对一个page进行reconcile时,如果系统中还有之前的读操作正在访问此page上修改的数据,则会将这些数据保存到lookasidetable;当page再被读时,可以利用lookasidetable中的数据重新构建内存page。
WT_REF_LOCKED:
当page被evict时,会将page锁住,其它线程不可访问。
WT_REF_MEM:
page已经从磁盘读到内存,并且能正常访问。
WT_REF_READING:
page正在被某个线程从磁盘读到内存,其它的读线程等待它被读完,不需要重复去读。
WT_REF_SPLIT:
当page变得过大时,会被split,状态设为WT_REF_SPLIT,原来指向的page不再被使用。

Page的大小参数

无论将数据从磁盘读到内存,还是从内存写到磁盘,都是以page为单位调度的,但是在磁盘上一个page到底多大?是否是最小分割单元?以及内存里面的各种page的大小对存储引擎的性能是否有影响?本节将围绕这些问题,分析与page大小相关的参数是如何影响存储引擎性能的。
总的来说,涉及到的关键参数和默认值如下表所示:

表:关键page参数和默认大小

参数名称

默认配置值

含义

allocation_size

4KB 磁盘上最小分配单元
memory_page_max 5MB 内存中允许的最大page值
internal_page_max 4KB 磁盘上允许的最大internal  page值
leaf_page_max 32KB 磁盘上允许的最大leaf  page值
internal_key_max 1/10*internal_page internal page上允许的最大key值
leaf_key_max 1/10*leaf_page leaf page上允许的最大key值
leaf_key_value 1/2*leaf_page leaf page上允许的最大value值
split_pct 75%

reconciled的page的分割百分比

详细说明如下:

allocation_size

MongoDB磁盘文件的最小分配单元(由WiredTiger自带的块管理模块来分配),一个page的可以由一个或多个这样的单元组成;默认值是4KB,与主机操作系统虚拟内存页的大小相当,大多数场景下不需要修改这个值。
memory_page_max
WiredTigerCache里面一个内存page随着不断插入修改等操作,允许增长达到的最大值,默认值为5MB。当一个内存page达到这个最大值时,将会被split成较小的内存pages且通过reconcile将这些pages写到磁盘pages,一旦完成写到磁盘,这些内存pages将从内存移除。
需要注意的是:split和reconcile这两个动作都需要获得page的排它锁,导致应用程序在此page上的其它写操作会等待,因此设置一个合理的最大值,对系统的性能也很关键。
如果值太大,虽然spilt和reconcile发生的机率减少,但一旦发生这样的动作,持有排它锁的时间会较长,导致应用程序的插入或修改操作延迟增大;
如果值太小,虽然单次持有排它锁的时间会较短,但是会导致spilt和reconcile发生的机率增加。
internal_page_max
磁盘上internalpage的最大值,默认为4KB。随着reconcile进行,internalpage超过这个值时,会被split成多个pages。
这个值的大小会影响磁盘上B-Tree的深度和internalpage上key的数量,如果太大,则internalpage上的key的数量会很多,通过遍历定位到正确leaf page的时间会增加;如果太小,则B-Tree的深度会增加,也会影响定位到正确leaf page的时间。
leaf_page_max
磁盘上leaf page的最大值,默认为32KB。随着reconcile进行,leaf page超过这个值时,会被split成多个pages。
这个值的大小会影响磁盘的I/O性能,因为我们在从磁盘读取数据时,总是期望一次I/O能多读取一点数据,所以希望把这个参数调大;但是太大,又会造成读写放大,因为读出来的很多数据可能后续都用不上。
internal_key_max
internalpage上允许的最大key值,默认大小为internalpage初始值的1/10,如果超过这个值,将会额外存储。导致读取key时需要额外的磁盘I/O。
leaf_key_max:
leaf page上允许的最大key值,默认大小为leaf page初始值的1/10,如果超过这个值,将会额外存储。导致读取key时需要额外的磁盘I/O。
leaf_value_max:
leaf page上允许的最大value值(保存真正的集合数据),默认大小为leaf page初始值的1/2,如果超过这个值,将会额外存储。导致读取value时需要额外的磁盘I/O。
split_pct
内存里面将要被reconciled的 page大小与internal_page_max或leaf_page_max值的百分比,默认值为75%,如果内存里面被reconciled的page能够装进一个单独的磁盘page上,则不会发生spilt,否则按照该百分比值*最大允许的page值分割新page的大小。
专栏作者:郭远威
MongoDB中文社区委员,长沙分会主席,《大数据存储MongoDB实战指南》作者。资深大数据架构师,通信行业业务架构与数据迁移专家
赞(7)
未经允许不得转载:MongoDB中文社区 » WiredTiger存储引擎之二:一个Page的生命周期
分享到: 更多 (0)

评论 2

评论前必须登录!

 

  1. #1

    这句话中磁盘映像,一开始没理解过来,感觉写成会更容易理解些。

    loveaishengtt3周前 (06-11)
  2. #2

    我用尖括号括起来的,居然没了。。。

    loveaishengtt3周前 (06-11)