【jvm】来自于线上的fullGC分析

【【jvm】来自于线上的fullGC分析】的更多相关文章

【jvm】来自于线上的fullGC分析

系统最近老年代的内存上升的比较快,三到四天会发生一波fullGC.于是开始对GC的情况做一波分析. 线上老年代2.7G,年轻带1.3G老年代上升较快,3天一波fullGC,并且fullGC会把内存回收,有时回收一般,有时回收全部.所以判断是不会有内存泄漏现象的,内存发生泄漏是回收不了的.第二个判断,不存在大对象,一个是基于对程序的理解,一个是对于老年代上升的速率,基本是稳固上升.不存在峰值. 我是先用jstack 命令打印出线程状态的 jstack -l pid >> 文件名发现这么…

关于GC(上)：Apache的POI组件导致线上频繁FullGC问题排查及处理全过程

某线上应用在进行查询结果导出Excel时,大概率出现持续的FullGC.解决这个问题时,记录了一下整个的流程,也可以作为一般性的FullGC问题排查指导. 1. 生成dump文件为了定位FullGC的原因,首先需要获取heap dump文件,看下发生FullGC时堆内存的分配情况,定位可能出现问题的地方. 1. 1 通过JVM参数自动生成可以在JVM参数中设置-XX:+ HeapDumpBeforeFullGC参数. 建议动态增加这个参数,直接在线上镜像中增加一方面是要重新打包发布,另一方面…

记一次线上OOM问题分析与解决

一.问题情况最近用户反映系统响应越来越慢,而且不是偶发性的慢.根据后台日志,可以看到系统已经有oom现象. 根据jdk自带的jconsole工具,可以监视到系统处于堵塞时期.cup占满,活动线程数持续增加,堆内存接近峰值. 二.分析情况使用jconsole分析: 找到jdk安装路径,点击bin目录下的jconsole.exe,运行.…

我整理的一份来自于线上的Nginx配置（Nginx.conf），希望对学习Nginx的有帮助

我整理了一份Nginx的配置文件说明,是真正经历过正式线上考验过.如果有优化的地方,也请朋友们指点一二,整理出一份比较全而实用的配置. 主要包含配置:负载均衡配置,页面重定向,转发,HTTPS和HTTP的配置, 缓存优化,错误页面配置等. #user nobody; #工作进程,于CPU核数一致 worker_processes 2; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/erro…

一次线上mysql死锁分析

一.现象发运车次调用发车接口时发生异常,后台抛出数据库死锁日志. 二.原因分析通过日志可以看出事务T1等待 heap no 8的行锁 (X locks 排他锁) 事务T2持有heap no 8的行锁,等待heap no 7的行锁两个更新运单sql发生死锁. 三.代码追踪发车接口:/ltl/loadShiftOrg/send 更新运单状态通过循环遍历进行操作,比较耗时. 其他接口更新运单导致发生死锁在发车接口之前还调用了另外一个接口 /ltl/loadShift/saveOrUpdate…

记一次线上频繁fullGc的排查解决过程

发生背景最近上线的一个项目几乎全是查询业务,并且都是大表的慢查询,sql优化是做了一轮又一轮,前几天用户反馈页面加载过慢还时不时的会timeout,但是我们把对应的sql都优化一遍过后,前台响应还是很慢,数据库测试sql运行时间在3s以内但响应的时候要么500要么就超时了,这时猜测可能是服务器出了问题,于是让运维监测了下GC情况,结果令人吃惊,近15小时发生了237次FGC,每次耗时近4000秒:于是我就让他把内存快照dump给我了通过MAT分析内存快照常用名词介绍 Leak Suspec…

快速定位java系统的线上问题--转

原文地址:http://m.blog.csdn.net/article/details?id=43376943 前言:我们的场景并没有像BAT等大型互联网公司里的系统那么复杂,但是基本上也有一定的规模,暂且就认为我们是一个中型互联网系统.但是工具和思路都是差不多的,因为原理是一样的.同时下面提到的命令,具体详细的用法,我想google上已经有足够多的资源了,这里只说思路与方向. 首先我们分析一下服务器构造和操作系统,服务器我们可以简单的分解为CPU.内存.硬盘(其他部件的我们就不考虑了),操作系…