DBCP连接池问题分析

背景

         生产环境,运维人员核对实时账单和累帐信息,发现有部分用户数据不一致;

问题描述

消费者日志报生产者线程池满

图1

生产者堆栈信息部分如下:

图2

问题分析

  1. 数据不一致产生原因:

累帐表数据是消费者SumCharge服务更新,更新完成后调用生产者AccountProcess服务,由于生产者服务处理慢导致返回超时,更新实时账单表失败;

  1. 生产者AccountProcess服务处理慢原因:

分析AccountProcess堆栈信息发下,100个线程中正常处理的有8个,其他92个线程都在等待获取数据库连接getConnection,因此真正在进行任务处理的线程只有8个

  1. 查看dbcp线程池配置

配置文件中并没有对线程池进行配置,因此使用的是默认值

maxActive: 链接池中最大连接数,默认为8.

验证

Dbcp=默认值

查看堆栈信息发现在处理数据的只有10个线程,其中2个线程在写日志

maxActive=32

将dbcp线程池设置为32后,堆栈信息如下,其中在处理数据的线程数有37个

修改配置

#连接池初始化大小

<property name="initialSize" value="8" />

#连接池中最大连接数,默认为8

<property name="maxActive" value="32" />

#当连接池资源耗尽时,调用者最大阻塞的时间,超时将跑出异常。单位,毫秒数;默认为-1.表示永不超时.

<property name="maxWait" value="5000" />

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值