ITPub博客

首页 > 数据库 > 数据库开发技术 > WiredTiger存储引擎之六:Cache分配规则与Page的淘汰机制

WiredTiger存储引擎之六:Cache分配规则与Page的淘汰机制

翻译 数据库开发技术 作者:MongoDB中文社区 时间:2020-10-14 22:57:38 0 删除 编辑


前言


WiredTiger存储引擎系列文章将从逻辑正确、内容完整的角度全面介绍WiredTiger存储引擎。 本篇作为WiredTiger存储引擎介绍系列文章第六篇,也是本系列文章的最后一篇。

前面的内容您可以点击下方标题进行阅读:


WiredTiger存储引擎之一:基础数据结构分析

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

WiredTiger存储引擎之三:Checkpoint原理

WiredTiger存储引擎之四:WT工具编译与元数据文件剖析

WiredTiger存储引擎之五:与事务相关的数据结构以及并发控制机制


本篇包含以下内容:


  • WiredTiger存储引擎的Cache分配规则

  • 内存Page的淘汰机制



1.2 Cache的分配机制

WiredTiger启动的时候会向操作系统申请一部分内存给自己使用,这部分内存我们称为Internal Cache,如果主机上只运行MongoDB相关的服务进程,则剩下的内存可以作为文件系统的缓存(File System Cache)并由操作系统负责管理,如下图所示:


:Cache的分配规则


MongoDB启动时,首先从整个主机内存中切一大块出来分给WiredTiger的Internal Cache,用于构建B-Tree中的各种page以及基于这些page的增删改查等操作。


从MongoDB3.4版本开始,默认的Internal Cache大小由下面的规则决定:比较50% of (RAM - 1 GB)和256MB的大小,取其中较大者。例如,假设主机内存为10GB,则Internal Cache取值为50% of (10GB - 1 GB),等于4.5GB;

如果主机内存为1.2GB,则Internal Cache取值为256MB。


然后,会从主机内存再额外划一小块给MongoDB创建索引专用,默认最大值为500MB,这个规则适用于所有索引的构建,包括多个索引同时构建时。

最后,会将主机剩余的内存(排除其它进程的使用)作为文件系统缓存,供MongoDB使用,这样MongoDB可将压缩的磁盘文件也缓存到内存中,从而减少磁盘I/O。


为了节省磁盘空间,集合和索引在磁盘上的数据是被压缩的,默认情况下集合采取的是块压缩算法,索引采取的是前缀压缩算法。因此,同一份数据在磁盘、文件系统缓存和Internal Cache三个位置的格式是不一样的,如下描述:


  • 所有数据在File System Cache中的格式和在磁盘上的格式是一致的,将数据先加载到文件系统缓存,不但可以减少磁盘I/O次数,还能减少内存的占用;


  • 索引数据加载到WiredTiger的Internal Cache后,格式与磁盘上的格式不一样,但仍能利用其前缀压缩的特性(即去掉索引字段上重复的前缀)减少对内存的占用;


  •  集合数据加载到WiredTiger的Internal Cache后,其数据必须解压后才能被后续各种操作使用,因此格式与磁盘上和File System Cache都不一样。



1.3 Page淘汰机制


当cache里面的“脏页”达到一定比例或cache使用量达到一定比例时就会触发相应的evict page线程来将pages(包含干净的pages和脏pages)按一定的算法(LRU队列)淘汰出去,以便腾挪出内存空间,保障后面新的插入或修改等操作。


触发page eviction条件由如下几种参数控制,如下表所示:


参数名称

默认配置值

含义

eviction_target

80%

Cache 的使用量达到80% 时触发work thread 淘汰page

eviction_trigger

90%

Cache 的使用量达到90% 时触发application thread work thread 淘汰page

eviction_dirty_target

5%

当“脏数据”所占Cache 比例达到5% 时触发work thread 淘汰page

eviction_dirty_trigger

20%

当“脏数据”所占Cache 比例达到20% 时触发application thread work thread 淘汰page


第一种情况: 当cache的使用量占比达到参数eviction_ target设定值时(默认为80%),会触发后台线程执行page eviction;

如果使用量继续增长达到eviction_trigger参数设定值时(默认为90%),应用线程支撑的读写操作等请求将被阻塞,应用线程也参与到页面的淘汰中,加速淘汰内存中pages。


第二种情况: 当cache里面的“脏数据”达到参数eviction_dirty_target设定值时(默认为5%),会触发后台线程执行page eviction;

如果“脏数据”继续增长达到参数eviction_dirty_trigger设定值(默认为20%),同时会触发应用线程来执行page eviction。


还有一种特性情况: 当在page上不断进行插入或更新时,如果页上内容占用内存空间的大小大于系统设定的最大值(memory_page_max),则会强制触发page eviction动作。


先通过将此大的page拆分为多个小的page,再通过reconcile将这些小的pages保存到磁盘上,一旦reconcile写入磁盘完成,这些pages就能从cache中淘汰出去,从而为后面更多的写入操作腾出空间。


默认情况下WiredTiger只使用一个后台线程来完成page eviction,为了提升eviction的性能,我们可以通过参数threads_min和threads_max来设定evict server启动的后台线程数。


通过设定合理值,加速页面淘汰,避免淘汰不及时导致应用线程也被迫加入到淘汰任务中来,造成应用线程对其它正常请求操作的阻塞。


淘汰一个page时,会先锁住这个page,再检查这个page上是否有其它线程还在使用(判断是否有hazard point指针指向它),如有则不会evict这个page。


 

专栏作者:郭远威




资深大数据解决方案咨询顾问与架构师,MongoDB中文社区委员,长沙分会主席,多年通信行业大数据研发、规划、咨询经验;《大数据存储MongoDB实战指南》作者;阿里云云计算ACP认证专家。


也许您还感兴趣——

WiredTiger存储引擎之一:基础数据结构分析
WiredTiger存储引擎之二:一个Page的生命周期

WiredTiger存储引擎之三:Checkpoint原理

WiredTiger存储引擎之四:WT工具编译与元数据文件剖析

WiredTiger存储引擎之五:与事务相关的数据结构以及并发控制机制

MongoDB特定场景性能数十倍提升优化实践(记一次MongoDB核心集群雪崩故障)

性能最佳实践:MongoDB索引

性能最佳实践:MongoDB查询模式和分析
性能最佳实践:MongoDB数据建模和内存大小调整
MongoDB 4.4 新特性解读

最新版MongoDB中文手册发布 | 翻译持续招募中!

MongoDB的WiredTigerLAS.wt大小异常分析
常用高并发网络线程模型设计及MongoDB线程模型优化实践
MongoDB网络传输处理源码实现及性能调优-体验内核性能极致设计
MongoDB 事务,复制和分片的关系

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/69961190/viewspace-2726983/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2020-02-14

  • 博文量
    21
  • 访问量
    5597