线上应用故障排查之一:高memory占用

简介: 前一篇介绍了线上应用故障排查之一:高CPU占用,这篇主要分析高内存占用故障的排查。 搞Java开发的,经常会碰到下面两种异常: 1、java.lang.OutOfMemoryError: PermGen space 2、java.lang.OutOfMemoryError: Java heap space 要详细解释这两种异常,需要简单重提下Java内存模型。

前一篇介绍了线上应用故障排查之一:高CPU占用,这篇主要分析高内存占用故障的排查。

搞Java开发的,经常会碰到下面两种异常:

1、java.lang.OutOfMemoryError: PermGen space

2、java.lang.OutOfMemoryError: Java heap space

要详细解释这两种异常,需要简单重提下Java内存模型。

(友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen

Java内存模型是描述Java程序中各变量(实例域、静态域和数组元素)之间的关系,以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。

在Java虚拟机中,内存分为三个代:新生代(New)、老生代(Old)、永久代(Perm)。

(1)新生代New:新建的对象都存放这里

(2)老生代Old:存放从新生代New中迁移过来的生命周期较久的对象。新生代New和老生代Old共同组成了堆内存。

(3)永久代Perm:是非堆内存的组成部分。主要存放加载的Class类级对象如class本身,method,field等等。

如果出现java.lang.OutOfMemoryError: Java heap space异常,说明Java虚拟机的堆内存不够。原因有二:

(1)Java虚拟机的堆内存设置不够,可以通过参数-Xms、-Xmx来调整。

(2)代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)。

如果出现java.lang.OutOfMemoryError: PermGen space,说明是Java虚拟机对永久代Perm内存设置不够。

一般出现这种情况,都是程序启动需要加载大量的第三方jar包。例如:在一个Tomcat下部署了太多的应用。

 

从代码的角度,软件开发人员主要关注java.lang.OutOfMemoryError: Java heap space异常,减少不必要的对象创建,同时避免内存泄漏。

现在以一个实际的例子分析内存占用的故障排查。

2G19({7(0}N(FIL09LH175N

通过top命令,发现PID为9004的Java进程一直占用比较高的内存不释放(24.7%),出现高内存占用的故障。

想起上一篇线上应用故障排查之一:高CPU占用介绍的PS命令,能否找到具体是哪个的线程呢?

ps -mp 9004 -o THREAD,tid,time,rss,size,%mem

1

遗憾的是,发现PS命令可以查到具体进程的CPU占用情况,但是不能查到一个进程下具体线程的内存占用情况。

 

只好寻求其他方法了,幸好Java提供了一个很好的内存监控工具:jmap命令

jmap命令有下面几种常用的用法:

?jmap [pid]

?jmap -histo:live [pid] >a.log

?jmap -dump:live,format=b,file=xxx.xxx [pid]

用得最多是后面两个。其中,jmap -histo:live [pid] 可以查看当前Java进程创建的活跃对象数目和占用内存大小。

jmap -dump:live,format=b,file=xxx.xxx [pid] 则可以将当前Java进程的内存占用情况导出来,方便用专门的内存分析工具(例如:MAT)来分析。

这个命令对于分析是否有内存泄漏很有帮助。具体怎么使用可以查看本博的另一篇文章:利用Eclipse Memory Analyzer Tool(MAT)分析内存泄漏

 

这里详细介绍下jmap -histo:live [pid] 命令:

1

从上图可以看出,int数组、constMethodKlass、methodKlass、constantPoolKlass都占用了大量的内存。

特别是占用了大量内存的int数组,需要仔细检查相关代码。

 

最后,总结下排查内存故障的方法和技巧有哪些:

1、top命令:Linux命令。可以查看实时的内存使用情况。  

2、jmap -histo:live [pid],然后分析具体的对象数目和占用内存大小,从而定位代码。

3、jmap -dump:live,format=b,file=xxx.xxx [pid],然后利用MAT工具分析是否存在内存泄漏等等。

(友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen

目录
相关文章
|
5月前
|
Arthas Java 测试技术
Docker 环境中 Spring Boot 应用的 Arthas 故障排查与性能优化实战
Docker 环境中 Spring Boot 应用的 Arthas 故障排查与性能优化实战
|
监控 JavaScript Java
Node.js 应用故障排查手册 —— 综合性 GC 问题和优化
本章前面两节生产案例分别侧重于单一的 CPU 高和单一的内存问题,我们也给大家详细展示了问题的定位排查过程,那么实际上还有一类相对更复杂的场景——它本质上是 V8 引擎的 GC 引发的问题。
1831 0
|
11月前
|
运维 Prometheus 监控
可观测性与应用监控:实时性能分析和故障排查
在现代软件开发中,应用程序的可观测性和实时性能分析变得越来越重要。随着应用程序规模和复杂性的增加,我们需要能够及时发现和解决潜在的性能问题和故障,并保持应用程序的高可用性。在本文中,我们将讨论可观测性的概念以及应用监控中的实时性能分析和故障排查方法。
141 0
|
SQL JavaScript 前端开发
Node.js 应用故障排查手册 —— 雪崩型内存泄漏问题
还有一些问题场景下下应用的内存泄漏非常严重和迅速,甚至于在我们的告警系统感知之前就已经造成应用的 OOM 了,这时我们来不及或者说根本没办法获取到堆快照,因此就没有办法借助于之前的办法来分析为什么进程会内存泄漏到溢出进而 Crash 的原因了。
1676 0
|
前端开发 JavaScript
Node.js 应用故障排查手册 —— 类死循环导致进程阻塞
在实践篇一中我们看到了两个表象都是和 CPU 相关的生产问题,它们基本也是我们在线上可能遇到的这一类问题的典型案例,而实际上这两个案例也存在一个共同点:我们可以通过 [Node.js 性能平台](https://www.aliyun.com/product/nodejs) 导出进程对应的 CPU Profile 信息来进行分析定位问题,但是实际在线上的一些极端情况下,我们遇到的故障是没有办法通过轻量的 V8 引擎暴露的 CPU Profile 接口(仅部分定制的 AliNode runtime 版本支持,详见下文)来获取足够的进程状态信息进行分析的,此时我们又回到了束手无策的状态。
1968 0
|
JavaScript 前端开发 开发者
Node.js 应用故障排查手册 —— 冗余配置传递引发的内存溢出
前面一小节我们以一个真实的压测案例来给大家讲解如何利用 [Node.js 性能平台](https://www.aliyun.com/product/nodejs) 生成的 CPU Profile 分析来进行压测时的性能调优。
1462 0
|
缓存 JavaScript 前端开发
Node.js 应用故障排查手册 —— 利用 CPU 分析调优吞吐量
在我们想要新上线一个 Node.js 应用之前,尤其是技术栈切换的第一个 Node.js 应用,由于担心其在线上的吞吐量表现,肯定会想要进行性能压测,以便对其在当前的集群规模下能抗住多少流量有一个预估。
1886 0
|
Web App开发 JavaScript 前端开发
Node.js 应用故障排查手册 —— Node.js 性能平台使用指南
实际上预备章中除了 CPU/Memory 的问题,我们还会遇到一些需要分析错误日志、磁盘和核心转储文件等才能定位问题的状况,因此在这些场景下,仅仅靠 Chrome devtools 显然会有一些力不从心。
1972 0
|
Web App开发 JavaScript 前端开发
Node.js 应用故障排查手册 —— 正确打开 Chrome devtools
前面的预备章节中我们大致了解了如何在服务器上的 Node.js 应用出现问题时,从常规的错误日志、系统/进程指标以及兜底的核心转储这些角度来排查问题。这样就引出了下一个问题:我们知道进程的 CPU/Memory 高,或者拿到了进程 Crash 后的核心转储,要如何去进行分析定位到具体的 JavaScript 代码段。
1893 0
|
监控 JavaScript 前端开发
Node.js 应用故障排查手册 —— 大纲与常规问题指标简介
JavaScript 发展到今天,早已脱离原本浏览器的战场,借助于 Node.js 的诞生将其触角伸到了服务端、PC 跨平台客户端方案等各个领域,但是与此同时,JS Runtime 对于绝大部分的开发者来说又一如既往的处于黑盒状态——开发者无法感知其运行状态,出现一些性能、内存问题时也没有很好的工具链进行更深入的支持。
1753 0

热门文章

最新文章