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

Question

我正在编写一个脚本，它在满是驱动器的磁盘货架上运行坏块，并且我正在试图了解所开发的服务器负载，以及在这个使用过程中，服务器负载在什么时候是至关重要的。

我通常坚持具有服务器负载<=#of_cores是理想的一般准则，而<=2x #of_cores一般不会导致显著的性能下降，除非为实时敏感的工作负载提供服务，但我认为这种用法不适用于通用性。

在下面的屏幕截图中，您可以看到我正在针对8个设备运行坏块--相关的负载是~8，我理解这一点，因为由于坏块的性质，队列中有8个进程有效地停滞了。但是只有2个cpu核被这些进程覆盖。所以有几个问题：

1.>，我是不是放慢了我的坏块，测试我的尝试这么多同时测试，如果是的话，它为什么不使用可用的核心？

2.>我假设这种“非理想”的cpu负载不会影响服务其他请求，比如服务器上其他驱动器共享的数据？(假设sas卡上没有瓶颈)因为两个核心是免费的和可用的，对吗？

3.>如果两个核心能够支持8个坏块进程而不相互影响(如图所示)，为什么两个坏块进程使用一个核心，而第三个核心导致第二个核心被利用，那么调度/优化将意味着一个假定8个进程应该消耗3-4个核心，而不是2个最优调度。

该平台是Centos 7双机

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

Answer 1

负载平均和

利用率

负载平均是CPU上可运行任务数量的缓慢移动度量。除了，低于CPU数量的在Linux早期，为了捕捉I/O负载，Linux还决定计算不可中断的任务。负载肯定可以运行更多的任务，但推荐的最大值并不明显。

在现代系统中，磁盘I/O需要最少的CPU参与。所以，我们几乎无所事事。用户+系统处于如此低的位置，这表明CPU在等待非常慢的纺锤体时没有什么可做的。

此工作负载的

并行作业

限制每个物理主轴一个坏块。多重可能会来回寻找磁盘头，从而导致糟糕的性能。

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

任务调度

任务调度程序正在为几个方面进行优化。即使在多CPU系统中，集中在几个核上也可以使数据保持在缓存中，为节省电力而关闭空闲核，并且仍然能够处理中断。另外，NUMA和SMT调度考虑因素，尽管这个CPU没有这些特性。

在这种情况下，您有两个几乎空闲的核心。我想主人一定会很机灵。不过，在你做这件事的时候，不要再做更多的工作。有限的I/O带宽和IOPS可以让CPU等待，而完成的工作不会增加。