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

database

简介

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。

 

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

以上是 五个Taurus垃圾回收compactor优化方案,减少系统资源占用 的全部内容, 来源链接: utcz.com/z/534182.html

回到顶部