
Linux服务器tomcat部署运行后cpu升到最高一直不降。 90
linux服务器部署tomcat启动过后访问页面导致java进程cup使用升到最高,持续不降,请问是什么原因我查找了项目内部debug.log输出:ClientAbort...
linux服务器部署tomcat启动过后访问页面导致java进程cup使用升到最高,持续不降,请问是什么原因我查找了项目内部debug.log输出:ClientAbortException: java.net.SocketException: Broken pipe,项目初部署时没有这种异常,最近刚部署后也不出现,但是过了段时间就出现这个问题,求各位大神解答。 linux -菜鸟
展开
展开全部
这个跟Linux没有任何关系。
是你的代码写的不好,重点检查以下几个方面:
有输入输出流操作的地方,资源是否正常释放;
有远程连接的地方,比如httpClient、Socket等,使用完是否正常关闭;
如果系统有开放接口,接口代码是否健壮,是否经的起大并发访问;是否会导致阻塞;出现异常后,异常处理机制是否健全;
追问
试过很多,在本地虚拟机上也经过测试无误,但是放在服务器上就出现间断性的这种cpu过高,tomcat进程僵死的问题,我也认为是代码内部问题, 还能帮我列举几个容易出错的地方么? 我做了过滤器,一直异常都是经过过滤器抛出的,但是检测过后,发现不能叫做异常,我使用spring定时机制,在spring加载的时候会经过过滤器。
追答
这个跟网络有关,连接中断后,用户使用的服务端资源无法正常释放,就会这样,最终使得CPU冲高,所以我建议你检查你的连接部分的代码,如果没有连接接口,检查一下异常处理的地方,当用户异常网络中断时,需要手动释放一下,否则服务器会一直等,等session过期,才会将资源标记为汪使用,然后虚拟机才能GC,但此时可能 为时已晚,很有可能时间长了服务器就趴了。
如果代码中弄不好这个问题,先检查一下网络环境,一定要保证稳定,而且还要有足够的吞吐量性能。

2024-12-20 广告
作为酷巴流体控制(苏州)有限公司的工作人员,对于缓冲器的安装有所了解。以电梯缓冲器为例,其安装步骤如下:首先,确定缓冲器中心位置,使其与轿厢撞板中心对准,偏移不得超过20mm。其次,用水平尺测量缓冲器顶面,确保其水平误差小于2‰。如果为双缓...
点击进入详情页
本回答由vip酷巴流体提供
展开全部
解决:
1.更改代码
2.改回相关文件目录的原有属性
两个坑:
代码的死循环不够严谨
坚决不应该以root身份启动有固定用户的进程(属于误操作,应谨慎)
其他思路:
1.查日志,其实能看到很多删除失败的记录,这个应该留意,才能更好找到原因
2.利用jstat分析jvm状态 , jstat -gcutil pid(vmid) 间隔(毫秒) 次数,如:
[root@service ~]# jstat -gcutil 14503 1000 4
S0 S1 E O P YGC YGCT FGC FGCT GCT
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
1.更改代码
2.改回相关文件目录的原有属性
两个坑:
代码的死循环不够严谨
坚决不应该以root身份启动有固定用户的进程(属于误操作,应谨慎)
其他思路:
1.查日志,其实能看到很多删除失败的记录,这个应该留意,才能更好找到原因
2.利用jstat分析jvm状态 , jstat -gcutil pid(vmid) 间隔(毫秒) 次数,如:
[root@service ~]# jstat -gcutil 14503 1000 4
S0 S1 E O P YGC YGCT FGC FGCT GCT
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
43.75 0.00 0.00 76.49 85.93 148 17.511 1 0.618 18.129
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
有可能是linux的线程机制会产生JVM出错的问题,特别是在连接高峰期间经常出现这样的问题,tomcat在linux下也出现类似情况。
解决办法是在环境变量中设置:_JAVA_SR_SIGNUM=12 基本就可以解决。
sun的解释:
--posted by: cooper
Below is a clipping from Sun on working around JVM crashes under high
thread counts in the JVM 1.3 for Linux
On Linux, use a larger signal number for hotspot thread
suspension/resumption handler. The signal number being used is
specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
number larger than SIGSEGV (11) will solve the problem. A good number
to use is 12, which is SIGUSR2. Using signal 16 to work around the
problem might have potential problems. So on tcsh, "setenv
_JAVA_SR_SIGNUM 12" can solve the problem.
解决办法是在环境变量中设置:_JAVA_SR_SIGNUM=12 基本就可以解决。
sun的解释:
--posted by: cooper
Below is a clipping from Sun on working around JVM crashes under high
thread counts in the JVM 1.3 for Linux
On Linux, use a larger signal number for hotspot thread
suspension/resumption handler. The signal number being used is
specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
number larger than SIGSEGV (11) will solve the problem. A good number
to use is 12, which is SIGUSR2. Using signal 16 to work around the
problem might have potential problems. So on tcsh, "setenv
_JAVA_SR_SIGNUM 12" can solve the problem.
追问
_JAVA_SR_SIGNUM=12 这答案我在已经看见过了,但是不理解的是_JAVA_SR_SIGNUM=12这步设置具体意义在哪儿?
追答
我也不是很懂,你可以看sun给的解释,个人理解是_JAVA_SR_SIGNUM是一个资源信号量(这里应该是用于处理请求的线程数),即_JAVA_SR_SIGNUM的值指定了一定数量的资源用于处理suspension/resumption(暂停/恢复的请求,就是因为服务器的性能原因未处理的用户的重复请求被取消或者重复提交)。通过设置_JAVA_SR_SIGNUM=12达到一个相对稳定的状态。(个人的理解)
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询