搜索
简帛阁>技术文章>五个Taurus垃圾回收compactor优化方案,减少系统资源占用

五个Taurus垃圾回收compactor优化方案,减少系统资源占用

简介

TaurusDB是一种基于MySQL的计算与存储分离架构的云原生数据库,一个集群中包含多个存储几点,每个存储节点包含多块磁盘,每块磁盘对应一个或者多个slicestore的内存逻辑结构来管理. 在taurus的slicestore中将数据划为多个slice进行管理,每个slice的大小是10G,Taurus架构图如下:

TauruDB的存储层支持append-only写和随机读,最小数据存储逻辑单元为plog,每个slice中包含多个plog,默认每个plog的大小为64M。slice中的plog主要用来存放page。Plog中存放中不同版本的page,有些老page已经过期,需要删除;有些page是新page,需要被保留下来。

Compator主要用来清理plog中过期的page,把一个plog上所有没有过期的page搬移到一个新plog,老的plog删除掉。

Compactor的任务需要频繁访问内存中索引结构和读写plog中的page页,这两部分都属于整个系统中关键资源,锁竞争的压力比较大,会直接影响性能,所以compactor的优化方案主要围绕减少内存访问和磁盘IO,需要考虑以下几个点:

A、 选取的清理的plog集最优问题,每次回收需要搬运有效page,搬运的有效page数越少,磁盘IO就越小。如何每次调度都选取到垃圾量最大的一批plog;

B、 垃圾量是否分布均匀,如何让垃圾集中到一起,回收垃圾集中的plog,提高回收效率;

C、 回收周期是固定的,怎么样保证在每个周期内,都能取到最优plog集。

当前,我们提出了几个可以有效减少page搬运数,从而达到减少IO目的的方案。

关键点1:全局调度

全局调度的方案增大plog垃圾量的排序范围,从slice的范围增大到slicestore的范围。因为考虑到后面需要针对单个磁盘进行“加速回收”,所以不扩大到一个存储节点的全局范围。

全局调度方案按照slicestore来选取回收plog,先遍历所有的slicestore,然后在slicestore内部进行垃圾量排序,选取最多的若干个plog进行回收;

优点:有效避免一个slicestore中由于垃圾分布不均匀引起的plog的无效搬运,减少对plog的读写产生的IO;

缺点:排序范围增大后,排序算法会增加CPU的消耗;

关键点2:排序算法优化

原始方案中在slice内部对plog按照垃圾量排序采用C++标准库排序(std::sort),该算法内部基于快速排序、插入排序和堆排序实现。原始方案中每个slice中最多存有160个plog,小数据量的排序或许效率影响不大,但是一个slicestore中存储成百上千的slice,排序算法的效率问题就值得关注。

Taurus设计了一种topN算法,能够提升该场景下的效率。假设需要在n个元素中选取m个最大的元素,两种算法的时间复杂度和空间复杂度:

C++标准库排序时间复杂度为O(nlogn),空间复杂度为O(nlogn);

topN算法排序时间复杂度为O(nlogm),空间复杂度为O(1);

Compactor应用场景中,n和m相差几个数量级,topN算法在时间和空间上都更具优势。

优点:减少时间复杂度和空间复杂度;

关键点3:调度数优化

公共线程池分配给compactor的线程数是固定的,每个周期调度器生成一次任务。原始方案中compactor的每次生成的任务数由slice个数决定,会导致任务队列中的任务数过多或者过少。过多的话会失去时效性,也就是说plog的垃圾量会随着时间改变,如果在队列等待执行的时间太长,可能就不是当前最高垃圾量的plog,同时一次挑选的plog个数太多,会增加算法的时间和空间复杂度;过少的话,compactor线程没有跑满,会导致垃圾回收速度降低。

调度数优化也是基于全局调度优化,调度策略只需要保证在一个调度周期内,任务队列中任务数刚好满足compactor线程执行。假设有8个slicestore,分配了24个执行线程,每个线程每个调度周期完成一个plog的回收,则每个调度周期每个slicestore只需要生成3个任务。

调度数优化即记录公共线程池中正在执行和准备执行的任务数,跟据记录决定本轮调度生成多少个回收任务,从而保证执行线程刚好够用,且不多不少。

优点:保证垃圾回收速度,最优回收的plog集,有效的减少page的搬运量。

关键点4:冷热分区优化

在数据库系统中,数据的更新并不是相同频率,一些数据页更新或者写入会更加频繁(例如系统页),这部分页面被称作热页,另外一些更新不频繁的称作冷页。如果把冷页和热页混合放到一起,就会导致更高的写放大。举个简单的例子,假设有100个热页和10个冷页,冷页基本不更新但是每次垃圾回收,都需要重复把冷页搬运一次。如果把冷页单独写入一个plog,那么在垃圾回收阶段,就可以减少重复搬运这部分冷页,达到减少IO放大的效果。

优点:提高垃圾回收的效率和速度。

缺点:需要额外的内存记录热度信息。

关键点5:磁盘逃生优化

为了后台线程比如备份、快照、垃圾回收、页面回放等线程有足够的磁盘空间运行,在磁盘容量使用到达一定阈值,会置Full标志位,同时停止前台IO。在极端情况下,磁盘使用到阈值前台IO会出现断崖式下跌为零:

为了避免在磁盘容量达到一定阈值之后前台IO完全停止,在磁盘使用率未达到阈值时,就应该有相应的处理机制。比如说在磁盘使用率未达阈值时,增加如下处理:

A、 降低前台IO,减少磁盘的压力;

B、 加速垃圾回收,也就是TaurusDB中的compactor机制;

A点不涉及compactor的功能,所以本文先不涉及,下面主要介绍两种加速机制:

1.修改写IO优先级

Compactor作为后台线程,考虑到整个系统的效率,正常运行时plog写IO优先级默认为low。在加速回收阶段,plog的IO需要修改为high。

2.提高执行速度

前文可知,公共线程池为compactor分配固定数目执行线程,而且运行过程中只支持扩容不支持恢复。如果压缩其他后台任务的执行线程,对整个系统的影响太大,量也不易控制。所以不考虑。

考虑到过程中不能扩容,那就初始化就扩容,通过控制调度任务数控制任务执行速度。例如,假设compactor的运行线程在正常场景下为4个,加速状态下需要增加到8个。可以在公共线程池中先分配8个线程,在正常场景下,控制任务队列为4个,另外4个线程处于wait状态,只会占用文件句柄,并不影响CPU。而在加速状态下,控制任务队列中的任务数为8,就可以实现上述的加速逻辑。

所以,提升写IO的优先级能够加速page的搬运,提升垃圾回收速度。通过控制调度任务数控制任务执行速度却很难控制很精准,上下会有一定的小波动。

最后

以上提到的垃圾回收compactor优化方案中,磁盘逃生优化能够处理磁盘容量紧急情况。目前根据本地测试,在500G的小数据集情况下,IO放大能减少到原来的1/6。系统资源占用减少到原来的1/3。

 

点击关注,第一时间了解华为云新鲜技术~

简介TaurusDB是一种基于MySQL的计算与存储分离架构的云原生数据库,一个集群中包含多个存储几点,每个存储节点包含多块磁盘,每块磁盘对应一个或者多个slicestore的内存逻辑结构来管理在ta
GC,GarbageCollect,中文意思就是垃圾回收,指的是系统中的内存的分配和回收管理。其对系统性能的影响是不可小觑的。今天就来说一下关于GC优化的东西,这里并不着重说概念和理论,主要说一些实用
C性能优化细节1、使用stringEmpty给一个空字符串变量赋初始值StringEmpty是一个指代,而””是具体的实现stringfilter“”;//不建议stringfilterstringE
[SystemRuntimeInteropServicesDllImport(kernel32dll)]publicstaticexternboolSetProcessWorkingSetSize(I
优化I/O写在开头读写文件是再普通不过的活动了,以至于开发人员往往忽略了它们,但是实际上它们确实非常耗时的程序活动互联网世界受限于数据传输速率和繁忙的服务器,响应延迟可能是以毫秒而非秒计量的。当数据
GC,GarbageCollect,中文意思就是垃圾回收,指的是系统中的内存的分配和回收管理。其对系统性能的影响是不可小觑的。今天就来说一下关于GC优化的东西,这里并不着重说概念和理论,主要说一些实用
1top查看ubuntu的资源占用的命令为$:top说明:top命令就可以查看内存,cpu和进程了,很方便top:主要参数d:指定更新的间隔,以秒计算。q:没有任何延迟的更新。如果使用者有超级用户,则
方法栈帧的局部变量引用了一个对象的地址,对象保存在Java堆内存里面。而在计算机中,内存资源是十分有限的,所以当一个方法执行完毕,那么方法的栈帧就会出栈,局部变量引用也会被清除。这时,堆内存中的对象没
Java垃圾回收器的发展历史第一阶段:串行垃圾回收器:jdk131之前Java虚拟机仅仅只支持Serial收集器第二阶段:并行垃圾回收器:随着多核的出现,Java引入了并行垃圾回收器,充分利用多核性能
管理I/O,避免过度地寻道可以让硬盘更快。顺序I/O和随机I/O之间的性能差异随便就可以达到40:1,可能更多。这在数据库服务器中尤其重要,因为数据库的日志是以顺序格式写的。选择合适的硬件,合理地配置