我有大量的小工作需要我去处理。如果我在6核Xeon Broadwell上运行它们,它至少使用80-90%的userland CPU运行。
如果我在一个带有2X16核心CPU Broadwell的盒子上运行相同的分配,如果我缩放作业的数量,我将得到80%的系统CPU,使用,并且这个值仅是单个6核CPU的3倍,尽管有5倍的核心和更快的时钟。
有什么改进的建议吗?
如果作业小于一定的大小,如果它们运行在稍微大一点的数据集上,系统CPU的使用就没有那么高,那么问题就变得特别严重--这使我怀疑BSD产生进程的速度是有限度的。
如下所示
/usr/share/dtrace/toolkit/procsystime给出了它在2x16核心机器上的顶级条目。
readlink 80898169570
select 128032327883
execve 215209078214
wait4 2127022159693
read 2545974471446在六台核心机器上
_umtx_op 5997915963
select 8746697465
read 59777849114
wait4 61693132566这似乎不足以解释这种非线性比例的差异。
当系统处于这种负载下时,在循环中运行uname需要每次执行半秒钟,而当机器处于空闲状态时则需要毫秒。这里似乎存在着某种核心问题
发布于 2016-11-13 18:37:49
分析将显示占用CPU时间的内容。由于在系统中花费了大量的时间,专注于系统调用可能会发现它。
对此有帮助。/usr/share/dtrace/toolkit/procsystime将通过系统调用显示CPU时间。如果您需要更多的细节,作者有用于火焰图可视化的工具。
发布于 2017-01-26 10:01:17
在试图跟踪这一问题的根源并发现许多不一致之后,我观察到,如果CPU负载超过50%,系统时间就会迅速增加。因此,我尝试在bios中禁用超线程,问题就消失了,机器的吞吐量大大提高了。
显然,BSD和超线程并不能很好地发挥作用,至少对于这种类型的工作负载是如此。一旦超线程被禁用,由此产生的吞吐量增加了大约120%。
https://serverfault.com/questions/814643
复制相似问题