记一次tomcat进程cpu占用过高的问题排查记录

记一次tomcat进程cpu占用过高的问题排查记录

详细介绍了tomcat进程cpu占用过多这一难题的记录。原文根据示例代码非常详细，对大家的学习培训或者工作都有一定的参考价值。有必要的朋友陪我去了解一下。

本文记录了一个tomcat进程，由于TCP连接过多，CPU占用了过多的故障排除记录。

难题叙述

在linux系统软件下，一个tomcatweb服务的cpu利用率非常高，最上面显示的信息结果超过200%。请求无法得到答复。重启后还是一样的情况。

疑难解答

1。获取进程信息

根据jdk提供的jps指令，可以快速找到jvm进程，

jpspid

2.查询jstack信息

jstackpid

发现有很多log4j线程块，处于等待锁的情况。

org.Apache.log4j.category.callappenders(org.Apache.log4j.SPI.loggingevent)@BCI=12，line=201(编译帧)

搜索资料发现log4j版本号有死锁问题。

发现了问题，于是调整log4j设备，只打开错误级别日志，重启tomcat。此时堆栈中的块线程退去，但进程的cpu利用率依然上升。

3。进一步调查

要分析每个线程的cpu使用情况，这里必须导入一个master做的脚本，来测量java进程中每个线程的cpu使用情况。

#!/bin/bash typesettop=${1:-10} typesetpid=${2:-$(pgrep-u$USERjava)} typesettmp_file=/tmp/java_${pid}_$$.trace $JAVA_HOME/bin/jstack$pid>$tmp_file psH-eouser,pid,ppid,tid,time,%cpu--sort=%cpu--no-headers\ |tail-$top\ |awk-v"pid=$pid"'$2==pid{print$4"\t"$6}'\ |whilereadline; do typesetnid=$(echo"$line"|awk'{printf("0x%x",$1)}') typesetcpu=$(echo"$line"|awk'{print$2}') awk-v"cpu=$cpu"'/nid='"$nid"'/,/^$/{print$0"\t"(isF?"":"cpu="cpu"%");}'$tmp_file done rm-f$tmp_file

脚本应用领域

由于ps中的%CPU数据分析来自/proc/stat，这个数据信息不是瞬间的，只是在OS升级的频率上，一般1S。所以你看到的数据分析会和jstack发来的信息不一致，这就是为什么~但是这个信息对于少数线程导致的问题的排查还是很周到的。因为这个固定数量的线程会持续消耗CPU资源，即使有时间差，总之都是这许多线程造成的。

除了这个脚本制作，更简单的方法是找出进程id，按照下面的说明查询进程中每个线程的资源申请状态

top-H-ppid

从这里获取pid(线程id)，转换成十六进制，然后到堆栈信息中搜索目标的线程信息。

根据该方法发现，tomcat进程匹配的线程的cpu利用率的累计总和约为80%，远低于top得出的200%。

说明不会有线程长时间占用cpu，但应该归因于很多临时的cpu聚合计算。所以经常会引起gc怀疑jvm是否内存不足。

jstat-gcpid

发现jvm在运行内存应用，但依然没有异常，gc频率大幅飙升。

检查运行内存，因为是互联网程序进程，进一步检查数据连接。

4。难题的准确定位

查看tomcat匹配端口号的tcp链接，发现EASTABLISH的连接很多，其他情况的也有一些，一共400个。

netstat-anp|grepport

对这个连接的进一步询问，来自于它是tomcat服务项目的应用端，后台管理线程很多，经常轮询服务项目，导致服务项目的tomcat线程数太满，无法再次接受请求。

netstat的情况表明:

监听:从远处监听TCP端口的连接需求。

SYN-SENT:再次推送连接请求，然后等待匹配的连接请求(如果有很多这样的情况，检查一下有没有什么窍门)

SYN-RECEIVED:接收并推送另一个连接请求后，等待对方确认连接请求(如果这种情况很多，可能会泛滥***)

ESTABLISHED:表示开放连接。

FIN-WAIT-1:等待远程控制TCP连接中断请求或先前连接中断请求的确定。

FIN-WAIT-2:等待远程控制TCP的连接中断请求

CLOSE-WAIT:等待来自用户帐户的连接中断请求。

关闭:等待远程控制TCP确定连接终止。

LAST-ACK:等待发送给远程控制TCP的原连接中断请求的确认(不是好产品，出现此项，检查是否***)

TIME-WAIT:等待足够的时间，确保远程控制TCP接受连接中断请求的确认。

关闭:没有连接。

5。根本原因分析

立即启动的原因是手机客户端轮询，要求有异常，再次开启序列；手机不断有新的后台管理线程加入轮询团队，最后服务器端的tomcat连接满了。

至此，关于记录tomcat进程中cpu占用率过高问题的故障排除记录的这篇文章已经详细介绍过了。关于tomcat进程中cpu占用率过高的大量信息，请搜索您以前的文章或再次访问下面的相关文章。期待你以后的申请！