一次性讲清楚「连接池获取连接慢」的所有原因( 二 ) _连接池

JVM 监控存在 Allocation Stall（垃圾回收阻塞，会暂停线程）或者暂停时间较长。

文章插图
图片

GC 日志相对于监控会更为准确一点，把日志文件直接丢到 https://gceasy.ycrash.cn/ 里面分析一下即可，会输出详细的报告，重点关注一下 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 重传，这里可以观测机器的带宽监控和机器支持的最大带宽做对比，看看是否超过限制。

文章插图
图片
数据库&数据库中间件异常当数据库或者数据库中间件出现异常时，对于上游应用的表现大多数就是 SQL RT 增高、TCP 重传。如果怀疑是数据库或者数据库中间件出现异常，可以先确定自己的应用连的是哪个库，这里可以通过应用监控（上下游 -RDS）直观的看到应用连接的具体的库信息，然后再观测对应 RDS 和数据库中间件的监控进一步分析。

文章插图
图片

如果是数据库中间件域名，就可以看数据库中间件的监控大盘。

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

文章插图
图片

如果是 RM/RR 开头的，说明连的是 RDS，可以看阿里云的 RDS 监控，把下面的 Rdsid 替换一下即可。

https://rdsnext.console.aliyun.com/detAIl/{替换成rdsId}/performance?reginotallow=cn-hangzhou&DedicatedHostGroupId=重点观测 CPU内存利用率 & IOPS 使用率，也可以框选指定时间段进行自动诊断。

文章插图
图片
四、总结本文列举了几乎所有可能导致连接池获取连接慢的 case，相信看完的读者以后再遇到此类问题时，再也不会一头雾水了。学会自助排查，不光可以提升自己的排障能力，同时也能减轻各位中间件 &DBA 小伙伴的客服压力。
参考文档：https://Github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

【一次性讲清楚「连接池获取连接慢」的所有原因】