性能文章>JVM故障分析及性能优化系列之三:jstat命令的使用及VM Thread分析>

JVM故障分析及性能优化系列之三:jstat命令的使用及VM Thread分析原创

https://a.perfma.net/img/2959233
8月前
220704

前面提到了一个使用jstack的shell脚本,通过命令可以很快地定位到指定线程对应的堆栈信息。

使用jstat命令

当服务器CPU100%的时候,通过定位占用资源最大的线程定位到 VM Thread:

"VM Thread" prio=10 tid=0x00007fbea80d3800 nid=0x5e9 runnable

这个时候需要使用 jstat -gc <pid> <period> <times> 命令查看gc的信息,显示结果如下:
jstatgcresult1.jpeg

S0C    S1C    S0U    S1U      EC       EU      OC         OU       PC        PU       YGC     YGCT    FGC   FGCT       GCT
64.0   64.0   0.0    0.0   332992.0   0.0    666304.0   73192.5   83968.0   83967.9   6893   17.576  6882   2705.923  2723.499

结果中每个项目的含义可以参考官方对jstat的文档,简单翻译如下:

  • S0C: Young Generation第一个survivor space的内存大小 (kB).
  • S1C: Young Generation第二个survivor space的内存大小 (kB).
  • S0U: Young Generation第一个Survivor space当前已使用的内存大小 (kB).
  • S1U: Young Generation第二个Survivor space当前已经使用的内存大小 (kB).
  • EC: Young Generation中eden space的内存大小 (kB).
  • EU: Young Generation中Eden space当前已使用的内存大小 (kB).
  • OC: Old Generation的内存大小 (kB).
  • OU: Old Generation当前已使用的内存大小 (kB).
  • PC: Permanent Generation的内存大小 (kB)
  • PU: Permanent Generation当前已使用的内存大小 (kB).
  • YGC: 从启动到采样时Young Generation GC的次数
  • YGCT: 从启动到采样时Young Generation GC所用的时间 (s).
  • FGC: 从启动到采样时Old Generation GC的次数.
  • FGCT: 从启动到采样时Old Generation GC所用的时间 (s).
  • GCT: 从启动到采样时GC所用的总时间 (s).

JDK8的结果稍微有所不同,结果含义可以参考:http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jstat.html。

JVM内存模型

上面中的Young Generation、Permanent Generation和Old Generation等概念有一些混乱,这里简要的进行说明。简单来说,JVM内存由堆(Heap)和非堆(Non-heap)内存组成,前者共运行在JVM之上的程序使用,后者供JVM自己使用。
r_sunjdkmemoryarea1.png

堆内存的组成如下:
r_heap1.png

非堆内存由 Permanent Generation 和 Code Cache 两部分组成:

  • Permanent Generation(持久代): 保存虚拟机自己的静态(refective)数据,主要存放加载的Class类级别静态对象如class本身,method,field等等。permanent generation空间不足会引发full GC;

  • Code Cache: 用于编译和保存本地代码(native code)的内存,JVM内部处理或优化。

JVM内存参数设置

堆内存设置

  • 堆内存(总的)由 -Xms-Xmx 分别设置最小和最大堆内存

  • New Generation 由 -Xmn 设置,-XX:SurvivorRatio=m 设置 Eden和 两个Survivor区的大小比值;-XX:NewRatio=n 设置 New Generation 和 Old Generation 的大小比值。

  • 每个线程的堆栈大小由 ·-Xss· 设置,JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。

非堆内存设置

非堆内存由 -XX:PermSize=n-XX:MaxPermSize=n 分别设置最小和最大非堆内存大小

日志分析

介绍完上面的概念之后,我们再来看最上面的日志信息,有两个地方有问题:
一是FGC(完全GC)的数量太大了,正常来说FGC应该占整个GC(YGC+FGC)的1%到5%才正常,上面日志上完全GC的次数太多了;二是日志中PU的值太大了,基本上已经达到设置的PC了,因此需要增大MaxPermSize的值。

不过这只是权宜之计,出现这么大的非堆内存,肯定什么地方出现了问题,还需要进一步找到占用内存的原因,这也是后面文章所要说的。

原文链接:https://www.javatang.com/archives/2017/10/20/12131956.html

 

系列阅读

JVM故障分析及性能优化系列之一:使用jstack定位线程堆栈信息

JVM故障分析及性能优化系列之二:jstack生成的Thread Dump日志结构解析

JVM故障分析及性能优化系列之四:jstack生成的Thread Dump日志线程状态

JVM故障分析及性能优化系列之五:常见的Thread Dump日志案例分析

JVM故障分析及性能优化系列之六:JVM Heap Dump(堆转储文件)的生成和MAT的使用

JVM故障分析及性能优化系列之七:使用MAT的Histogram和Dominator Tree定位溢出源

请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得