一次使用 Eclipse Memory Analyzer 分析 Tomcat 内存溢出

简介:

最近,线上生产系统突然频繁的 JVM 内存报警!但本系统近期内并没有上线改动!

为了能查清内存报警的原因,使用 Eclipse Memory Analyzer tool(MAT)对 JVM Dump 文件进行了分析!

1. 生成 dump 文件

用 jmap 生产 dump 文件

1
jmap -dump:format=b,file=HeapDump.bin <pid>

2. MAT 安装与介绍

下载地址:http://www.eclipse.org/mat/downloads.php

1_20150209180326.jpg

通过 MAT 打开 dump 出来的内存文件,打开后如下图:

1_20150209180332.jpg 1_20150209180338.jpg

Histogram 可以列出内存中的对象,对象的个数以及大小。

Histogram 如下图:

Objects:类的对象的数量。
Shallow size:就是对象本身占用内存的大小,不包含对其他对象的引用,也就是对象头加成员变量(不是成员变量的值)的总和。
Retained size:是该对象自己的 shallow size,加上从该对象能直接或间接访问到对象的 shallow size 之和。换句话说,retained size 是该对象被 GC 之后所能回收到内存的总和。

我们发现 ConcurrentHashMap 类的对象占用了很多空间。

1_20150209180345.jpg

Leak Suspects 如下图:

从那个饼图,该图深色区域被怀疑有内存泄漏,可以发现整个 heap 2G 内存,深色区域就占了 98%。后面的描述,说明内存被一个实例占用了大量内存,并指出 system class loader 加载的"java.util.concurrent.concurrentHashMap$Segmen[]"实例的内存中聚集(消耗空间),并建议用关键字"java.util.concurrent.concurrentHashMap$Segmen[]"进行检查。所以,MAT 通过简单的报告就说明了问题所在。

1_20150209180403.jpg

Dominator Tree 如下图:>

我们逐层打开 concurrentHashMap 的内存结构,发现 Key 非常多,并且最底层的 String 长度很大!

幸运的是该系统的下游也是我们负责的系统,猜测 concurrentHashMap 应该是 RPC 调用返回回值待处理的内存存储,正常情况这个 String 的长度不很大。仔细查看, String 里包含了多了很多详细的异常描述信息,之前是没有的。

1_20150209180411.jpg

排查下游系统代码,发现在返回异常时,与之前异常抛出有所不同:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
try  {
catch (Exception e) {
     throw  e;
}
  
...
  
try  {
catch (Exception e) {
     throw  new  Exception( "xxxx" , e);
}
  
// 返回伪代码
response(e.getMessage);

就是有这些许的不同,我们看下源代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public  Throwable(String message, Throwable cause) {
     fillInStackTrace();
     detailMessage = message;
     this .cause = cause;
}
  
public  Throwable(Throwable cause) {
     fillInStackTrace();
     detailMessage = (cause== null  null  : cause.toString());
     this .cause = cause;
}
  
public  String getMessage() {
     return  detailMessage;
}

当没有 message,message = cause.toString(),所以就造成了返回大量不必要的异常信息,从而影响了上游系统!










本文转自 LinkedKeeper 51CTO博客,原文链接:http://blog.51cto.com/sauron/1614362,如需转载请自行联系原作者
目录
相关文章
|
19天前
|
Web App开发 监控 JavaScript
监控和分析 JavaScript 内存使用情况
【10月更文挑战第30天】通过使用上述的浏览器开发者工具、性能分析工具和内存泄漏检测工具,可以有效地监控和分析JavaScript内存使用情况,及时发现和解决内存泄漏、过度内存消耗等问题,从而提高JavaScript应用程序的性能和稳定性。在实际开发中,可以根据具体的需求和场景选择合适的工具和方法来进行内存监控和分析。
|
1月前
|
编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(上)
动态内存分配与管理详解(附加笔试题分析)
49 1
|
2月前
|
程序员 编译器 C++
【C++核心】C++内存分区模型分析
这篇文章详细解释了C++程序执行时内存的四个区域:代码区、全局区、栈区和堆区,以及如何在这些区域中分配和释放内存。
53 2
|
13天前
|
开发框架 监控 .NET
【Azure App Service】部署在App Service上的.NET应用内存消耗不能超过2GB的情况分析
x64 dotnet runtime is not installed on the app service by default. Since we had the app service running in x64, it was proxying the request to a 32 bit dotnet process which was throwing an OutOfMemoryException with requests >100MB. It worked on the IaaS servers because we had the x64 runtime install
|
23天前
|
Web App开发 JavaScript 前端开发
使用 Chrome 浏览器的内存分析工具来检测 JavaScript 中的内存泄漏
【10月更文挑战第25天】利用 Chrome 浏览器的内存分析工具,可以较为准确地检测 JavaScript 中的内存泄漏问题,并帮助我们找出潜在的泄漏点,以便采取相应的解决措施。
143 9
|
28天前
|
并行计算 算法 IDE
【灵码助力Cuda算法分析】分析共享内存的矩阵乘法优化
本文介绍了如何利用通义灵码在Visual Studio 2022中对基于CUDA的共享内存矩阵乘法优化代码进行深入分析。文章从整体程序结构入手,逐步深入到线程调度、矩阵分块、循环展开等关键细节,最后通过带入具体值的方式进一步解析复杂循环逻辑,展示了通义灵码在辅助理解和优化CUDA编程中的强大功能。
|
1月前
|
程序员 编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(下)
动态内存分配与管理详解(附加笔试题分析)(下)
47 2
|
2月前
|
算法 程序员 Python
程序员必看!Python复杂度分析全攻略,让你的算法设计既快又省内存!
在编程领域,Python以简洁的语法和强大的库支持成为众多程序员的首选语言。然而,性能优化仍是挑战。本文将带你深入了解Python算法的复杂度分析,从时间与空间复杂度入手,分享四大最佳实践:选择合适算法、优化实现、利用Python特性减少空间消耗及定期评估调整,助你写出高效且节省内存的代码,轻松应对各种编程挑战。
41 1
|
2月前
|
存储 Prometheus NoSQL
Redis 内存突增时,如何定量分析其内存使用情况
【9月更文挑战第21天】当Redis内存突增时,可采用多种方法分析内存使用情况:1)使用`INFO memory`命令查看详细内存信息;2)借助`redis-cli --bigkeys`和RMA工具定位大键;3)利用Prometheus和Grafana监控内存变化;4)优化数据类型和存储结构;5)检查并调整内存碎片率。通过这些方法,可有效定位并解决内存问题,保障Redis稳定运行。
|
1月前
|
SQL 安全 算法
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)

推荐镜像

更多
下一篇
无影云桌面