![高性能计算的CPU负载](https://linux22.com/image/755118/%E9%AB%98%E6%80%A7%E8%83%BD%E8%AE%A1%E7%AE%97%E7%9A%84CPU%E8%B4%9F%E8%BD%BD.png)
在高性能计算环境下,CPU 负载是否存在合理/安全的水平?
我理解意义的平均负载对于一般的服务器来说,但不知道对于为高性能计算而构建和使用的服务器有什么样的期望。
通常的惯例是否load <= # of cores
适用于这种环境?
我很好奇,因为我的系统特定细节通常load >> # of cores
针对每个节点:
- 24 个物理核心,48 个虚拟核心的超线程(相对较新的硬件)
- 平均负载:通常为 100-300
节点正常运行时间长,通常 CPU 使用率/负载较高。硬件故障很少,尤其是 CPU,但我不知道在高负载下节点的整个生命周期内会发生什么。
示例top
输出:
top - 14:12:53 up 4 days, 5:45, 1 user, load average: 313.33, 418.36, 522.87
Tasks: 501 total, 5 running, 496 sleeping, 0 stopped, 0 zombie
%Cpu(s): 33.5 us, 50.9 sy, 0.0 ni, 15.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 19650371+total, 46456320 free, 43582952 used, 10646443+buff/cache
KiB Swap: 13421772+total, 78065520 free, 56152200 used. 15164291+avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
85642 user 20 0 36.5g 7.6g 245376 S 1566 4.0 1063:21 python
97440 user 20 0 33.1g 5.3g 47460 S 1105 2.8 512:10.86 python
97297 user 20 0 31.0g 4.0g 69828 S 986.4 2.1 430:16.32 python
181854 user 20 0 19.3g 5.0g 19944 R 100.0 2.7 2823:09 python
...
iostat -x 5 3
同一台服务器上的输出:
avg-cpu: %user %nice %system %iowait %steal %idle
50.48 0.00 12.06 0.38 0.00 37.08
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 350.41 705.68 58.12 22.24 2126.25 3393.61 137.36 6.02 74.93 9.10 246.94 1.19 9.56
dm-0 0.00 0.00 4.87 8.70 511.41 516.65 151.59 0.31 22.55 28.40 19.28 2.62 3.56
dm-1 0.00 0.00 403.67 719.23 1614.71 2876.92 8.00 8.83 7.10 7.38 6.95 0.08 9.05
dm-2 0.00 0.00 0.00 0.00 0.02 0.01 65.03 0.00 3.74 3.82 1.00 2.12 0.00
答案1
平均负载显示准备运行的线程队列。在 Linux 中,这还包括等待磁盘的线程。可能发生的情况是,损坏的 NFS 服务器可能会将平均负载增加到疯狂的数字。这并不意味着 CPU 被占用了。
因此,平均负载仅显示故事的一个方面,不能单独考虑,这就是我要求top
输出的原因。
有些工作负载不是可并行的。这意味着所有步骤将依次在同一核心上运行。实际问题通常是部分可并行的。
在性能方面,你有一些目标和限制。例如低延迟、吞吐量、成本(初始成本和运营成本)...
如果您对吞吐量和低成本感兴趣,那么拥有高队列可能是正常的。您的所有 CPU 核心将始终处于 100% 使用率。
答案2
平均负载只是一种症状,是一种操作系统可以轻松报告的有用指标。医生无法仅凭发烧症状就诊断出人类患者出了什么问题,他们对正在发生的事情有更多疑问。对于计算机患者,同样需要更多关于其表现的背景信息。
不同系统的平均负载可能存在很大差异。有些平台不会在平均负载中报告可能执行 I/O 的任务,这与 Linux 的做法不同。有些主机的每核平均负载可以达到几十个,但不会崩溃。有些应用程序对延迟非常敏感,如果每核负载大于 1,用户响应时间就会变差。
除了操作系统级别的指标外,还要收集特定于应用程序的性能基准,并随时间推移分析其趋势。一般示例:
- HPC 系统每个 CPU 核心执行多少个操作?
- 用户请求响应时间是否可以接受?
- 数据库每秒有多少个查询?
- 该系统是否能跟上典型的批处理?
要将操作系统指标纳入上下文,有必要对系统所做的有用工作进行一些衡量。即使在平均负载相对较高的情况下,您的系统似乎也在做有用的工作。与分叉炸弹相比,分叉炸弹会将负载推高到无法使用的高水平,但作为拒绝服务攻击,它没有任何用处。