调整2-调整配置,数据库连接池数量
mysql默认最大连接数是100
关闭程序和mysqld
修改mysql配置文件/etc/my.cnf
在[mysqld]下增加
max_connections=400 |
修改项目中jdbc.c3p0.properties配置文件,将127.0.0.1改成localhost,不受网卡限制.mysql对localhost也做了相应的处理措施-(http://wenku.baidu.com/link?url=Ju_Ap7u8hOkPSPXgAWAGMnyWN7JwBeU4HUOvWma-OnOCYD89LpJkCmZWXKJmnfgKkq_gW38U83wXGQOxFYbKAEmiayClqSilX3KZxDFVGZq)
jdbc.jdbcUrl=jdbc:mysql://localhost:3306/story?useUnicode=true&characterEncoding=UTF-8
jdbc.miniPoolSize=100
jdbc.maxPoolSize=380
jdbc.initialPoolSize=100
jdbc.maxIdleTime = 120000
jdbc.acquireIncrement=20
jdbc.acquireRetryAttempts = 45
jdbc.acquireRetryDelay=120000
jdbc.testConnectionOnCheckin = true
jdbc.automaticTestTable = test
jdbc.idleConnectionTestPeriod = 30000
jdbc.checkoutTimeout=65000
先行发起1200并发尝试,成功率,略有好转
走势图
吞吐量报告
将参数略加修改,再次尝试
my.cnf
max_connections=600
程序连接池
jdbc.miniPoolSize=200
jdbc.maxPoolSize=580
jdbc.initialPoolSize=200
jdbc.maxIdleTime = 120000
jdbc.acquireIncrement=38
jdbc.acquireRetryAttempts = 50
预热后,压1200并发
走势图
报告
虽然吞吐量上升了,但是错误率也在上升。Top查看,看多时候操作系统在wait消耗比重比较大。
调整3-日志的输出配置
使用iostat工具查看io负载率
iostat -x -d 3
再压,发现iostat的util%占用率较高。
将项目日志级别配置文件调整
## LOGGERS ##
#define a logger
#log4j.rootLogger=DEBUG,console,file
log4j.rootLogger=ERROR,console,file
log4j.appender.console=org.apache.log4j.ConsoleAppender
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.File=../logs/story_log.log
log4j.appender.file.MaxFileSize=1504800KB
log4j.appender.file.MaxBackupIndex=10
log4j.appender.file.BufferedIO=true
log4j.appender.A3.BufferSize=100960
1200并发测试,iostat探测结果,util%虽然有所下降,可是压力结果并未改善,看来不是写日志造成的IO瓶颈。异常反映出依然是http连接超时
继续调大mysql的连接池数量,使其到达1500。调整程序的连接池,使其到达1200,(剩余的连接用于mysql监控workbench使用)。
创建的池对象(数据库线程池、程序连接池)差不多已到该机器极限。
调整4-Tomcat连接方式
将Tomcat的连接方式由默认的BIO改为linux下的NIO(epoll)。
server.xml,并且调大连接超时时间
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="45000"
redirectPort="8443"/>
再修改catalina.sh的内容头加上oracle jdk在linux平台对epoll实现支持
CATALINA_OPTS='-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider'
依然以1200并发开始作为基数测试。
预热稳定后走势图
报告
TPS维持在22~25之间。
观察top情况,us%占用较大,怀疑tomcat的JVM或者是Java代码遇到了瓶颈。
记录:第15页,调整5-Tomcat的启动JVM参数之前