[Linux] 性能基础之理解Linux系统平均负载和CPU使用率

• 　　appletekimbp:~ apple$ uptime
  
• 　　20:44  up 21 days,  6:41, 2 users, load averages: 2.85 2.33 2.91
  

• 　　20:44                  # 当前时间
  
• 　　up 21 days,  6:41     # 系统运行时间
  
• 　　2 users               # 正在登录用户数
  
• 
  
• 　　# 系统的平均负载，分别是1分钟、5分钟、15分钟内系统的平均负载
  
• 　　load averages: 2.85 2.33 2.91
  

　　CPU 负载值在 Linux 系统中表示正在运行，处于可运行状态的平均作业数（读取一组与流程执行线程对应的机器语言的程序指令），或者非常重要，休眠但不可中断（不可交错的休眠状态））。也就是说，要计算 CPU 负载的值，只考虑正在运行或等待分配 CPU 时间的进程。不考虑正常的休眠过程（休眠状态），僵尸或停止的过程。

　　进程状态代码 R 正在运行或可运行（在运行队列中） D 不间断休眠（通常为IO） S 可中断休眠（等待事件完成） Z 失效/僵尸，终止但未被其父 T 停止，由作业控制停止信号或因为它被追踪 [...]

• 　　0.00：没有任何作业正在运行或等待 CPU 执行，即 CPU 完全空闲。因此，如果正在运行的程序（进程）需要执行任务，它会向 CPU 请求操作系统，并立即为该进程分配 CPU 时间，因为没有其他进程在竞争它。
  
• 　　0.50：没有任何作业在等待，但 CPU 正在处理以前的作业，并且它正在以 50％ 的容量进行处理。在这种情况下，操作系统还可以立即将 CPU 时间分配给其他进程，而无需将其置于保持状态。
  
• 　　1.00：队列中没有作业，但 CPU 正在以 100％ 的容量处理先前的作业，因此如果新进程请求 CPU 时间，则必须将其保留到另一个作业完成或当前 CPU 插槽时间（例如，CPU tick）到期，操作系统决定哪一个是下一个给定的进程优先级。
  
• 　　1.50：CPU 工作在其容量的 100％，15个工作中有5个请求CPU时间，即 33.33％，必须排队等待其他人耗尽他们分配的时间。因此，一旦超过1.0 的阈值，就可以说系统过载，因为它不能立即处理所请求的 100％ 的工作。
  

　　在具有多个处理器或核心（多个逻辑 CPU）的系统中，CPU 负载值的含义取决于系统中存在的处理器数量。因此，具有4  个处理器的计算机在达到4.00的负载之前将不会以100％使用，因此在解释由 top，htop 或正常运行时间等命令提供的3个负载值时，你必须要做的第一件事 就是将它们分开。系统中存在的逻辑CPU数量，并从中得出结论。

　　如果我们观察在给定时间间隔内通过 CPU 的不同进程，则利用率百分比将表示相对于 CPU 执行与每个进程相对应的指令的那个时间间隔的时间部分。但这种计算只运行的进程，而不是那些正在等待，无论它们是在队列（可运行状态）还是休眠但不可中断（例如在等待输入/输出操作的结束）被认为。 因此，这个指标可以让我们了解哪些进程最大程度地挤压 CPU，但是如果系统状态过载或者未充分利用，则不能给出真实的系统状态图。

• 　　CPU 密集型进程，使用大量 CPU 会导致平均负载升高，这时候两者是一致的。
  
• 　　I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高。
  
• 　　大量等待 CPU 的进程调度也会导致平均负载很高，此时的 CPU 使用率也会比较高。
  

• 　　>=0.70：没有任何反应，但有必要监控 CPU 负载。如果在一段时间内保持这种状态，就必须在事情变得更糟之前进行调查。
  
• 　　>=1.00：存在问题，您必须找到并修复它，否则系统负载的主要高峰将导致您的应用程序变慢或无响应。
  
• 　　>=3.00：你的系统变得 非常慢。甚至很难从命令行操作它来试图找出问题的原因，因此修复问题需要的时间比我们之前采取的行动要长。你冒的风险是系统会更饱和并且肯定会崩溃。
  
• 　　>=5.00：你可能无法恢复系统。你可以等待奇迹自发降低负载，或者如果你知道发生了什么并且可以负担得起，你可以在控制台中启动 kill-9<process_name> 之类的命令 ，并祈求它运行在某些时候，以减轻系统负荷并重新获得其控制权。否则，你肯定别无选择，只能重新启动计算机。