为了后台线程比如备份、快照、垃圾回收、页面回放等线程有足够的磁盘空间运行，在磁盘容量使用到达一定阈值，会置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。
点击关注，第一时间了解华为云新鲜技术~
