问题描述
在工作中经常遇到Tomcat占用CPU居高不下,top显示结果超过200%,请求无法响应,针对这种情况有以下处理办法进行排查。请求无法响应。
问题排查
1、获取进程信息
通过jdk提供的jps命令可以快速查出jvm进程
jps pid
2、查看jstack信息
jstack pid
3、将十进制pid转换为16进制
将十进制转换成16进制
# printf “%xn” 19713–>将第2步查到占用较高CPU的线程号转换为16进制,以便于jstack查看
4d01
#jstack pid | grep 0x4d01–> 0x4d01为第3步19713转换为16进制后的数字,因为jstack显示的线程号是以16进制表示的!
将16进制转换成十进制
# printf “%dn” 0x4d19
jstack的作用是显示正在运行的所有Java线程情况,jstack pid | grep 0x4d01的意思只显示某个java线程的运行信息。通过这种方法,可以将此线程正在运行的方法显示出来,将此方法交给开发即可。(也可能jstack pid | grep 0x4d01什么都没有出来的)
4、打印线程的堆栈信息
jstack pid | grep tid -A 30
此处不一一列表各tid的堆栈信息了,在其中一个的tid堆栈信息中找到了问题的原因
5、进一步排查,分析每个线程的cpu占用量
简单点儿的方法则是,查出进程id后,通过如下命令查看该进程中每个线程的资源使用情况
top -H -p pid -H用于显示某个进程的所有线程
从这里获取pid(线程id),转换为16进制,然后去stack信息中查找对象的线程信息。
通过上述方法,查出tomcat进程对应的线程cpu占用率累积之和约80%,远小于top给出的200%+
说明并不存在长期占用cpu的线程,应该是属于有许多短暂性的cpu密集计算。进而怀疑是不是jvm内存不足,频繁gc导致。
jstat -gc pid
发现jvm内存使用并未出现异常,gc次数明显暴涨
查完内存,由于本身是一个网络程序,进一步排查网络连接。
6、问题定位
查询tomcat对应端口的tcp链接,查看是否存在大量EASTABLISH的链接,或还有部分其它状态的连接。
netstat -anlp | grep port
netstat状态说明:
LISTEN:侦听来自远方的TCP端口的连接请求
SYN-SENT:再发送连接请求后等待匹配的连接请求(如果有大量这样的状态包,检查是否中招了)
SYN-RECEIVED:再收到和发送一个连接请求后等待对方对连接请求的确认(如有大量此状态,估计被flood***了)
ESTABLISHED:代表一个打开的连接
FIN-WAIT-1:等待远程TCP连接中断请求,或先前的连接中断请求的确认
FIN-WAIT-2:从远程TCP等待连接中断请求
CLOSE-WAIT:等待从本地用户发来的连接中断请求
CLOSING:等待远程TCP对连接中断的确认
LAST-ACK:等待原来的发向远程TCP的连接中断请求的确认(不是什么好东西,此项出现,检查是否被***)
TIME-WAIT:等待足够的时间以确保远程TCP接收到连接中断请求的确认
CLOSED:没有任何连接状态
解除Tomcat中POST方式上传文件的大小限制
当服务器是Tomcat时,通过POST上传的文件大小的最大值为2M(2097152)。
如果想修改该限制,修改方法如下:
tomcat目录下的conf文件夹下,server.xml 文件中以下的位置中添加maxPostSize参数
<Connector port=”8081″
maxThreads=”150″ minSpareThreads=”25″ maxSpareThreads=”75″
enableLookups=”false” redirectPort=”8443″ acceptCount=”100″
debug=”0″ connectionTimeout=”20000″
disableUploadTimeout=”true” URIEncoding=”GBK”
maxPostSize=”-1″/>
注意:maxPostSize参数只有当request的Content-Type为“application/x-www-form-urlencoded”时起作用。
从 apache-tomcat-7.0.63 开始,参数 maxPostSize 的含义就变了: 如果将值设置为 0,表示 POST 最大值为 0,不限制 POST 大小需要将值设置为 -1。,在此版本之前设置为 0 表示不限制 POST 大小。