1、数据库连接池爆满,cpu使用率100%,几分钟之后池就满了
采取方案:将数据库与应用程序分离,使用阿里的RDS云数据库
2、有所缓解,但是RDS的cpu以及连接数只增不降
采取方案:数据库连接池没有来得及空闲回收,因为存在连接泄露问题,
找出泄漏源以及更改数据源配置;以及数据库操作台频繁,因为业务里面
所有的操作日志都是入库操作,所以对这块进行优化
3、RDS数据库性能趋于稳定,但是tomcat连接数爆满
大量TCP连接,没有关闭socket以及流操作之类的。
目前在线人数可以达到7000人左右
Tomcat Connector的三种不同的运行模式性能相差很大,有人测试过的结果如下:
这三种模式的不同之处如下:
一个线程处理一个请求。缺点:并发量高时,线程数较多,浪费资源。
Tomcat7或以下,在Linux系统中默认使用这种方式。
利用Java的异步IO处理,可以通过少量的线程处理大量的请求。
Tomcat8在Linux系统中默认使用这种方式。
Tomcat7必须修改Connector配置来启动:
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000" redirectPort="8443"/>
即
Apache Portable Runtime,从操作系统层面解决
io
阻塞问题。
Tomcat7或Tomcat8在Win7或以上的系统中启动默认使用这种方式。
Linux如果安装了apr和native,Tomcat直接启动就支持apr。(安装方法:http://my.oschina.net/lsw90/blog/181161
)
官方对这三种的区别的详细说明:
Java Blocking Connector Java Nio Blocking Connector APR/native Connector
BIO NIO APR
Classname AjpProtocol AjpNioProtocol AjpAprProtocol
Tomcat Version 3.x onwards 7.x onwards 5.5.x onwards
Support Polling NO YES YES
Polling Size N/A maxConnections maxConnections
Read Request Headers Blocking Sim Blocking Blocking
Read Request Body Blocking Sim Blocking Blocking
Write Response Blocking Sim Blocking Blocking
Wait for next Request Blocking Non Blocking Non Blocking
Max Connections maxConnections maxConnections maxConnections
Tomcat启动的时候,可以通过log看到Connector使用的是哪一种运行模式:
- Starting ProtocolHandler ["http-bio-8080"]
- Starting ProtocolHandler ["http-nio-8080"]
- Starting ProtocolHandler ["http-apr-8080"]
maxConnections
根据字面意思觉得就应该是这个了。
去验证吧,
!
最大连接数为10,我们启动30个长连接,
预期应该是只有10个长连接,实际结果却是远超过10个。这个有点不应该啊。
实验验证
原来还有个参数可以觉得连接数的大小
maxThreads:tomcat起动的最大线程数,即同时处理的任务个数,默认值为200
acceptCount:当tomcat起动的线程数达到最大时,接受排队的请求个数,默认值为100
这两个值如何起作用,请看下面三种情况
情况1:接受一个请求,此时tomcat起动的线程数没有到达maxThreads,tomcat会起动一个线程来处理此请求。
情况2:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,tomcat会把此请求放入等待队列,等待空闲线程。
情况3:接受一个请求,此时tomcat起动的线程数已经到达maxThreads,等待队列中的请求个数也达到了acceptCount,此时tomcat会直接拒绝此次请求,返回connection refused
同时加上maxConnections
原来tomcat最大连接数取决于maxConnections这个值加上acceptCount这个值,在连接数达到了maxConenctions之后,tomcat仍会保持住连接,但是不处理,等待其它请求处理完毕之后才会处理这个请求。