Linux 性能监控与诊断1

1. 认识内核数

2. CPU占用率

3. 平均负载

4. CPU占用率和平均负载的关系

4.1 CPU高不一定平均负载高

Linux 性能监控与诊断1

 

 load高,CPU不高

Linux 性能监控与诊断1

 

 

 

以下是转载:

1、查看Linux系统CPU个数

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

 
Linux 性能监控与诊断1
 

2、每次发现系统变慢时,我们通常做的第一件事,就是执行top或者uptime命令

#    uptime?

 
Linux 性能监控与诊断1
当前时间、系统运行时间以及正在登录用户数    #######   14:53:06 //当前时间    #######   up 1:42 //系统运行时间    #######   3 users //正在登录用户数    #######   而最后三个数字呢,依次则是过去1分钟、5分钟、15分钟的平均负载(Load Average)??

2.1、如果1分钟、5分钟、15分钟的三个值基本相同,或者相差不大,那就说明系统负载很平稳。?

2.2、但如果1分钟的值远小于15 分钟的值,就说明系统最近1分钟的负载在减少,而过去15分钟内却有很大的负载。

2.3、反过来,如果1分钟的值远大于 15 分钟的值,就说明最近1分钟的负载在增加,这种增加有可能只是临时性的,也有可能还会持续增加下去,所以就需要持续观察。一旦1分钟的平均负载接近或超过了CPU的个数,就意味着系统正在发生过载的问题,这时就得分析调查是哪里导致的问题,并要想办法优化了。

??eg:假设我们在一个单 CPU 系统上看到平均负载为 1.73,0.60,7.98,那么说明在过去 1 分钟内,系统有 73% 的超载,而在 15 分钟内,有 698% 的超载,从整体趋势来看,系统的负载在降低。? ?

2.4、当平均负载高于 CPU 数量70%的时候,你就应该分析排查负载高的问题了。一旦负载过高,就可能导致进程响应变慢,进而影响服务的正常功能。?

2.5、CPU 使用率,是单位时间内 CPU 繁忙情况的统计,跟平均负载并不一定完全对应

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

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

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

3、使用工具iostat(stress)、mpstat、pidstat 等工具,找出平均负载升高的根源

#    yum install -y epel-release
#    yum install -y stress
??#    yum install -y sysstat

3.1、stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景??

3.2、而 sysstat 包含了常用的 Linux 性能工具,用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。?

3.2.1、mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有CPU的平均指标。

3.2.2、pidstat 是一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标


场景一:CPU 密集型进程(需要开三个终端,登录到同一台 Linux 机器中)

首先,在第一个终端运行 stress 命令,模拟一个 CPU 使用率 100% 的场景

#    stress --cpu 1 --timeout 600

 
Linux 性能监控与诊断1
 

接着,在第二个终端运行uptime查看平均负载的变化情况

#    watch -d uptime                          ### -d 参数表示高亮显示变化的区域?? 

 
Linux 性能监控与诊断1
 

最后,在第三个终端运行mpstat查看 CPU 使用率的变化情况

#    mpstat -P ALL 5                         ### -P ALL 表示监控所有CPU,后面数字5表示间隔5秒后输出一组数

 
Linux 性能监控与诊断1
eg:从终端二中可以看到,1 分钟的平均负载会慢慢增加到 1.00,而从终端三中还可以看到,正好有一个 CPU 的使用率为 100%,但它的 iowait 只有 0。这说明,平均负载的升高正是由于 CPU 使用率为 100%

那么到底是哪个进程,导致 iowait 这么高呢?我们还是用 pidstat 来查询

#    pidstat -u 5 1                       ### 间隔5秒后输出一组数据,-u表示CPU指标 ,从这里可以明显看到,stress进程的CPU使用率为100%。

 
Linux 性能监控与诊断1
 

场景二:I/O 密集型进程

首先还是运行 stress 命令,但这次模拟 I/O 压力,即不停地执行 sync

#    stress -i 1 --timeout 600

还是在第二个终端运行uptime查看平均负载的变化情况

#    watch -d uptime

然后,第三个终端运行mpstat查看 CPU 使用率的变化情况

#    mpstat -P ALL 5 1                      # 显示所有CPU的指标,并在间隔5秒输出一组数据

 
Linux 性能监控与诊断1
eg:从这里可以看到,1 分钟的平均负载会慢慢增加到 1.06,其中一个 CPU 的系统CPU使用率升高到了 23.87,而 iowait 高达 67.53%。这说明,平均负载的升高是由于 iowait 的升高。

那么到底是哪个进程,导致 iowait 这么高呢?我们还是用 pidstat 来查询

#    pidstat -u 5 1                               # 间隔5秒后输出一组数据,-u表示CPU指标 

### ?可以发现,还是 stress 进程导致的。??

 
Linux 性能监控与诊断1
 

场景三:大量进程的场景

当系统中运行进程超出 CPU 运行能力时,就会出现等待 CPU 的进程。比如,我们还是使用 stress,但这次模拟的是 4 个进程

#    stress -c 8 --timeout 600

 
Linux 性能监控与诊断1
 

由于系统只有 1 个CPU,明显比 4 个进程要少得多,因而,系统的 CPU 处于严重过载状态,平均负载高达3.71

#    uptime

 
Linux 性能监控与诊断1
 

接着再运行pidstat来看一下进程的情况

#    pidstat -u 5 1 # 间隔5秒后输出一组数据,-u表示CPU指标

 
Linux 性能监控与诊断1


作者:SuperGu
链接:https://www.jianshu.com/p/56468fa6e048

Linux 性能监控与诊断1

上一篇:软件测试菜鸟之路(5)————Shell编程


下一篇:Linux 下迁移 Nexus3