数据库链接抖升，如何排查具体是什么链接？

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境
【TiDB 版本】V7.5.6
【问题复现路径】无
【遇到的问题：问题现象及影响】
集群正常运行中突然链接数抖升，检查dashbard中对应时间点的慢查询也没有慢查询。

image
image554×250 22 KB

唯一可疑的是有较多的Sleep的进程。
image
image490×521 23.3 KB

1、Connection Count中的连接数是服务器的连接数，是tidb节点的连接数，还是进程数？
2、如果获取processlist中Sleep进程执行的sql语句？

2

连接数

Sleep 代表当前未执行 SQL

3

我看到连接上有digests，能根据这个或者其他找到连接最后执行的语句，或者执行过的语句吗？
现在有大量sleep的连接，不知道是怎么产生的。

4

连接为了保活，做了心跳探测，Mysql 旧的心跳探测就是执行 Select 1 ，目的是为了保持连接的活跃，但是不执行其他的。在服务端看起来就是一堆sleep

后来的Mysql 为了提升探活的性能，减少损耗改成了 Ping Method

要解决这个问题只能从用户 + IP 判断连接的服务是什么，来进行改善了。
或者减少 connector alive 的时间，断开这些连接

这种问题没有最优解，要从应用侧和服无侧来看

5

你说的是tikv的心跳?

6

硬件出问题了吗

7

  • 感觉连接数的变还是有点规律
    均是从整点时刻开始缓慢攀升，在持续约半个小时后，出现断崖式下降。基于现象，高度怀疑存在某些业务操作或者定时任务在触发。此外，还还可以看到一个特征，即每次连接数的变化都会在 12 点半、15 点半这两个时刻断崖式下降，恢复到常态水平，可以考虑从这块下手，问问业务这个时间，是否存在相关业务会关闭或者重启。

  • 建议找开发对峙之前，数据库层先收集如下信息：
    1、平峰和高峰的不同用户的连接数变化，直接定位连接数暴增的用户。
    2、平峰和高峰的不同机器连到数据库的连接数变化，直接定位连接数暴增的机器ip。（需要ha开透传）

  • 针对sleep会话最后执行的SQL，可以尝试这个方法：
    SELECT * FROM information_schema.processlist WHERE COMMAND=‘Sleep’
    EXPLAIN FOR CONNECTION <conn_id>

image
image898×261 5.82 KB

8

断崖式下降是我批量kill了

9

这个有点赞，我试试

10

select DIGEST_TEXT from statements_summary where DIGEST=‘’;

image
image898×437 6.07 KB

但是这个表记录的条目可能不全。

11

这个我试过了，很多都是空的。感觉不大准，不知道是不是连接池的原因，一个链接复用多次。

12

这个不行，大部分也是没有，有返回的，根据返回也推测不出执行的是什么。
并且还必须登录对应的节点执行才行，还不是全局的。

image
image1125×109 4.4 KB

13

连接池被长事务占满了，主要特征：

  • 连接数持续高位、不释放
  • 单条 SQL 并不慢
  • show processlist 里大量 Sleep 或 Query 状态但耗时很短
14

能定位到增长的用户或者ip吗？

15

ip 来源找原因，要记录 sql 得企业版开审计，不过 sleep 大概率只是个空闲长链接

16

目前processlist里记录的ip都是负载的ip，用户也没有按业务做区分，所以用户也是一样的。

17

performance_schema.session_connect_attrs 记录有没有帮助？

1 个赞
18

恭喜入坑～

19

审计日志里面怎么提示的呢

20

:yum:社区版，没有审计日志