目录

一、前言

二、连接池监控

三、排查思路

    1. 连接池存在等待连接

    2. 应用负载过高

    3. 应用 STW

    4. 网络阻塞

    5. 数据库&数据库中间件异常

四、总结

一

前言

应用连接数据库基本上都是通过连接池去连接，比如常用的 HikariCP、Druid 等，在应用运行期间经常会出现获取连接很慢的场景，大多数同学都是一头雾水，不知道从哪下手。而且很多时候都是偶发场景，让人头疼不已，别着急，本文带你逐步剖析获取连接慢的所有可能的原因，以及对应的调优手段，让你成为连接池排障大师。

二

连接池监控

华宇登录

对应应用程序比较敏感的时间就是获取连接耗时，因为它是同步的会直接影响链路的RT，下面我们就来逐步分析造成这个获取连接耗时较高的所有可能性以及解决方案。

三

排查思路

连接池存在等待连接

那么又有哪几种情况会导致存在等待连接数呢？

如果日常的活跃连接数/总连接比例持续很高，或者 QPS * AVG-RT(s) > 连接总数说明当前连接池的最大连接数已经不足以支撑当前的流量，如何解决？

慢 SQL 相对来说比较好排查，数据库或者数据库中间件都有成熟的慢 SQL 采集工具。只需要分析一下指定时间段内是否有慢 SQL 即可。 如果SQL 优化空间比较低，可以把慢 SQL 和核心业务分 2 个数据源，防止慢 SQL 影响正常核心业务。

长事务是很容易忽略的一种 case，可以通过观测连接使用时间指标和 SQL 耗时来分析，如果连接使用平均耗时远大于 SQL 平均耗时，那么说明有长事务。还可以根据 HikariCP 自带的连接泄露检测来分析，当连接被借出后长时间未归还（超过配置的阈值 leak-detection-threshold=30000）会打印借出时的堆栈，可以帮助我们快速定位。

还可以通过 RDS 的 SQL 洞察来分析是否有长事务，如果使用 华宇登录 Spring+JDBC 管理事务的情况下，开启事务的命令是 ，提交事务是 ，这里根据数据库线程 ID 来逐个分析，提交事务的时间-开启事务的时间=事务持续时间。

应用负载过高

在 CPU 繁忙时，执行完网络 IO 后等待获取 CPU 时间片的时间较长，最终表现的结果就是获取连接时间拉长。这种 case 的分析手段比较简单，直接通过观测应用的 CPU 和 Load 指标即可。

应用STW

华宇登录

网络阻塞

这是最常见的一种情况，一般我们可以通过观测应用所在主机的 TCP 重传监控是否有尖刺，但这里要注意下，TCP 重传不代表一定是网络抖动，也可能是网络带宽打满或者数据库 &DAL 异常。

除了监控还可以通过网络循环抓包来分析（主要磁盘容量不要保留太多文件），可以参考以下命令。

抓取 3306 端口的网络包，存储到 3306.pcap 文件中，-C 50 -W 10 代表一个文件最大 50M，最多保留 10 个 tcpdump -i eth0 port 3306 -w 3306.pcap -C 50 -W 10。

然后导入到 WireShark 工具中分析，重点关注 TCP Retransmission 即 TCP 重传。

如机器带宽打满，具体表现也是 TCP 重传，这里可以观测机器的带宽监控和机器支持的最大带宽做对比，看看是否超过限制。

数据库&数据库中间件异常

如果数据库中间件本身没有异常，可以继续下钻到 RDS。

重点观测 CPU内存利用率 & IOPS 使用率，也可以框选指定时间段进行自动诊断。

四

总结

本文列举了几乎所有可能导致连接池获取连接慢的 case，相信看完的读者以后再遇到此类问题时，再也不会一头雾水了。学会自助排查，不光可以提升自己的排障能力，同时也能减轻各位中间件 &DBA 小伙伴的客服压力。

参考文档：