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

 1.. jstact 命令先分析一下

一次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