iowait 绑定服务器 - 负载计算和进程调度

iowait 绑定服务器 - 负载计算和进程调度

我正在编写一个脚本,该脚本针对装满驱动器的磁盘架运行坏块,并且我试图了解产生的服务器负载以及在这种用例中服务器负载在什么时候至关重要。

我通常坚持一般准则,即服务器负载<=核心数是理想的,而<=2x核心数通常不会导致显着的性能下降,除非服务实时敏感的工作负载,但我不认为这种普遍性适用于这种用例。

在下面的屏幕截图中,您可以看到我正在对 8 个设备运行坏块,相关负载约为 8,我理解这是因为由于坏块的性质,队列中有 8 个进程实际上停滞了。但只有 2 个 CPU 核心受到这些进程的 io 限制。所以有几个问题:

1.> 我尝试同时进行这么多测试是否会减慢我的坏块测试速度?如果是这样,为什么它不使用可用的内核?

2.> 我假设这种通常“非理想”的 CPU 负载不会影响其他请求的服务,比如说从服务器上的其他驱动器共享的数据?(假设 sas 卡没有瓶颈)因为 2 个核心是空闲的并且可用,对吗?

3.> 如果 2 个核心能够支持 8 个 badblock 进程而不会互相影响(如图所示),那么为什么 2 个 badblock 进程使用一个核心,而第 3 个核心导致第 2 个核心被使用,调度/优化意味着假设 8 个进程应该消耗 3-4 个核心,而不是 2 个调度是最佳的,不是吗?

平台是 Centos 7 |--| 处理器是 Intel e3-1220 v2(四核,无超线程)|--| 磁盘架通过外部 SAS HBA(非 raid)连接到服务器

top - 16:03:12 up 6 days, 15:21, 13 users,  load average: 7.84, 7.52, 6.67
Tasks: 171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie
%Cpu0  :  0.0 us,  0.0 sy,  0.0 ni, 99.7 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.3 us,  6.0 sy,  0.0 ni,  0.0 id, 93.6 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni, 95.7 id, 4.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  2.3 us,  3.0 sy,  0.0 ni,  0.0 id, 94.7 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  7978820 total,  7516404 free,   252320 used,   210096 buff/cache
KiB Swap:  4194300 total,  4194300 free,        0 used.  7459724 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
22322 root      20   0  122700   9164    832 D   3.3  0.1   18:36.77 badblocks
22394 root      20   0  122700   9164    832 D   1.3  0.1  15:52.98 badblocks
23165 root      20   0  122700   9152    820 D   1.3  0.1   0:36.94 badblocks
23186 root      20   0  122700   5792    808 D   1.3  0.1   0:02.54 badblocks
23193 root      20   0  122700   5004    768 D   1.3  0.1   0:02.17 badblocks
23166 root      20   0  122700   9152    820 D   1.0  0.1   0:36.11 badblocks
23167 root      20   0  122700   9148    820 D   1.0  0.1   0:39.74 badblocks
23194 root      20   0  122700   6584    808 D   1.0  0.1   0:01.47 badblocks

答案1

平均负载和 CPU 利用率

平均负载是衡量 CPU 上可运行任务数量的一个缓慢移动指标。除了,Linux 早期决定也计算不可中断任务,以期捕捉 I/O 负载。 低于 CPU 数量的负载肯定可以运行更多任务,但建议的最大值并不那么明显。

现代系统中的磁盘 I/O 几乎不需要 CPU 参与。因此,iowait 几乎处于空闲状态。用户 + 系统如此之低表明 CPU 在等待非常慢的主轴时几乎无事可做。

此工作负载的并行作业

每个物理主轴限制为一个坏块。多个坏块可能会导致磁盘头来回寻找,从而导致性能不佳。

SAS 卡或存储系统的其他组件也可能存在瓶颈。当您看到 I/O 带宽(可能通过iotop)不再增加时,请使用较少的进程。或者每次只选择 8 个左右作为任意大小的批处理以并行运行(可能使用GNU并行)。

任务调度

任务调度程序正在针对多个方面进行优化。即使在多 CPU 系统中,专注于几个核心也可以使数据在缓存中保持热度,降低空闲核心的速度以节省电量,并且仍然能够处理中断。此外,还需要考虑 NUMA 和 SMT 调度,尽管此 CPU 不具备这些功能。

在这种情况下,您有两个几乎空闲的内核。我希望主机能够相当敏捷。不过,在执行此操作时不要运行太多工作。有限的 I/O 带宽和 IOPS 可能会让 CPU 等待,而工作量却不会增加。

相关内容