当前位置: 首页 > news >正文

7.5.4 MVCC优化测试

作者: h5n1 原文来源: https://tidb.net/blog/4e02d900

1. 背景

由于MVCC 版本数量过多导致rocksdb扫描key数量过多影响SQL执行时间是tidb经常出现问的问题,tidb也一直在致力于优化该问题。 一些优化方式包括比:

(1) 从传统的集中式GC变为GC in compaction filter,在rocksdb compact时进行GC,降低GC时性能影响,同时能将GC后的数据直接清理。

(2) 引入region-compact-min-redundant-rows、region-compact-redundant-rows-percent参触发更多的compact 以清理冗余的mvcc版本

(3) 修复GC相关的bug ,如: https://asktug.com/t/topic/932932

(4) 7.5.4及该版本后的版本进一步通过mvcc.delete_rows方式解决region-compact-min-redundant-rows不能触发的场景。

 有小伙伴在7.5.1版本遇到了这个问题,有一张表目前只有40000多万数据,但全表扫描出来要6亿多total\_keys,GC设置为24小时,检查GC tso推进正常

image.png

image.png

但是检查该表的region 发下最小的tso时间还很早,很明显有些mvcc数据还没有被GC,也就没法清理。

image.png

image.png

  猜测是由于gc in compaction filter等特性导致历史数据没有被GC,而且region上没有多少冗余的mvcc版本导致region-compact-min-redundant-rows等未起作用。通过7.5.4 版本引入的MVCC优化特性:**优化存在大量 DELETE 版本时 RocksDB 的 compaction 触发机制,以加快磁盘空间回收 #17269**  issue描述,小伙伴很可能也是这种场景,目前暂未确认,也未进行版本升级尝试。

要解决上述问题,除了版本升级外还可以通过以下方式解决

(1) 修改参数enable-compaction-filter 关闭compaction filter使用传统GC模式

(2) 使用region compact 手工对表compact,可以通过threads设置并发度。

(3) 重建表表后清理原表,但影响业务

(4) 降低region-compact-min-redundant-rows、region-compact-redundant-rows-percent参数值以触发更多compact,但如果冗余mvcc极少的情况下可能没效果。

2. 测试内容
本测试是验证7.5.4版是否能够解决背景中描述的问题,测试时初始化一张表,然后分段删除表数据,只保留中间和末尾的极少部分数据。

(1) 在7.5.1版本按要求删除数据后,观察GC情况和全表扫描的total_keys数量。

(2) 重启7.5.1集群观察重启操作对compact/GC是否有影响,以排除升级重启后影响GC。

(3) 升级到7.5.4版本观察测试表的GC情况和全表扫描的total_keys数量。

(4) 在7.5.4版本按照步骤1重新测试和观察。

测试中相关参数保持默认值,如GC时间。

3. 版本7.5.1删除后测试
测试表插入了42578713条数据,按要求删除后剩余18754条。

刚删完(2025-01-14 14:22:53)后total_keys:84985676

image.png

2个多小时后total_keys:35037709

image.png

直到7个小时后key数量一直保持稳定未变化,total_keys:35037709

image.png

从监控可以看到17:00后GC几乎无活动。

image.png

4. 测试集群重启影响

  重启集群后经过20多分钟观察,keys降到以下数值后未变化,total keys从重启前的35037709降为34866180,减少171529,约0.4%

image.png

从GC监控上看有3次GC,但实际是从21:30的GC后 keys数量就一直未变化。

image.png

问题: 再重启后观察total keys:61222618数量比重启前的35037709还要高很多,直到最后稳定在34866180, 为什么这个会变高呢?

image.png

5. 升级7.5.4版本

使用offline方式升级到7.5.4版本后 观察GC情况,可以看到22:10分左右完成升级后-22:46 totalkeys降到了5295017

image.png

 从监控上可以看到明显GC活动比单纯的重启集群要更剧烈些

image.png

6. 新版本重复测试
在新的7.5.4集群重复前面的的测试观察delete数据后GC情况。初始 51611460条数据,删除后剩余8837条。9:48 首次检查total\_keys;100164327

image.png

10:22 再次检查total_keys;17446709,34分钟内totalkeys减少了82717618。

image.png

  监控上看GC/compact活动也很频繁。

image.png

7. 结论

7.5.4版本对于大量delete版本优化改进还是比较明显,建议升级到较新的版本。

http://www.lryc.cn/news/522982.html

相关文章:

  • STM32 FreeRTOS 事件标志组
  • 生成树机制实验
  • 企业分类相似度筛选实战:基于规则与向量方法的对比分析
  • 2024年博客之星年度评选—创作影响力评审入围名单公布
  • 递归40题!再见递归
  • 社区版Dify实现文生视频 LLM+ComfyUI+混元视频
  • 【LLM】Openai-o1及o1类复现方法
  • jlatexmath-android如何实现自定义渲染字符
  • dockerhub上一些镜像
  • Python 爬虫学习指南与资料分享
  • TypeScript特有运算符和操作符
  • 介绍下常用的前端框架及时优缺点
  • MATLAB算法实战应用案例精讲-【数模应用】图形变换和复杂图形组合(附python和MATLAB代码实现)
  • SpringMVC 实战指南:打造高效 Web 应用的秘籍
  • doris: Flink导入数据
  • Nginx在Linux中的最小化安装方式
  • CSS布局新视角:BFC(块级格式化上下文)的作用与优势
  • PCL K4PCS算法实现点云粗配准【2025最新版】
  • 02IO篇(D2_深入IO模型)
  • 记录一次微信小程序使用云能力开发的过程
  • Learning Prompt
  • 事务处理系统 (Transaction Processing System, TPS)
  • 【PCIe 总线及设备入门学习专栏 5.3.2 -- PCIe 枚举与 PCIe PHY firmware 的区别与联系】
  • 职场的三个阶段及其应对规划:以前端开发工程师为例
  • 某讯一面,感觉问Redis的难度不是很大
  • RV1126+FFMPEG推流项目(9)AI和AENC模块绑定,并且开启线程采集
  • excel实用工具
  • 基于.Net Core+Vue的文件加密系统
  • 工业网口相机:如何通过调整网口参数设置,优化图像传输和网络性能,达到最大帧率
  • 深入理解 Windows Server 的核心功能:现代 IT 架构的基石