推荐设备MORE

企业微信小程序开发流程—M

企业微信小程序开发流程—M

行业知识

汇报工作时CPU 飙涨100%朋友们都手足无措记一次紧

日期:2021-02-18
我要分享
汇报工作时CPU 飙涨100%朋友们都手足无措记一次紧急解决全过程,手足无措
关注度1 评价 105  网民共享于:  :43 访问数24985次

汇报工作时CPU 飙涨100%朋友们都手足无措记一次紧急解决全过程,手足无措告警

已经汇报工作,忽然钉钉告警响声个不断,同时销售市场工作人员意见反馈顾客在举报系统软件登不进了,报504不正确。查询钉钉上的告警信息内容,多台业务流程网络服务器连接点所有报CPU超出告警阀值,达100%。

赶快从大会上出来,SSH登陆网络服务器,应用 top 指令查询,好多个Java过程CPU占有做到180%,190%,这好多个Java过程相匹配同一个业务流程服务的好多个Pod(或器皿)。

在这里插入图片描述

与朋友确定,该点为应用一个架构的excel导出来作用,而且,导出来excel时沒有分页查询,沒有限定!!!查询SQL查寻纪录,该导出来作用一次导出来50w总数据,而且每总数据都必须做变换测算,更加不尽人意的是,实际操作者由于导出来时很长时间沒有响应,因此持续点一下,一些钟内进行了10数次的导出来恳求。。。因此,CPU挨打满,服务奔溃了,因为我奔溃了。。

针对该类耗資源的实际操作,一定要搞好相对的限定。例如能够限定恳求量,操纵较大分页查询尺寸,同时能够限定浏览頻率,例如同一客户一分鐘内数最多恳求是多少次。

服务重新启动后修复。来到中午,又一台网络服务器连接点CPU告警,依前边流程精准定位到占有CPU高的进程,以下

 GC task thread#0 (ParallelGC) os_prio=0 tid=0x00007fa nid=0x10 runnable 
 GC task thread#1 (ParallelGC) os_prio=0 tid=0x00007fa nid=0x11 runnable 

应用指令 jstat -gcutil 过程ID 2000 10 查询GC状况,如图所示

在这里插入图片描述

发觉Full GC频次做到1000数次,且仍在持续提高,同时Eden区,Old区早已被占满(也可让用jmap -heap 过程ID 查询堆运行内存各个区的占有状况),应用jmap将运行内存应用状况dump出去,

jmap -dump:format=b,file=./jmap.dump 13

在这里插入图片描述

假如dump文档较为大,必须扩大MemoryAnalyzer.ini配备文档中的-Xmx值

发觉占有运行内存数最多的是char[], String目标,根据鼠标右键能够查询引入目标,但点开好像也看不出来因此然来,进到运行内存泄漏汇报网页页面,如图所示

在这里插入图片描述

该网页页面统计分析了堆运行内存的占有状况,而且得出疑是泄漏点,在图中中点开“see stacktrace”连接,进到进程栈网页页面,

在这里插入图片描述

似曾了解的界面,還是跟excel导出来相关,数据信息过多,造成运行内存外溢。。。因此GC经常,因此CPU爆了。根本原因還是同一个。

文中以解决一次网上服务CPU 100%的实战演练全过程实例了在碰到Java服务导致网络服务器CPU耗费太高或运行内存外溢的一般解决方式,期待对大伙儿精准定位网上相近难题出示参照。同时,开发设计完成作用时要要考虑到的更加深入远一些,不可以滞留在处理当今的情景,必须考虑到数据信息量持续扩大时,你的完成是不是还能可用。老话说,初中级程序猿处理当今难题,初级程序猿处理2年后的难题,高級程序猿处理五年之后的难题,_。

创作者:雨歌
file

dengb.TechArticle汇报工作时CPU 飙涨100%朋友们都手足无措记一次紧急解决全过程,手足无措 告警 已经汇报工作,忽然钉钉告警响声个不断,同时销售市场工作人员意见反馈顾客在投...