理解cpu过高的逻辑思维与分析方法

     

 

 

工作经常碰到负载过高,cpu占有太高,系统变慢,运维通常做的第一件事就是通过top或者uptime命令来了解系统负载的情况

通常uptime后会出现三个小数,就是平均负载值,那真正的了解这个平均负载值吗?

大多数运维小哥会说:平局负载不就是cpu使用率吗?上面三个数字分别代表不同时间段的cpu使用率吗?

其实并不是这样的.......

平均负载的详细解释:平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是平均活跃进程数!和cpu使用率并没有直接关系

如果是工作中所期盼的,我们都希望平局负载最理想的状态的是等于cpu个数,所以,在通过命令来了解平均负载之前,我们应该先知道cpu的个数,才能更好的知道负载状态

#grep 'model name' /proc/cpuinfo | wc -l  

 

 

 当知道cpu个数后,如果平局负载值超过个数,就说明系统负载过高!!!

可是这样看来,既然平均负载代表的是活跃进程数,那平均负载高了,不就意味着 CPU 使用率高吗?

这里还得从理论来分析平均负载是指单位时间内,处于可运行状态和不可中断状态的进程数。所以,它不仅包括了正在使用 CPU 的进程,还包括等待 CPU 和等待 I/O 的进程。

由此可见!CPU 使用率,是单位时间内 CPU 繁忙情况的统计,跟平均负载并不一定完全对应。

比如:

CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的。

I/O 密集型进程,等待 I/O 也会导致平均负载升高,但 CPU 使用率不一 定很高。

大量等待 CPU 的进程调度也会导致平均负载升高,此时的 CPU 使用率也会比较高。

这里做一个小实验

模拟负载过高,来做分析

这里我用到的系统是 :

系统: RedFlag-Asianux-7.6
内核版本 3.10.0-957

                   注:其他的linux系统也可以做

要下一个压力测试包:stress-1.0.4-6.7.rpm

这个包各大镜像站网源有,可以查到并下载

这里分析两个立志;一个是模拟cpu使用率过高    |   一个模拟I/O压力过大


 

案例一:

下载安装后,开启三个终端,并在一个终端进行施压模拟,同时在另外两个终端进行排查分析

第一个终端:  模拟施压

#stress --cpu 1 --timeout 500

 

 

第二个终端:  查看平局负载

#uptime    

#watch -d uptime

 

 

 第三个终端;   找出引起负载过高的进程

#pidstat -u 5 1 

 


 

案例二:

模拟i/o压力,首先还是使用stress命令来测试

第一个终端:

 

#stress -i 1 --timeout 600

 

 

 

 

第二个终端:

#uptime

#mpstat -P ALL 5 1

 

 通过mpstat可以看出,平局负载过高是iowait引起的,那么到底是哪个进程,导致 iowait 这么高呢?我们还是用 pidstat 来查询(如:案例一)

 

-----

如何快速定位到是哪一个进程导致load过高

1,top  命令使用:总体查看各项信息,看看cpu占用率高的进程是什么(谨慎使用top,如果机器负载很高,最好不要使用)

2,ps  ux  :通过此命令,看第四列的%cpu  ,看看哪个进程占用过高

3,ps -Lp 进程PID  cu   :查看进程下线程占用cpu的使用情况

3,jstack   -l / -F  进程PID  >  打印到的文件   :查看进程的详细信息并分析它占用率高的原因

 

 


 

 

                                                                                           综上所例:

  平均负载提供了一个快速查看系统整体性能的手段,反映了整体的负载情况。但只看平均负载本身,我们并不能直接发现,到底是哪里出现了瓶颈。所以,在理解平均负载时,也要注意:

 

(1)平均负载高有可能是 CPU 密集型进程导致的;

 

(2)平均负载高并不一定代表 CPU 使用率高,还有可能是 I/O 更繁忙了;

 

(3)当发现负载高的时候,你可以使用 mpstatpidstat 等工具,辅助分析负载的来源

 

 

posted @ 2020-11-16 13:38  Supernova-L李  阅读(230)  评论(0编辑  收藏  举报