1

背景： 我需要使用大量800 [GB]数据（过去 50 年和未来 80 年）进行大量的气候模拟计算。

为此，我使用基于 linux 的 RegCM4。我正在使用 Ubuntu。我们拥有的最强大的系统有一些具有 20 个内核的 Intel XEON 处理器。此外，我们还有近 20 个更小、功能更弱的 Intel i7 八核处理器。

要运行模拟，单个系统需要一个多月的时间。

所以，我一直在尝试建立具有可用资源的计算机集群。
（仅供参考：RegCM 允许并行处理mpi。）

眼镜：：

Computer socket cores_per_socket threads_per_core CPUs   RAM   Hard_drives 
node0    1      10               2                20   32 GB   256 GB  + 2 TB-HDD
node1    1       4               2                 8    8 GB             1 TB-HDD
node2    1       4               2                 8    8 GB             1 TB-HDD

-> 我使用mpichv3（我不记得确切的版本号。）

以此类推...（除 之外的所有节点node0都与 相同node1。）
所有节点都1 Gbps支持以太网卡。
出于测试目的，我建立了一个小型模拟工作来分析 6 天的气候。所有测试模拟都使用相同的参数和模型设置。

所有节点都从它们自己的 HDD 引导。
node0在 Ubuntu 16.04 LTS 上运行。
其他节点运行 Ubuntu 14.04 LTS。

我是怎么开始的？ 我按照这里的步骤进行操作。

  1. 连接node1并node2使用 Cat 6 电缆，为它们分配静态 IP。（暂时离开node0） -/etc/hosts使用 IP-s 和相应的名称进行编辑 -node1如上node2表所示
  2. 在两者中都使用 ssh 设置无密码登录 - 成功
  3. /home/user在 in中创建了一个文件夹node1（将在此测试中为主）并导出文件夹（/etc/exports），将此文件夹安装NFS到并在node2其中编辑- 成功/etc/fstabnode2
  4. 使用两台机器的 14 个核心运行我regcm的集群 - 成功
  5. 我使用 : iotop, bmon,htop分别监控磁盘读/写、网络流量和 CPU 使用率。

$ mpirun -np 14 -hosts node0,node1 ./bin/regcmMPI test.in

此测试的结果
单节点处理上的更快计算

现在我尝试了同样的node0 方法（参见上面的计算机规格）

-> 我正在开发node0.
-> 工作正常，但问题是在集群中连接时的时间因素。

以下是结果摘要:: - 首次使用node0- 不使用集群

$ mpirun -np 20 ./bin/regcmMPI test.in

nodes   no.of_cores_used    run_time_reported_by_regcm_in_sec   actual time taken in sec (approx)
node0   20                  59.58                                60
node0   16                  65.35                                66
node0   14                  73.33                                74

这没关系

现在，使用集群
（使用以下参考来理解下表）：

rt= regcm 以秒为单位报告的 CPU 运行时间

a-rt=以秒为单位的实际时间（大约）

LAN=以 MBps 为单位达到的最大 LAN 速度（接收/发送）

disk(0 / 1)=最大磁盘写入速度 at node0/ at node1 MBps

nodes*  cores   rt      a-rt    LAN     disk(  0 /  1 )
1,0    16       148     176     100/30        90 / 50
0,1    16       145     146      30/30         6 /  0
1,0    14       116     143     100/25        85 / 75
0,1    14       121     121      20/20         7 /  0

*笔记：

1,0（例如 16 核）意味着：$ mpirun -np 16 -hosts node1,node0 ./bin/regcmMPI test.in

0,1（例如 16 核）意味着：$ mpirun -np 16 -hosts node0,node1 ./bin/regcmMPI test.in

实际运行时间是使用 regcm 报告的开始和结束时间手动计算的。

我们可以在上面看到 LAN 使用和驱动器写入速度对于两个选项有显着差异 - 1.node1,node0作为主机传递；node0,node12.作为主机传递----注意顺序。

此外，在单节点中运行的时间比在集群中运行的时间要快。为什么 ？

我还进行了另一组测试，这次使用的是 hostfile（名为 hostlist），其内容是：

node0:16
node1:6

现在我运行了以下脚本

$ mpirun -np 22 -f hostlist ./bin/regcmMPI test.in

报告 CPU 运行时间101 [s]，实际运行时间为1 min 42 sec( 102 [s])，达到的 LAN 速度约为10-15 [MB/s]，磁盘写入速度约为7 [MB/s]。

当我使用相同的主机文件设置并使用 20 个处理器运行代码时获得了最好的结果，因此订阅不足

$ mpirun -np 20 -f hostlist ./bin/regcmMPI test.in

CPU runtime     : 90 [s]
Actual run time : 91 [s]
LAN             : 10 [MB/s]

当我将核心从 20 个更改为 18 个时，运行时间增加到102 [s].

我还没有连接node2到系统。

问题：

  1. 有没有办法实现更快的计算速度？难道我做错了什么 ？
  2. 单机 14 核的计算时间比 22 核或 20 核的集群要快。为什么会这样？
  3. 可用于实现时间效率的最佳内核数量是多少？
  4. 如何利用可用资源实现最佳性能？
  5. 有没有最好的 mpich 使用手册可以回答我的问题？（我找不到任何此类信息）
  6. 有时使用更少的内核比使用更高的内核提供更快的完成时间，即使我没有使用所有可用的内核，在单个节点中为操作系统和其他操作留下 1 或 2 个内核。为什么会这样？
4

1 回答 1

0

虽然上面提到的联系区域或国家 HPC 中心的建议是公平且值得遵循的，但我可以想象，如果截止日期和预算都对您不利，那么获得一些非凡的处理配额会变得多么困难

简介：
关于一个尚未隐藏的复杂系统的问题的简化答案：

1：
有没有办法实现更快的计算速度？
是的。
我做错了吗？
不是直接的。

2：14
核单机计算时间比22核或20核集群快。为什么会这样？
你付出的比得到的多。就这么简单。NFS - 文件系统的网络分布式抽象是可能的，但如果性能开始成为最终目标，您需要付出巨大的成本才能轻松使用它。一般来说，所有支付的各种额外成本（数据分发 + 高附加开销）的总和都高于可[PARALLEL]分配工作负载在少量 CPU_cores 上的净效应，实际减速而不是加速出现。这是一个常见的主要嫌疑人（更不用说在 BIOS 本身中关闭超线程以用于计算密集型工作负载）。

3：可用于实现时间效率
的最佳内核数是多少？首先确定观察到
的最大流程瓶颈{ CPU | MEMORY | LAN | fileIO | a-poor-algorithm }，然后再寻找提高速度的最佳步骤（在此链上继续迭代前进，同时性能仍在增长）。{ cause: remedy }切勿尝试以相反的顺序进行。

4：
如何利用可用资源实现最佳性能？
这是最有趣的，需要做更多的工作（参考下文）。

5：
有没有最好的mpich使用手册可以回答我的问题？
LAN 电缆没有这样的颜色，它决定了它的实际速度和性能，或者保证它对某些特定用途的适用性，但整体系统架构确实很重要。

6：
有时使用更少的内核比使用更高的内核提供更快的完成时间，即使我没有使用所有可用的内核，在单个节点中为操作系统和其他操作留下 1 或 2 个内核。为什么会这样？
参考。[以上第2项]

解决方案：
对于这种设计困境，人们总能做些什么？

在做任何进一步的步骤之前，尽你最大的努力去理解原来的阿姆达尔定律+ 它的新的开销严格的重新制定

如果没有掌握这个基础，没有其他方法可以帮助您决定性能狩猎困境-（对偶性）-of-fair-accounting-of-both-{ -costs +benefits }

狭隘的观点：
更喜欢测试而不是猜测。（+1 用于运行测试）
mpich是一种用于分发代码以及用于所有相关流程管理和同步的工具。虽然天气模拟可能享有良好的影响局部性（较少的进程间通信和同步是强制性的，但实际代码决定了实际发生了多少）仍然与数据相关的传输成本将占主导地位（参考下文数量级）。如果您无法修改代码，则必须忍受它，并且可能只是尝试更改硬件，以调解流程（如果基准测试支持并且预算允许，从 1 Gbps 接口到 10 GBE 到 40 GBE 结构）。

如果您可以更改代码，请查看示例测试用例，该示例测试用例作为一种主要方法来隔离实际瓶颈的根本原因，并将{ cause: remedy, ... }迭代作为一种解决问题的方法，使其变得更好。

更广阔的视野：

从磁盘文件中读取( N )块以及它们刚刚通过 LAN发送需要多长时间？0.8 [TB]get ( N - 1 )

为了粗略估计，让我们刷新一些关于这些事情实际如何工作的事实：

           0.5 ns - CPU L1 dCACHE reference
           1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance
           5   ns - CPU L1 iCACHE Branch mispredict
           7   ns - CPU L2  CACHE reference
          71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
         100   ns - MUTEX lock/unlock
         100   ns - own DDR MEMORY reference
         135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
         202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
         325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
      10,000   ns - Compress 1K bytes with Zippy PROCESS
      20,000   ns - Send 2K bytes over 1 Gbps NETWORK
     250,000   ns - Read 1 MB sequentially from MEMORY
     500,000   ns - Round trip within a same DataCenter
  10,000,000   ns - DISK seek
  10,000,000   ns - Read 1 MB sequentially from NETWORK
  30,000,000   ns - Read 1 MB sequentially from DISK
 150,000,000   ns - Send a NETWORK packet CA -> Netherlands
|   |   |   |
|   |   | ns|
|   | us|
| ms|

处理器的主要内部（实际上是 NUMA）架构有很大不同：

Core i7 Xeon 5500 Series Data Source Latency (approximate)               [Pg. 22]

local  L1 CACHE hit,                              ~4 cycles (   2.1 -  1.2 ns )
local  L2 CACHE hit,                             ~10 cycles (   5.3 -  3.0 ns )
local  L3 CACHE hit, line unshared               ~40 cycles (  21.4 - 12.0 ns )
local  L3 CACHE hit, shared line in another core ~65 cycles (  34.8 - 19.5 ns )
local  L3 CACHE hit, modified in another core    ~75 cycles (  40.2 - 22.5 ns )

remote L3 CACHE (Ref: Fig.1 [Pg. 5])        ~100-300 cycles ( 160.7 - 30.0 ns )

local  DRAM                                                   ~60 ns
remote DRAM                                                  ~100 ns

然而，尽管英特尔公布的这些细节数据会影响任何和所有的性能规划，但这些数据既不是理所当然的，也不是不变的，正如英特尔在发表的评论中警告的那样：

“注意：这些值是粗略的近似值。它们取决于核心和非核心频率、内存速度、 BIOS设置、DIMM数量等。您的里程可能会有所不同。 ”

我喜欢这张桌子，可以看到数量级，有人可能更喜欢一种视觉形式，其中颜色“转变”——范式，最初基于 Peter Norvig 的帖子： https://i.stack.imgur.com/a7jWu.png

如果我的预算、期限和模拟软件允许，我更愿意（在性能方面，由于延迟屏蔽和基于数据局部性的处理）在没有mpich层的情况下进入每个 CPU 的最大 CPU + MEM 控制器通道数。

根据架构优化处理设计的常识，结果表明，可以在纯代码中接收相同的结果，[SERIAL]甚至比“原始”代码中的最佳情况~50x ~ 100x更快，或者如果使用“幼稚”的硅架构编程工具和不恰当的范例。

今天的系统能够以这种方式满足大量模拟的需求，而不会花费超过收到的费用。

希望你的条件也能让你聪明地进入这个性能次要的方向，将模拟运行时间缩短到不到一个月的时间。

于 2017-12-01T18:21:50.767 回答