使用jprofiler分析dump文件一个实例

1.. jstat 命令先分析一下

一次fullgc之后 old 老年代使用比例 只降低2% 应该有什么大的对象常驻内存。

 

2.可以使用jmap 命令查看对象大小 (这里后面使用jprofiler 就没用这个命令)

 

jmap -histo:live 72947 | more 

 

3 .dump 线上文件栈

[root@yszyz10a153 ~]# jmap -dump:live,format=b,file=heap201712.hropf  72947   
Dumping heap to /root/heap201712.hprof ...
Heap dump file created

 

4

使用jprofiler 加载dump文件 (jprofiler版本9.1.1)

 

点击菜单biggst object 发现大对象是arrayblockingqueue 占用400M 点击show in graph 图形展示对象

 

 

 

发现关联的可能问题来自 logback 

 

继续查看

 

也是指向logback 

 

查看logback的配置文件 info级别

 

	<!-- 异步输出，异步的log片段必须在同步段后面，否则不起作用 -->
	<appender name="ASYNC_INFO" class="ch.qos.logback.classic.AsyncAppender">
		<!-- 不丢失日志.默认的,如果队列的80%已满,则会丢弃TRACT、DEBUG、INFO级别的日志 , 保持INFO的events，设置该值为0。 -->
		<discardingThreshold>0</discardingThreshold>
		<!-- 更改默认的队列的深度,该值会影响性能.默认值为256 -->
		<queueSize>100000000</queueSize> <!-- 设置太大 ，系统可能跑步起来 0<queueSize<1个亿 -->
		<!-- 添加附加的appender,最多只能添加一个 -->
		<appender-ref ref="INFO" />
	</appender>

 

queuesize 设置的太大了 调小该值即可  是个初始的blockingqueue