这个方法没用过。如果近期复现的话我试试！ region相关的表只有9800行，理论全部放入内存都不至于。 现象有点像是，读不出来… 但是服务器io也挺空闲的。 不知道有没有人遇到类似的BUG 。 我也是头一次遇到这么诡异的现象。

已经通过 pd-ctl tikv-ctl 查看了region相关的信息，split尝试切割region。 v5.3.4 版本 我看也没有其他可以对region进行的操作了

这个确认过了，在term 42后，就稳定保持，leader恒定状态了。 没有region分裂和合并事件发生。 手动触发split，也一切正常。

谢大佬指点。 这个当时看了，大概几百行的执行计划…SQL很庞大。所以我优先去分析的这个conn=13对应的 tidb/tikv输出的日志信息，发现仅有 上边截图的 rocksdb_read_byte 这些全为0 的信息，且已经无限循环了好几个小时。

版本升级是在进行中的事了，升级周期很长，估计得年后才能上线新版本啦。 我们线上所有版本都是5.3.4呢… 这个问题是第一次发生，挺奇怪的呢。 leader retransfer ，这个理论上我split后，会触发一次新region leader选举的。没留下截图

坐等各位大佬，各抒己见

期待PPT啊。 苦大数据已久。

这里追问一下， （包含所有列值） ，我如果update一列，也会把其他不变的列，load到内存，生成新的kv，进行写入么？ 还是只update一列的数据到内存即可。 之前看过一篇帖子（专栏 - TiDB MVCC 版本堆积相关原理及排查手段 | TiDB 社区 说是把所有列都拿出来，根据新的值生成一行新的kv，然后写入到底层数据。所以update的成本单纯内存来说，还是比delete要高。由此也可以推断，用replace来优化delete，其实并不成立。因为replace其实也是update

感谢大佬。 我好好理解下这段话，原理这块还得持续学习！

资源消耗呢？ delete成本更高吧。 update 应该只是 k_new-version = new_value。操作的时候只是把列拿到内存去庚新把。 delete我之前看到一篇文章说是整个行拿到内存去。。。

我记得delete from t1 where xx;的原理是把 要删除的内容都load到tidb-server的内存里。 update在内存方面的原理还不知道。 所以从内存消耗方面考虑，是不是update is_del =1 比 delete 要轻量级? 但是在 mvvc scan keys方面，是不是也有理论支撑？

从tidb 读取和写入的 scan 原理入手，有参考意义么？

根源是，我们有一台机器，会频繁的ssh到这台节点来执行shell命令获取某些监控信息，导致systemd里存在了大量的sshd相关的failed状态，采集时就变慢了。 监控节点年前就停掉了，后来一直处理巡检，就没跟进这个问题。 至此，这个问题算是告一段落。感谢各位大佬的支持！

已经解决掉了。最终执行命令： systemctl reset-failed来清理failed服务。这样systemd就不再记录这些信息，采集也就变快了。

现在基本确定是有过多的sshd@ID-IP1-IP2:端口.service信息。 collect 去收集systemd的这个信息时，有1W多条失败，导致采集变慢

我们当前还是 Linux node1 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

感谢！ 我看看这个issue

[root@node1 ~]# systemctl status ● node1 State: degraded Jobs: 0 queued Failed: 12742 units Since: Fri 2023-04-28 10:19:12 CST; 9 months 23 days ago

现在现在的核心问题是， 1、为什么有如此多的sshd@.service信息 2、连接从哪儿来。 3、即使有，也不应该阻塞采集才对。