问题四:数据库连接池不释放
搭e6mall需要使用tomcat7搭建。
过程:压测一个商品的详情页请求,看看报错如何?按照上面方法分析
1、先访问tomcat的初始页面,可以访问,这说明:tomcat负载机、网络、tomcat连接池,tcp/ip没有问题。
2、接下来看 cpu ,top:没问题。
]# top
top - 18:54:44 up 8 days, 6:55, 3 users, load average: 0.00, 0.00, 0.00
Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2054084k total, 1817816k used, 236268k free, 186872k buffers
Swap: 0k total, 0k used, 0k free, 833836k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1178 root 10 -10 123m 9.9m 5456 S 0.3 0.5 47:35.04 AliYunDun
1884 root 20 0 221m 9.9m 5064 S 0.3 0.5 2:29.35 docker
9136 root 20 0 2587m 316m 16m S 0.3 15.8 0:41.86 java
3、线程栈以及 jvm 都没问题,问题在哪?
4、我们看下数据库连接池,发现连接池很多被 e6mall 占用,但是 sleep 了,我们可以看到有 30 个连接池被占用了(ip和db都要符合规则)。
数据库连接池:
1、数据库本身对外提供的连接池的最大数(数据库配置文件里的)
2、应用程序配置的客户端和服务器建立的连接数(项目里配置的)
数据库连接池不释放,【数据库连接一般用完立即释放,配置90个连接就算很高了,单机配四五十就算挺高了】
开始配置30个连接,都被用掉了,后来改为90也被用完了,所以这里是数据库连接池不释放导致的问题。
之前我们有提到过,数据库连接池除了在数据库内部设置最大连接数,在程序内也有,我们的数据库最大连接数查询命令为:show variables like '%max_connections%';并且可以查到,是 151 个。接下来我们去程序中查看数据库的属性连接。
我们的最大连接数一般是在配置文件内,去 e6mall 内查看 jdbc.properties:(xxx为我的 ip)
jdbc.driverClassName=com.mysql.jdbc.Driver
jdbc.url=jdbc\:mysql\://xx.xxx.xxx.xxx\:3306/e6mall?useUnicode\=true&characterEncoding\=utf-8&autoReconnect\=true&zeroDateTimeBehavior\=round
jdbc.username=root
jdbc.password=123456
可以看到只有基础的属性配置,但是没有详细的连接配置,我们的 dangdang 是有的,那么这里在哪配的呢?
e6mall/WEB-INF/classes/applicationContext.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>classpath:jdbc.properties</value>
</list>
</property>
</bean>
<bean id="velocityEngine" class="org.springframework.ui.velocity.VelocityEngineFactoryBean">
<property name="velocityProperties">
<props>
<prop key="resource.loader">class</prop>
<prop key="class.resource.loader.class">
org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
</prop>
<prop key="velocimacro.library"></prop>
</props>
</property>
</bean>
<bean id="dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource">
<property name="driverClass" value="${jdbc.driverClassName}" />
<property name="jdbcUrl" value="${jdbc.url}" />
<property name="user" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
<!--连接池中保留的最小连接数。 -->
<property name="minPoolSize">
<value>5</value>
</property>
<!--连接池中保留的最大连接数。Default: 15 -->
<property name="maxPoolSize">
<value>30</value>
</property>
<!--初始化时获取的连接数,取值应在minPoolSize与maxPoolSize之间。Default: 3 -->
<property name="initialPoolSize">
<value>10</value>
</property>
<!--最大空闲时间,60秒内未使用则连接被丢弃。若为0则永不丢弃。Default: 0 -->
<property name="maxIdleTime">
<value>60</value>
</property>
<!--当连接池中的连接耗尽的时候c3p0一次同时获取的连接数。Default: 3 -->
<property name="acquireIncrement">
<value>5</value>
</property>
<!-- JDBC的标准参数,用以控制数据源内加载的PreparedStatements数量。但由于预缓存的statements 属于单个connection而不是整个连接池。所以设置这个参数需要考虑到多方面的因素。
如果maxStatements与maxStatementsPerConnection均为0,则缓存被关闭。Default: 0 -->
<property name="maxStatements">
<value>0</value>
</property>
<!--每60秒检查所有连接池中的空闲连接。Default: 0 -->
<property name="idleConnectionTestPeriod">
<value>60</value>
</property>
<!--定义在从数据库获取新连接失败后重复尝试的次数。Default: 30 -->
<property name="acquireRetryAttempts">
<value>30</value>
</property>
<!-- 获取连接失败将会引起所有等待连接池来获取连接的线程抛出异常。但是数据源仍有效 保留,并在下次调用getConnection()的时候继续尝试获取连接。如果设为true,那么在尝试
获取连接失败后该数据源将申明已断开并永久关闭。Default: false -->
<property name="breakAfterAcquireFailure">
<value>false</value>
</property>
<!-- 因性能消耗大请只在需要的时候使用它。如果设为true那么在每个connection提交的 时候都将校验其有效性。建议使用idleConnectionTestPeriod或automaticTestTable
等方法来提升连接测试的性能。Default: false -->
<property name="testConnectionOnCheckout">
<value>false</value>
</property>
</bean>
说明最大连接数我配了 30 ,就连上了 30 ,初步判断是数据库连接池不释放,那么怎么验证?我们把 30 改成 120 再压测,如果数据库连接池又被占满了,则可以判断是连接池不释放导致的。
果然,120个又被占满,说明是数据库连接池不释放导致的问题
总结
根据问题现象,去定位问题。具体方式是根据我们的架构拓扑图去排查,有些是经验推断,以及日志内的分析去定位大致范围。还有比较重要的能定位问题的:日志内的埋点的时间信息。在日志内打印接口的调用时间。如果响应时间长,在日志内打出来接口的调用时间,再减去数据库内发生的时间,就是接受请求之前所花费的时间。
还有超时问题,503问题,响应超时,web容器处理慢,数据库超时; 502:超时,大叔总结。
以及频繁gc的问题。
性能监控和企业分析的ppt,查看案例。