问题四:数据库连接池不释放
搭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,查看案例。