CPU 使用率
CPU 使用率就是 CPU 非空闲态运行的时间占比，它反映了 CPU 的繁忙程度。比如，单核 CPU 1s 内非空闲态运行时间为 0.8s，那么它的 CPU 使用率就是 80%；双核 CPU 1s 内非空闲态运行时间分别为 0.4s 和 0.6s，那么，总体 CPU 使用率就是 (0.4s + 0.6s) / (1s * 2) = 50%，其中 2 表示 CPU 核数，多核 CPU 同理。
在 Linux 系统下，使用 top 命令查看 CPU 使用情况，可以得到如下信息：
top - 13:58:53 up 280 days, 22:57, 3 users, load average: 1.22, 1.29, 1.18
这些字段显示：
· 当前时间
· 系统已运行的时间
· 当前登录用户的数量
· 相应最近1、5和15分钟内的平均负载。
Tasks: 161 total, 1 running, 160 sleeping, 0 stopped, 0 zombie
Tasks — 任务（进程），系统现在共有161个进程，其中处于运行中的有1个，160个在休眠（sleep），stopped状态的有0个，zombie状态（僵尸）的有0个
%Cpu(s): 3.6 us, 11.4 sy, 0.0 ni, 84.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
这里显示不同模式下所占cpu时间百分比，这些不同的cpu时间表示：
us(user)：表示 CPU 在用户态运行的时间百分比，通常用户态 CPU 高表示有应用程序比较繁忙。典型的用户态程序包括：数据库、Web 服务器等。
sy(sys)：表示 CPU 在内核态运行的时间百分比（不包括中断），通常内核态 CPU 越低越好，否则表示系统存在某些瓶颈。
ni(nice)：表示用 nice 修正进程优先级的用户态进程执行的 CPU 时间。nice 是一个进程优先级的修正值，如果进程通过它修改了优先级，则会单独统计 CPU 开销。
id(idle)：表示 CPU 处于空闲态的时间占比，此时，CPU 会执行一个特定的虚拟进程，名为 System Idle Process。
wa(iowait)：表示 CPU 在等待 I/O 操作完成所花费的时间，通常该指标越低越好，否则表示 I/O 存在瓶颈，可以用 iostat 等命令做进一步分析。
hi(hardirq)：表示 CPU 处理硬中断所花费的时间。硬中断是由外设硬件（如键盘控制器、硬件传感器等）发出的，需要有中断控制器参与，特点是快速执行。
si(softirq)：表示 CPU 处理软中断所花费的时间。软中断是由软件程序（如网络收发、定时调度等）发出的中断信号，特点是延迟执行。
st(steal)：表示 CPU 被其他虚拟机占用的时间，仅出现在多虚拟机场景。如果该指标过高，可以检查下宿主机或其他虚拟机是否异常。
由于 CPU 有多种非空闲态，因此，CPU 使用率计算公式可以总结为：CPU 使用率 = (1 - 空闲态运行时间/总运行时间) * 100%。
- 根据经验法则， 建议生产系统的 CPU 总使用率不要超过 70%。
平均负载
平均负载是指单位时间内，系统处于运行状态、等待运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
所谓可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。
不可中断进程
不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。
比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。
如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
在 Linux 系统下，使用 top 命令查看平均负载，可以得到如下信息：
load average: 1.09, 1.12, 1.52
这 3 个数字分别表示 1分钟、5分钟、15分钟内系统的平均负载。该值越小，表示系统工作量越少，负荷越低；反之负荷越高。
平均负载为多少更合理？
理想情况下，每个 CPU 应该满负荷工作，并且没有等待进程，此时，平均负载 = CPU 逻辑核数。
但是，在实际生产系统中，不建议系统满负荷运行。
- 通用的经验法则是：平均负载 = 0.7 * CPU 逻辑核数。
当平均负载持续大于 0.7 * CPU 逻辑核数，就需要开始调查原因，防止系统恶化； 当平均负载持续大于 1.0 * CPU
逻辑核数，必须寻找解决办法，降低平均负载； 当平均负载持续大于 3.0 * CPU 逻辑核数，系统变得
非常慢，甚至很难从命令行操作它来试图找出问题的原因，因此修复问题需要的时间会比较长，风险是系统会更饱和并且很有可能会崩溃；
当平均负载持续大于 5.0 * CPU 逻辑核数，表明系统已出现严重问题，长时间未响应，或者接近死机。
除了关注平均负载值本身，我们也应关注平均负载的变化趋势，这包含两层含义。一是 load1、load5、load15 之间的变化趋势；二是历史的变化趋势。
当 load1、load5、load15 三个值非常接近，表明短期内系统负载比较平稳。
此时，应该将其与昨天或上周同时段的历史负载进行比对，观察是否有显著上升。 当 load1 远小于 load5 或 load15
时，表明系统最近 1 分钟的负载在降低，而过去 5 分钟或 15 分钟的平均负载却很高。 当 load1 远大于 load5 或
load15 时，表明系统负载在急剧升高，如果不是临时性抖动，而是持续升高，特别是当 load5 都已超过 0.7 * CPU 逻辑核数
时，应调查原因，降低系统负载。
CPU 使用率与平均负载的关系
CPU 使用率是单位时间内 CPU 繁忙程度的统计。而平均负载不仅包括正在使用 CPU 的进程，还包括等待 CPU 或 I/O 的进程。因此，两者不能等同，有两种常见的场景如下所述：
- CPU 密集型应用，大量进程在等待或使用 CPU，此时 CPU 使用率与平均负载呈正相关状态。
- I/O 密集型应用，大量进程在等待I/O，此时平均负载会升高，但 CPU 使用率不一定很高。
案例分析
机器配置：8CPU，8GB 内存
安装 stress
初始系统资源使用情况
场景一：CPU 密集型
我们在一个终端运行 stress 命令，模拟3个 CPU 使用率 100% 的场景
stress -c 3 -t 600
在第二个终端top 查看结果：
场景二：I/O 密集型
运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync
stress --io 20 -t 100
在第二个终端top 查看结果：
平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出现了瓶颈。
所以，在理解平均负载时，也要注意：
平均负载高有可能是 CPU 密集型进程导致的； 平均负载高并不一定代表 CPU 使用率高； 还有可能是 I/O 繁忙了；
标签：负载,系统,Linux,进程,使用率,平均,CPU 来源： https://blog.csdn.net/fzxwl/article/details/117993424
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。