大并发下的连接异常

[smily]

某线上授课系统底层库采用TiDB（6.1），上课前扫码签到（需访问多个库），均发现连接耗时超长，出现较多登录超时现象；经全链路分析可见，连接TiDB耗时超长；
因情况紧急，迁移部分库到MySQL；再次开放系统，迁移到MySQL后连接正常，留在TiDB的仍然出现连接超时。
针对TiDB做了如下排查：
1、主机资源、系统参数等都是按照官方的建议配置
2、负载均衡策略为最少链接
3、计算节点扩容至5节点
4、网络方面的防火墙、数据库审计、带宽没问题
5、无用的测试数据已清理
6、优化tidb性能参数
tidb_mem_quota_query为4G；
max_execution_time为0；
tidb_mem_oom_action为CANCEL；
server-memory-quota为32G；
tidb_replica_read为leader-and-follower；
max-server-connections为0；
token-limit为1000；
max-procs为0；
7、数据库磁盘的吞吐是达到4000或以上；通过sysbench进行数据库读写性能测试
8、tidb、tikv日志无相关报错。

请教各位，还有哪些排查方向，多谢！

[forever]

1.出问题时数据库资源是否使用率很高
2.有没有从tiup的客户机上操作下，连接负载均衡ip跟tidb IP分别试下，判断下是否负载均衡出问题了

[alfred]

1.应用层超时报错的日志可以贴出来看下
2.系统层负载情况可以贴出来看下，像CPU、内存、IO的监控

[smily]

查看了热点，看上去也还好

看db的连接数，也没有太夸张

瞬时流量还是比较大的

CPU使用率，tidb明显偏高

[smily]

回复的信息有些凌乱，还请谅解

[smily]

请大家指导~

[yilong (yi888long)]

1. 看起来有两个 tidb-server，为什么其中一个的 cpu 使用率明显比另一个高？前端负载均衡是否配置合理？
2. TiKV 看起来 max 也是某两个比较高，不知道是同一时间点，还是不同时间点。如果是某个时间点，某个 tikv 比较高，可能是热点，可以看看是读热点，还是写热点。看看是否能够打散或者拆分。

[smily]

也曾怀疑过热点，查了一下，还好；不过您说的两个tidb-server负载不均倒是提醒了我，谢谢。