我内部反馈下吧。

企业版本支持 有企业级工具提供改造方法。 https://www.pingcap.cn/ [image]

离线源包涵 arm 和 x86 包即可，tiup 当前代码上支持。 当前这么用的，没听说过。不推荐，真用的话做好踩坑准备。

OK 了？

出问题的时候调大 gc，直到修复 如果 gc 了，那么是补不了的，只能放弃。

换了 io2 好了？

有很多应该不预期。6.5.0 版本？推荐可以试试先升级到 6.5.12.

降本降的服务器配置很差？盘至少得 ssd 的。尤其看起来你们业务压力还是蛮高的。

去 tidb 日志里面，搜索下 memory quota 类似关键字，是不是在频繁触发 tidb 的内存管理。 推测就是 tidb 内存用的多，触发内存管理杀 sql，实际上没有啥 sql 能杀。一直在这个逻辑里面导致 cpu 高。重启释放掉内存即可。 本质问题应该是内存使用不合理或者内存溢出了。

重启 tidb server 应该能解决 尽快升级到 853 版本吧。

6.6.0-DMR: 2023-02-20 没看过 6.6.1 版本。 而且看描述是裸 kv 使用？

cdc 原生支持这个 sink 么？是不是用的三方的什么软件。。。

新版本显式事务，SELECT … FOR UPDATE 是行锁。这样可以避免写冲突。 你说的读写锁没太明白什么意思。

pd 的数据盘是什么盘。 看日志是落盘慢。pd 的 io 不高但是对盘的 duration 要求比较高。推荐至少是 ssd 的盘。

@GreenGuan 这个回复解决了你的问题了么？

已经反馈内部。

嗯 可以按照上面老师的推荐，修改下 storage.block-cache.capacity 更小一点，应该能行。

连接到的 tidb-server 是一个节点么？可以考虑滚动重启下应用端，刷一次连接试试。

滚动重启下 tikv-server 算了。应该能释放。 tikv 还有一些 region meta 、grpc 等内存使用，有时候内存用超一点可能也预期。。。