系统卡顿及数据库连接异常排查思路

[qq_34106886]

是不是遇到到过下面这种情况，日志显示“Unable to acquire JDBC Connection”，系统异常的卡顿，点击无响应？下面教你如何排查，如何解决！

 

排查步骤

1.检查数据库状态，确保数据库服务正在运行且可以接受连接。

2.检查网络状态，确保应用服务能够连接到数据库，并使用Ping命令查看与数据库服务器的连接状态，看看是否延时过高

3.登录系统，访问系统，查看是否所有请求都报连接超时

4.如果都超时，此时应用服务已经停止工作，可以先联系用户，暂停一切操作，等待一段时间看连接是否能够自动释放。

5.打开leanpec_prod.log查看连接池使用情况，例子如下：

type=GAUGE, name=pool.ActiveConnections, value=0
type=GAUGE, name=pool.IdleConnections, value=10 
type=GAUGE, name=pool.MaxConnections, value=10
type=GAUGE, name=pool.MinConnections, value=10
type=GAUGE, name=pool.PendingConnections, value=0
type=GAUGE, name=pool.TotalConnections, value=10
type=HISTOGRAM, name=pool.ConnectionCreation, count=9, min=37, max=140, mean=49.0, stddev=32.176596049509854, median=38.0, p75=38.0, p95=140.0, p98=140.0, p99=140.0, p999=140.0
type=HISTOGRAM, name=pool.Usage, count=9, min=0, max=35, mean=10.252065332792702, stddev=12.783619388871982, median=3.0, p75=8.0, p95=35.0, p98=35.0, p99=35.0, p999=35.0
type=METER, name=pool.ConnectionTimeoutRate, count=0, mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second
type=TIMER, name=pool.Wait, count=9, min=0.0049, max=0.198, mean=0.03560730725613549, stddev=0.058963184221449014, median=0.0106, p75=0.0173, p95=0.198, p98=0.198, p99=0.198, p999=0.198, mean_rate=0.3060659392132232, m1=1.289756359032821, m5=1.683912573056912, m15=1.7604411704722809, rate_unit=events/second, duration_unit=milliseconds

具体参数说明请看表1和表2

 

6.如果连接池一直得不到释放，就要考虑重启服务了，但会中断正在执行的事物，严重的话会丢失数据或数据错乱，还请慎重考虑。

7.调整连接池参数，比如增加最大连接数，添加connection-timeout参数（连接超时时间，单位为毫秒）重启服务，再持续观察

8.如果调整过后依旧出现此问题，那么需要继续排查系统日志，本地部署的运行时会打印逻辑、模型方法执行的时间以及对应的ID，请仔细排查是否有执行异常的逻辑，并定位分析。

打印例子和说明如下

=== Script starts executing === （一次逻辑调用开始）
- Action ID： dfd152ee-893e-4e38-8950-e93e03531b44 .（逻辑的ID）
- Run script time: 72 milliseconds. （逻辑执行时长，中间可能会出现多次，表示这个逻辑有嵌套执行，也就是内部调用了其他逻辑方法）
- Model Function ID: 009164c3-4ce4-47aa-88f9-e182fc5f194d .（模型方法的ID）
- Model Function Running time: 112 milliseconds. （模型方法执行时间）
=== Total script execution time: 186milliseconds. ===（这次逻辑执行的总时长）

 

9.如果报连接超时的异常穿插在逻辑执行里面，或者一次逻辑调用嵌套多个逻辑，导致执行时间过长，那么就要考虑优化逻辑代码块了，这里列几个优化思路

1. 正常来说不应在循环里面操作数据库，这样会频繁创建数据库连接导致连接池的溢出，例如循环插入，循环查询，这也是最可能导致异常的情况之一，可以考虑优化为批量操作
2. 慢查询sql，如果一个sql执行超过5秒，理论上就要考虑优化了，可以创建索引，或者优化sql
3. 业务优化，将一个大业务拆成多个小业务，公共的业务提取出来，避免重复造轮子，也避免在一个大事物下执行过多的数据库操作

 

 

表1（输出指标说明）

指标	解释	说明
ActiveConnections	活跃连接数	此数据长期保持最大连接数值的时候可以尝试扩大连接数
IdleConnections	空闲连接数	此数据过高的时候可以尝试减少配置中的最小连接数
MaxConnections	配置的最大连接数
MinConnections	配置的最小连接数
PendingConnections	排队等待连接的线程数	如果此数据持续飙高，表示连接池中已经没有空闲线程了
TotalConnections	当前总连接数
ConnectionCreation	创建新连接的耗时	此数据主要反应当前服务到数据服务的网络延迟
ConnectionTimeoutRate	创建新连接的超时	如果经常创建连接超时这个时候需要排查数据服务或者网络通讯是否异常
Usage	连接被复用时长	此参数表示连接池中一个连接从返回连接池到再次被复用的时间间隔，表示数据访问频繁程度，对于使用较长的间隔可以尝试减少连接数
Wait	获取连接的等待耗时	可以和PendingConnections结合分析连接池情况。

 

 

Wait和PendingConnections结合分析连接池情况

 

如果排队多等待短：此时表示数据访问频繁可以尝试扩大连接数；

 

如果排队少等待长：此时连接中存在慢查询或者比较大的事务；

 

如果排队多等待长：此时可能是数据访问压力过大且存在大量慢查询，但实际上如果频繁出现慢查询很有可能是程序或者业务上出现了问题，需要对业务和代码进行排查。这种时刻也能网络出现异常导致所有查询都变得非常慢；

 

表 2（输出度量说明）

属性	解释
count	指标记录次数
min	最小记录数
min	最大记录数
mean	平均值
stddev	标准差
median	中位数
p75	75百分位数
p95-p999	对应数字的百分数位
mean_rate	平均耗时
m1	1分钟内记录平均数
m5	5分钟记录平均数
m15	15分钟记录平均数
duration_unit	统计单位
rate_unit	记录单位（events/second 为 事件次数/每秒钟）

 

接口限流&熔断

为了保障系统的可用性，目前调用逻辑接口设置了QPS为5，也就是一秒最多接受五个请求（限流），熔断规则为当单位统计时长（10s）内请求数目大于设置的最小请求数目(5)，并且异常的比例大于阈值(0.5)，则接下来的熔断时长（10s）内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态，若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断.

 

熔断时系统日志例子：

Fallback:  NullPointExcepetion  (逻辑出现异常时的报错)

BlockException： *** （流量超出限制报错）