生产事故
Louis.No1
这个作者很懒,什么都没留下…
展开
-
服务器请求大量COLSE_WAIT排查
1. 背景 生产环境的服务器突然访问无响应,而我的服务是用来接收上游推送数据用的,功能也是最近新上线的; 2. 定位原因 访问系统的version方法,也无响应,服务器日志也没有输出http请求的日志;登录服务器查看服务的状态正常; 初步怀疑会不会是程序问题引起的频繁FullGC问题,查看内存使用情况也正常 Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSiz原创 2020-08-08 12:35:24 · 347 阅读 · 0 评论 -
记一次JVM内存溢出排查过程
内存溢出排查1. 频繁FullGC预警2. 排查原因 1. 频繁FullGC预警 1.1 频繁FullGC告警: 时间发生在2020-07-10(周五)晚上21:15分左右,本该收拾行囊下班,突然收到频繁FullGC预警消息,吓的菊花一紧,过一会收到接口探活告警,说明服务已经不可用了; 1.2 下线当前问题节点: 服务是3台节点部署,既然其中一台出现问题,在上层网关上将当前节点下线,保证用户的请求不会再打到当前节点; 1.3 年青代和老年代情况: 登录监控平台查看jvm的情况: 黄色线:老年代 蓝色线:原创 2020-07-12 00:57:14 · 1353 阅读 · 0 评论 -
JVM设置不当造成的生产事故
说来你可能不信,但是这就是事实,JVM设置不当会选成严重的生产事故;这段时间随着业务数据量的不断提升,遇到了很多性能方面的问题,其中就包括JVM的配置; 1.服务频繁重启 我的系统上游对接了一些系统A,系统A会间隔1小时推一次数据,每次推送大概40-50W的数据量,就在上周,系统其中一个节点突然频繁重启,一到整点就收到服务重启的告警,我的个去,这让我很尴尬(毕竟这个节点前几天刚出过事故); 2.原因分析 查看CPU、IO、内存、JVM的监控都没有查出为什么,只是看出内存的可用空间剩余不多了,但也还有20G左原创 2020-06-07 17:18:36 · 364 阅读 · 0 评论 -
记一次排查线上频繁FullGC 过程
记一次排查线上频繁FullGC 过程一、一段艰辛的排查过程1.突发告警1.1 新生代老年代情况:1.2 老年代GC情况2.紧急处理3.问题定位3.1 dump文件过大:3.2 如何分析:3.3 排查原因3.4 水落石出4.修复上线二、收获 一、一段艰辛的排查过程 记录一次生产环境频繁FullGC的排查过程,艰辛但收获满满; 1.突发告警 这是一个风和日丽的下午,已经疲惫不堪的我正日常码代码,突然收到JVM监控告警,进入监控大盘查看JVM情况: 1.1 新生代老年代情况: 图片截了一张最简化的出来,因为公司原创 2020-06-06 23:25:00 · 561 阅读 · 0 评论