线上linux系统故障排查

CPU使用率过高

一个应用占用CPU很高，除了确实是计算密集型应用之外，通常原因都是出现了死循环。
下面我们将一步步定位问题，详尽的介绍每一步骤的相关知识。

一、通过top命令定位占用cpu高的进程

执行top命令得到以下结果：top命令执行结果

image

通过上图可以明显看出进程PID41843占用cpu过高，明显存在问题，定位到了进程id。当然如果你想只观察进程PID41843的CPU和内存以及负载情况，可以使用以下命令

top -p 41843。

结果如下：top -p 41843命令执行结果

image

这里顺便解释下上图各个参数的意义，有利于读者更好的排查问题。

1. 第一行是任务队列信息
   top - 14:06:34 up 537 days, 6 min, 6 users, load average: 0.41, 0.45, 0.43

任务队列信息	含义
14:06:34	当前时间
537 days	系统运行时间
6 min	用户在线时间
6 users	在线用户数
load average: 0.41, 0.45, 0.43	系统负载，即任务队列的平均长度。1分钟前、5分钟前、15分钟前平均负载

2)第二行为进程的信息

进程信息	含义
Tasks: 1 total	进程总数
0 running	正在运行的进程数
1 sleeping	睡眠的进程数
0 stopped	停止的进程数
0 zombie	僵尸进程数

1. 第三行为cpu信息

cpu信息	含义
6.1% us	用户空间占用CPU百分比
1.5% sy	内核空间占用CPU百分比
0.0% ni	用户进程空间内改变过优先级的进程占用CPU百分比
92.2% id	空闲CPU百分比
0.0% wa	等待输入输出的CPU时间百分比
0.0% hi	硬件中断
0.0% si	软件中断
0.0%st	实时

1. 第四、五行为内存信息。
   内容如下：

物理内存信息	含义
Mem: 191272k total	物理内存总量
173656k used	使用的物理内存总量
17616k free	空闲内存总量
22052k buffers	用作内核缓存的内存量

交换区信息	含义
Swap: 192772k total	交换区总量
0k used	使用的交换区总量
192772k free	空闲交换区总量
123988k cached	缓冲的交换区总量

二、通过top命令定位问题进程中每个线程占用cpu情况

通过问题进程中每个线程占用cpu情况使用可以使用如下命令：

top -p 41843 -H

查看进程PID41843的每一个线程占用CPU情况，如图。top -p 41843 -H的执行结果

image

由上图明显可以发现，线程PID41892CPU占用率最高，接下来定位该线程的代码是否出现异常导致cpu占用过高。

三、通过jstack 命令定位问题代码

上一步发现PID41892占用的CPU过高，就将这个PID转换成16进制，易知，PID41892转化成16进制为a3a4。使用如下命令命令定位问题代码：

jstack 41892 | grep a3a4

输出如下：

"Thread" prio=10 tid=0x00007f950043e000 nid=0x54ee in test()；

可以分析得到： 线程Thread下的wait()函数cpu使用率很高，查看源代码中的test()函数代码如下：

public void test(){  while(true){     for(int i = 0 ;i<100;i++);  }}

while循环无法结束，一直抢占cpu，导致程序cpu使用过高，修改代码即可。
到此为止，因为代码问题导致的cpu使用过高的故障排查方法就介绍完了。

内存占用过高

一、异常出现的原因

1.Java.lang.OutOfMemoryError: PermGen space

PermGen space全称是Permanent Generation space,是指内存的永久保存区域, 这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中, 它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对 PermGen space进行清理，所以如果你的应用中有很多CLASS的话,就很可能出现PermGen space错误。如果你的WEB或者APP用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息。

解决方法：
1.调整PermSize、MaxPermSize的大小；
2.减少jar重复使用，重复占用内存。

2.java.lang.OutOfMemoryError: Java heap space

Heap size 设置 JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。

在JVM中，如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

二、异常原因排查步骤

1.通过jstat命令查询gc情况

通过top命令定位到内存占用过高的进程PID后，排查该进程的GC情况，

命令：jstat -gccause 41843 2000

• 每间隔2s查询进程pid = 41843 的gc情况；
• gccause表示输出-gcutil提供的信息以及最后一次执行GC的发生原因和当前所执行的GC的发生原因。

image

jstat命令的结果

2.通过jmap命令查询进程实体类内存占用情况

如果步骤1中发现，gc非常频繁，则可以使用jmap命令查询进程实体类内存占用情况。

命令： jmap -histo:live 41843 | head -n 100

• 查询进程pid = 41843 存活的对象占用内存前100排序。

image

jmap 命令结果

如上图可以看出，jdbc所占用的存活对象特别多，而且占用的内存也很高，从这里就可以看出，需要去检查下mysql的调用中，哪里存在问题，有内存泄露。

3.通过jmap命令查询进程堆的使用情况

如果以上没有查出问题，可以看看进程中，新生代、老年代、永久代的使用情况。

命令： jmap -heap 41843

image

jmap -heap 41843结果

如上图，如果发现频繁的gc是因为新生代、老年代、永久代分配的大小有问题，则可以通过修改设置解决。

永久代解决方法（同上）：
1.调整PermSize、MaxPermSize的大小；
2.减少jar重复使用，重复占用内存。

新生代、老年代解决方法：
1.调整Xms -Xmx -Xmn的大小

示例及参数注解：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:PermSize=64M -XX:MaxPermSize=128M -XX:MaxTenuringThreshold=0

-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存；
-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右；
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5；
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6；
-XX:PermSize=64M JVM初始分配的非堆内存（永久代）；
-XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配；
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。