Qiuchi
(Ti D Ber T Hwl2t Uf)
1
【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.0
【遇到的问题：问题现象及影响】
在 tidb 节点没有其它链接的情况下，使用 jdbc 连接数据库，有概率在握手时卡住0-30秒不等，但最终都可以连接上。
大概说一下场景，我们使用 kettle jdbc 直连 tidb，没有使用连接池，所以其实每次都会创建新连接。同时老版本 kettle 配不了 connectTimeout，导致在上述问题出现的时候，jdbc 就会报 communication link failure。这个问题之前偶尔出现过但不频繁，并且是在被 spark 并发创建大量连接时才会出现，可发现问题表现是即使没有负载也会有这个情况。
出现某一次连接慢的时候 tidb 本身没有输出什么日志，监控上面有问题的节点和其它正常的节点也没什么区别，所以因为这个我一度怀疑是负载均衡配的有问题，但后来通过直连每个节点发现了有问题的 tidb。
后来我抓包看了下，发现慢的时候是卡在 tcp 握手成功之后和 tidb 协商验证方式之前，这俩正常情况下几乎没有延迟
但慢的时候就很慢，会隔很长的时间，甚至多了tcp keepalive，不过也说明连接本身应该没问题
修改：似乎也不全是卡在同一个地方，比如这个就是卡在密码认证之后和返回认证成功之前
不知道有没有遇到过这个问题的佬
容易出现的话，把tidb的日志级别调整成debug，然后再看看有没有日志。
1 个赞
通过 pd，能看到火焰图，debug/profile那里，弄下来看看。
1 个赞
Qiuchi
(Ti D Ber T Hwl2t Uf)
5
是说这个吧，但我不大会看。。慢的情况大概十几次创建连接会出现一次，这个咋看啊
goroutine.txt (113.6 KB)
cpu.zip (120.8 KB)
Heap.zip (19.6 MB)
Mutex.txt (24.5 MB)
这样搞：
如果是卡住了，就把其他没卡住的链接 kill掉，只留一个卡住了。然后获取下火焰图。看看关于链接的部分卡在了哪里。然后对应着看看代码。
不过这个确实很难确定原因，也就是看看，能不能找到一些线索。
2 个赞
nobody
(不定时出现)
10
一般建立链接 tidb 内部没啥特别重的操作，就是分配一些内存，然后把一些连接信息和版本信息写到 packet 里返回给客户端，基本都是内存操作。可以看下 node_exporter 监控里的 vmstat 看看内存分配情况以及排查下客户端到tidb-server 的网络情况。
1 个赞
Qiuchi
(Ti D Ber T Hwl2t Uf)
11
我们确实是有数据库审计，我之前也怀疑这个，但是那个是直接装在负载均衡上的，直连后来发现有一样的问题
Qiuchi
(Ti D Ber T Hwl2t Uf)
12
网络和内存分配都没有什么问题，因为后面我都给他踢出负载均衡了它基本没有连接了，而且这个包我是在tidb的服务器上抓的，应该不是网络的问题。我后来发现，有问题的那个节点是负责auto analyze的tidb，而且在不执行analyze的时间段似乎就没有这个问题，具体有没有关系我再观察一段时间
有猫万事足
13
可以考虑子版本升级一下看看。
https://docs.pingcap.com/zh/tidb/v6.5/release-6.5.1
从6.5.1的修复列表看是修复了大量和auto analyze有关的问题。
何况现在最新的子版本是6.5.11了。
kevinsna
(Ti D Ber P O Zcnp Ja)
14
没有使用连接池的话，每次都会创建新连接。这可能导致连接建立的开销较大。建议使用连接池来管理数据库连接，减少连接创建和销毁的开销
