linux x打印内存不足,简单总结Linux上排查JVM问题，cpu飙升或者内存不足

前言

首先建议先简单了解JVM的内存机制，以及GC垃圾回收机制

初步了解jvm的内存分配，gc以及简单的jvm内存配置

以下j开头的命令基本都是java命令，如果没有设置全局环境变量，需要加上${java_home}全路径。如/usr/local/jdk8/java/bin/jmap pid

一、内存不足

1. 查看pid ps -ef|grep java 或 jps -lv

24130 就是pid

2. jmap -heap查看堆内存 jmap -heap pid

上面就是jvm的堆内存配置信息，以及新生代，老年代，永久代的内存最大值和当前使用值

3. jmap -histo:live

这里会触发Full GC jmap -histo:live pid > 1.txt

然后查看1.txt

less 1.txt 或者cat 1.txt

4. jmap -dump:live

同样会触发Full GC

可以导入到本地的jvisual进行分析，这个工具在jdk的java/bin目录下

可以查看类的实例数和所占内存大小，分析哪个类异常

二、cpu飙升

1. top命令

top命令查看cpu，内存情况 top

找到占用cpu高的pid top -Hp pid

再找出占用高的pid

2. jstack查看对账信息

假如通过Top命令，找到了占用cpu高的java应用的pid是24130

那么 jstack [-l] pid -l是打印出线程信息

jstack -l 24130

假如我们上面 top -Hp 命令找到的占用cpu高的pid是24190

先转成16进制 printf "%x\n" s

printf “%x\n” 24190

然后 jstack -l javapid | grep '0x'+十六进制pid -A10 --color -A是打印符合条件后n行,-C是环绕n行,-B是之前n行

jstack -l 24130|grep ‘0x5e7e’ -A10 --color

根据堆栈信息和线程状态，分析cpu占用原因。

如果线程状态是BLOCKED，就是线程阻塞中

三、gc和类加载情况

1. jstat -class jstat -class pid

Loaded:加载class的数量

Bytes：所占用空间大小

Unloaded：未加载数量

Bytes:未加载占用空间

Time：时间s

编译统计 jstat -compiler pid

2. jstat -gc

伊甸园区(Eden区)

幸存区(survivor区) jstat -gc pid 1000 1000表示1秒刷新一次

S0C：第一个幸存区的大小

S1C：第二个幸存区的大小

S0U：第一个幸存区的使用大小

S1U：第二个幸存区的使用大小

EC：伊甸园区的大小

EU：伊甸园区的使用大小

OC：老年代大小

OU：老年代使用大小

MC：方法区大小

MU：方法区使用大小

CCSC:压缩类空间大小

CCSU:压缩类空间使用大小

YGC：年轻代垃圾回收次数

YGCT：年轻代垃圾回收消耗时间 ，秒

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间 ，秒

GCT：垃圾回收消耗总时间 ，秒

总体垃圾回收统计 jstat -gcutil pid 1000

S0：幸存1区当前使用比例

S1：幸存2区当前使用比例

E：伊甸园区使用比例

O：老年代使用比例

M：元数据区使用比例

CCS：压缩使用比例

YGC：年轻代垃圾回收次数

FGC：老年代垃圾回收次数

FGCT：老年代垃圾回收消耗时间

GCT：垃圾回收消耗总时间

其他: # 新生代垃圾回收统计 jstat -gcnew pid #老年代垃圾回收统计 jstat -gcold pid

观察

通过观察YGC和FGC的次数和频率，以及FGCT / FGC 单位耗时，YGCT / YGC 单位耗时，判断内存是否足够。

如果频繁的FULL GC说明内存分配不合理。堆内存很可能分配太小了。并且GC会导致除了垃圾收集收集器线

程之外的线程都被挂起，频繁GC毫无疑问是影响程序的

观察Eden区的内存占用和老年代的内存占用，如果持续的增加说明很可能存在内存泄漏问题，可能导致OOM