做网站云服务器2m宽带够用吗,怎么做电商运营的基本步骤,织梦网站自适应怎么做,宝宝个人网站模板作者#xff1a; h5n1 原文来源#xff1a; https://tidb.net/blog/4e02d900 1. 背景 由于MVCC 版本数量过多导致rocksdb扫描key数量过多影响SQL执行时间是tidb经常出现问的问题#xff0c;tidb也一直在致力于优化该问题。 一些优化方式包括比#xff1a; (1) 从传统… 作者 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\_keysGC设置为24小时检查GC tso推进正常但是检查该表的region 发下最小的tso时间还很早很明显有些mvcc数据还没有被GC也就没法清理。 猜测是由于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 2个多小时后total_keys:35037709 直到7个小时后key数量一直保持稳定未变化,total_keys:35037709 从监控可以看到17:00后GC几乎无活动。 4. 测试集群重启影响 重启集群后经过20多分钟观察keys降到以下数值后未变化total keys从重启前的35037709降为34866180减少171529约0.4%从GC监控上看有3次GC但实际是从21:30的GC后 keys数量就一直未变化。问题 再重启后观察total keys61222618数量比重启前的35037709还要高很多直到最后稳定在34866180 为什么这个会变高呢 5. 升级7.5.4版本 使用offline方式升级到7.5.4版本后 观察GC情况可以看到22:10分左右完成升级后-22:46 totalkeys降到了5295017 从监控上可以看到明显GC活动比单纯的重启集群要更剧烈些6. 新版本重复测试 在新的7.5.4集群重复前面的的测试观察delete数据后GC情况。初始 51611460条数据删除后剩余8837条。9:48 首次检查total\_keys10016432710:22 再次检查total_keys1744670934分钟内totalkeys减少了82717618。 监控上看GC/compact活动也很频繁。7. 结论 7.5.4版本对于大量delete版本优化改进还是比较明显建议升级到较新的版本。
