应用连接数据库基本上都是通过连接池去连接，比如常用的 HikariCP、Druid 等，在应用运行期间经常会出现获取连接很慢的场景，大多数同学都是一头雾水，不知道从哪下手。而且很多时候都是偶发场景，让人头疼不已，别着急，本文带你逐步剖析获取连接慢的所有可能的原因，以及对应的调优手段，让你成为连接池排障大师。
排查问题的前提是发现问题，所以首先需要有连接池的详细监控，下面我们以 HikariCP 为例，简单介绍几个常用的指标的含义。
图片
图片
图片
对应应用程序比较敏感的时间就是获取连接耗时，因为它是同步的会直接影响链路的RT，下面我们就来逐步分析造成这个获取连接耗时较高的所有可能性以及解决方案。
获取连接耗时较高最直接的原因就是存在等待连接数，这种情况直接观测等待连接数的大盘即可
图片
那么又有哪几种情况会导致存在等待连接数呢？
如果日常的活跃连接数/总连接比例持续很高，或者 QPS * AVG-RT(s) > 连接总数说明当前连接池的最大连接数已经不足以支撑当前的流量，如何解决？
适当增加连接池最大连接数：连接数也不是越大越好，一般是根据 CPU 核数决定，HikariCP 官方给出了一个公式可以做一下参考，最大连接数一般不要超过 50。
core_count 为core的数量 effective_spindle_count 为挂载的磁盘数量。core_count 为core的数量 effective_spindle_count 为挂载的磁盘数量。慢 SQL 相对来说比较好排查，数据库或者数据库中间件都有成熟的慢 SQL 采集工具。只需要分析一下指定时间段内是否有慢 SQL 即可。 如果SQL 优化空间比较低，可以把慢 SQL 和核心业务分 2 个数据源，防止慢 SQL 影响正常核心业务。
长事务是很容易忽略的一种 case，可以通过观测连接使用时间指标和 SQL 耗时来分析，如果连接使用平均耗时远大于 SQL 平均耗时，那么说明有长事务。还可以根据 HikariCP 自带的连接泄露检测来分析，当连接被借出后长时间未归还（超过配置的阈值 leak-detection-threshold=30000）会打印借出时的堆栈，可以帮助我们快速定位。
图片
还可以通过 RDS 的 SQL 洞察来分析是否有长事务，如果使用 Spring+JDBC 管理事务的情况下，开启事务的命令是 SET autocommit=0，提交事务是 commit，这里根据数据库线程 ID 来逐个分析，提交事务的时间-开启事务的时间=事务持续时间。
应用负载过高
由于 HikariCP、Druid 在从连接池借出连接时，会有一个同步探活的操作，比如直接 MySQL 的 PING 命令或执行 select 'X' 等，因为有网络 IO，所以这里会让当前线程进入阻塞状态让出 CPU 时间片。
图片
在 CPU 繁忙时，执行完网络 IO 后等待获取 CPU 时间片的时间较长，最终表现的结果就是获取连接时间拉长。这种 case 的分析手段比较简单，直接通过观测应用的 CPU 和 Load 指标即可。
在获取连接方法开始到结束期间，如果应用发生了 STW，就会导致获取连接耗时升高，需要结合 JVM 监控 &GC 日志来分析，关于 GC 分析不是本文重点，这里简单列举几个重点说明一下（以 ZGC 举例）。
图片
图片
图片
图片
这一类问题比较难以排查，具有偶发性和难以观测的特点，网络阻塞也分好几种情况。
这是最常见的一种情况，一般我们可以通过观测应用所在主机的 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。
图片
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
本文链接：http://www.28at.com/showinfo-26-38133-0.html一次性讲清楚「连接池获取连接慢」的所有原因｜
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
下一篇： C 语言变长参数及其陷阱
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号