线上linux系统故障排查

CPU使用率过高

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

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

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

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

top -p 41843。

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

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

  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的执行结果

由上图明显可以发现,线程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的发生原因。

jstat命令的结果

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

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

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

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

jmap 命令结果

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

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

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

命令: jmap -heap 41843

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区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

Linux服务器故障以及性能排查常用命令https://blog.csdn.net/gyshun/article/details/82661792

猜你喜欢

转载自blog.csdn.net/wade3015/article/details/88416531