bladex系统宕机问题跟踪与解决

Blade 未结 2 1954
xcuni-wang
xcuni-wang 剑童 2021-04-07 18:24

/**************************转自同事的技术博客*************************/

一、该问题的重现步骤是什么?

1.现象:高并发场景(均是和疫情相关:电子通行证上线第一天、外来人口摸排登记上线第一天)下系统崩溃假死,其中摸排登记系统上线第一天2-3小时内PV达到了近80万,QPS尚未进行测算统计,理论上并不会太高。


2.出现的日志特征:

3.继续跟踪:

项目采用了docker部署模式,


通过docker exec -it container_name /bin/bash 命令进入容器,


采用jps命令查找java进程id,docker中是1,


采用top -Hp 1命令查看对应的资源占用情况,


采用jstack 1 > jstack.log命令将堆栈信息导出到文件jstack.log中。


二、问题锁定

发现,该系统中集成了druid 数据库连接池框架,而卡死的原因也正是druid中获取数据库连接一直处于等待状态引起的。

跟踪druid源码找到线程阻塞的位置:

再继续向上跟踪,找到getConnectionInternal方法(private DruidPooledConnection getConnectionInternal(long maxWait)throwsSQLException):

通过maxWatit参数来判定是否走takeLast流程,而maxWatit的值始终是默认值-1,而不是application.yml配置文件中的60000。


那么,问题来了,application.yml配置文件中所有关于druid的配置(在spring.datasource.druid中配置)参数都没有生效。


三、问题解决

修改application.yml druid配置

image.png

四、修改配置后的效果

经过以上调整(1-调整druid参数配置位置,放置于动态数据源节点下;2-升级druid-spring-boot-starter版本至1.2.1及以上),同样的环境原本压测只能压到100左右的系统,目前可以抗到2000以上(受限于压测工具的客户端,尚未测试出极限值)。

2条回答
  • 2021-04-07 18:42

    点赞,666

    2 讨论(0)
  • 2021-04-08 12:53

    补充说明下:

     1. 之前遇到的问题是因为开启了动态数据源,而原先的druid配置是在外层,动态数据源无法读取也就使用了默认的配置。

     2. 将druid的配置转移到dynamic节点下之后,动态数据源就能读取到真正的druid配置,性能也就一起提高了

    1 讨论(0)
提交回复