如何理解操作系统负载均衡和运行队列（CPU利用率）(文档 ID 2221159.1)

适用于：

Linux OS - Version Oracle Linux 5.2 to OracleLinux 7.3 [Release OL5U2 to OL7U3]
Linux x86-64
Linux x86

用途：

如何理解操作系统负载均衡和运行队列

解决方案：

首先让我们了解什么是负载均衡：

负载平均值是运行队列（状态R）或等待磁盘I / O（状态D）在1,5和15分钟内平均的作业数。

uptime / top命令的输出示例：

# uptime
11:49:14 up 25 days, 5:56, 68 users, load average: 0.03, 0.13, 0.47 <-----

# top -b -n 1
top - 11:49:34 up 25 days, 5:56, 68 users, load average: 0.09, 0.14, 0.46 <-----
Tasks: 456 total, 1 running, 445 sleeping, 10 stopped, 0 zombie
Cpu(s): 0.8%us, 0.4%sy, 0.0%ni, 98.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 141823788k total, 140483388k used, 1340400k free, 313452k buffers
Swap: 16772092k total, 0k used, 16772092k free, 134695384k cached

经验法则是：

单核系统 - 如果负载平均值为1.00，意味着系统被充分利用，如果有更多任务传入，它们将排队等待排除

单核系统 - 如果负载平均值为2.00，则意味着系统已经被使用，并且一些任务已经排队等待执行

多核系统（4核） - 如果负载平均为1.00，这意味着系统使用他的CPU能力的1/4，一个任务正在运行，还有3个核处于“空闲”阶段

多核系统（4核） - 如果负载平均为4.00，这意味着系统使用所有4个核，并且它指示系统被充分利用

在上述情况下，还有一些顶部空间还留下来吗？ - 通常没有 - 如果负载平均值接近系统的核心数量 - 应该检查操作系统，以查找实际瓶颈和失误的调整，或者操作系统未正确扩展以服务任何APP / DB任务。

如何在活动操作系统上计算负载平均值？ - 为此，我们需要通过vmstat命令找到可用的运行队列：

空闲系统（8核）

vmstat 1 6
procs -----------memory---------- ---swap-- -----io---- --system-------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0
0 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0
0 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0
0 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0
0 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0
0 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0

活动系统（8核）

vmstat 1 6
procs -----------memory---------- ---swap-- -----io---- --system-------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 0 1674516 316588 134364752 0 0 0 1 0 0 1 0 99 0 0
7 0 0 1674624 316588 134364752 0 0 0 0 195 307 0 0 100 0 0
2 0 0 1674624 316596 134364752 0 0 0 12 168 302 0 0 100 0 0
6 0 0 1674624 316596 134364752 0 0 0 0 198 331 0 0 100 0 0
1 0 0 1674624 316596 134364752 0 0 0 0 206 356 0 0 100 0 0
8 0 0 1674624 316600 134364736 0 0 0 12 197 333 0 0 100 0 0

上面的输出是示例 - 第一个示出了当前运行队列（r）为0，其中活动系统运行队列在6个探测中从1跳到8。

什么是运行队列？

run-queue：活动（正在运行）和排队的进程数。

在第二个例子中，当系统处于活动状态时，我们看到运行队列为8 - 这已经是最大上限系统，具有8个内核应该运行。

当然，运行队列可能显示36或甚至101的值 - 如果第一个36有36个核心，第二个101我们有超过101个核心。

运行队列应始终低于/等于系统上安装的核心数 - 当然运行队列100可以在只有8个核心的系统上可见 - 这将意味着8个进程主动由CPU服务，其余92个进程排队并等待执行。

如果运行队列高于安装的CPU核心，则应该检查APP / DB性能和缺少的调整，或者可以指示系统未正确扩展以服务此类运行队列/负载。

就像负载平均运行队列应该保持在安装的核心数以下 - 不保持这个值低于最大阈值将导致减速/挂起或驱逐情况（如果系统是HA启用）作为操作系统可以简单地在磁盘/网络层上排队心跳监控因为其忙于服务其他任务。

高负载平均和运行队列将导致突然崩溃/挂起的情况 - 它值得通过第三方监控工具主动监控这两个值，并在运行队列/负载平均占用超过70％的实际CPU资源时发出警报。

Load Average也采用的第二个重要列是vmstat中的'b'状态，它解释了阻塞状态进程- 这可以轻松地解释为状态D进程（等待后端IO完成 - 通常是存储活动）

如果负载平均值高，并且没有进程正在活动，并且vmstat显示异常的'b'状态值，那么它来检查SAN性能或验证任何操作系统组件的时候，如ISCSI / NFS / NIC / HBA，可能会遇到一些问题，在Linux上导致严重阻塞状态。

例如，NFS服务器可能在CPU级别上忙，并且所有客户端（Linux）进程/任务将在状态d（b）中排队，导致“排队”，随后可能随后释放大量运行队列，因为所有进程等待后端IO完成后，他们可能再次切换到运行导致大量运行队列，这之后可能导致挂起/恐慌状态或导致驱逐案例。

要快速列出运行/阻塞的进程，请使用以下ps命令：

# ps r -Af

还验证操作系统CPU是否正在服务活动用户（US）空间使用以下命令示例：

# sar -P ALL 1
Linux 3.8.13-118.13.3.el6uek.x86_64 (lnx-ovm-san2076.uk.oracle.com) 01/08/2017_x86_64_ (8 CPU)

02:40:38 PMCPU %user %nice %system %iowait %steal %idle
02:40:39 PM all 12.62 0.00 0.12 6.88 0.00 80.38
02:40:39 PM 0 0.00 0.00 0.00 54.55 0.00 45.45
02:40:39 PM 1 0.00 0.00 0.00 0.00 0.00 100.00
02:40:39 PM 2 0.99 0.00 0.00 0.00 0.00 99.01
02:40:39 PM 3 0.00 0.00 0.00 0.00 0.00 100.00
02:40:39 PM 4 100.00 0.00 0.00 0.00 0.00 0.00
02:40:39 PM 5 0.98 0.00 0.98 0.00 0.00 98.04
02:40:39 PM 6 0.00 0.00 0.00 0.00 0.00 100.00
02:40:39 PM 7 0.00 0.00 0.00 0.00 0.00 100.00

Average: CPU%user %nice %system %iowait %steal %idle
Average: all 12.63 0.00 0.13 6.00 0.00 81.24
Average: 0 0.00 0.00 0.00 45.23 0.00 54.77
Average: 1 0.50 0.00 0.00 3.00 0.00 96.50
Average: 2 0.50 0.00 0.00 0.00 0.00 99.50
Average: 3 0.00 0.00 0.00 0.50 0.00 99.50
Average: 4 100.00 0.00 0.00 0.00 0.00 0.00
Average: 5 0.50 0.00 0.50 0.00 0.00 99.00
Average: 6 0.00 0.00 0.00 0.00 0.00 100.00
Average: 7 0.00 0.00 0.00 0.00 0.00 100.00

# mpstat -P ALL
Linux 3.8.13-118.13.3.el6uek.x86_64 (lnx-ovm-san2076.uk.oracle.com) 01/08/2017_x86_64_ (8 CPU)

02:41:26 PMCPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
02:41:26 PM all 0.79 0.00 0.10 1.18 0.00 0.02 0.00 0.00 97.92
02:41:26 PM 0 0.94 0.00 0.14 2.84 0.00 0.02 0.00 0.00 96.06
02:41:26 PM 1 0.94 0.00 0.14 2.70 0.00 0.02 0.00 0.00 96.20
02:41:26 PM 2 0.93 0.00 0.14 1.13 0.00 0.03 0.00 0.00 97.77
02:41:26 PM 3 0.94 0.00 0.13 2.71 0.00 0.02 0.00 0.00 96.20
02:41:26 PM 4 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.28
02:41:26 PM 5 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27
02:41:26 PM 6 0.65 0.00 0.06 0.01 0.00 0.01 0.00 0.00 99.27
02:41:26 PM 7 0.64 0.00 0.05 0.01 0.00 0.01 0.00 0.00 99.29

注意

默认情况下，oswatcher捕获mpstat/vmstat/top，有关更多详细信息，请检查：1531223.1，此外，OS还会捕获/var/log/sa中的标准SAR数据

如果系统运行的上限是8个运行的进程，负载平均值在8核系统上相同的值？ - 不是

系统应该正确扩展，并且不超过其可能性的70％ - 这对于任何新的任务都有一定的要求 - 这对于HA启用的服务器和具有任何高端IO/网络的系统尤其重要，可能由活动操作系统意外排队。对于这个深入检查应该由APP / DB团队来验证是什么在操作系统下运行。

只有APP / DB任务导致高运行队列/负载平均？ - 不是

某些操作系统任务可能会导致高运行队列或负载平均 - 但这些都是很少见的情况。

在这种情况下，top命令将有助于监视US / SY / NI / ID / WA / HI / SI / ST值，并专注于SY（系统）部分，告诉处理器在内核级别花费多少时间。确保其总是低于实际的US（用户）利用率，并且SY不是使用例如20-30％的CPU（取决于CPU设置和实际情况）。

例如，高SY可能在高IO /网络操作期间或在内存不足情况期间可见。