【TiDB 使用环境】生产环境
【TiDB 版本】v6.5.3
【部署方式】机器部署
现在观察到底情况是119节点，复杂高于其它节点
但是两个tidb节点的连接数差不多
1 个赞
看起来 119 上还有监控相关的服务，可能是这些服务导致机器负载更高
2 个赞
119部署的服务多一些，连接数也多点。此外，就算同样的连接数，如果119上处理一些大的事务，也可能导致负载比121压力大，不能仅比较连接数，，没有太大意义，顺便看一下有没有热点问题
1 个赞
2台节点连接数参不多，可能119上部署的服务多一些。
检查119 节点非 TiDB 进程（监控、agent、定时任务），用top或者htop定位高 CPU 进程。
1 个赞
部署其他额外组件了吗
混合部署，大概率会出现这样的问题不奇怪了，唯一的解法就是拆分服务，拆分资源。
1 个赞
优先排查是否有重 SQL 集中在 119 节点执行，其次检查节点硬件 / 配置差异和中间件路由策略
请求分布不均，重点看下119节点
1 个赞
也感觉是分布不均造成的。
没有，只有截图的tidb相关组件
已经持续很久这个现象了，我也查看了 processlist，并没有什么异常
1 个赞
对业务影响情况严重吗
没影响，但是这个现象不正常呀
真实的CPU使用率不高（2.4%），119 load高主要原因应该就是第一个回复所说的监控服务导致的。所有的监控组件都在119上，进程数量肯定会比121多很多。如果想验证的话，可以考虑单独把119上的监控进程停掉，看看load值是否下降。
Load（负载） ：是进程队列的长度，即有多少进程在等待被调度或正在运行。
Load Average：1 分钟、5 分钟、15 分钟 的平均值，在 top、uptime 等命令中显示。
另外也得看119本身是几核的CPU（看着像是64c的），load除以核心数，看结果是否 > 1。
1 个赞
119部署的东西不少
会不会有冲突
应该没有影响
应该没影响