RegCM、MPICH、计算机集群

Question

背景： 我需要使用超过 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

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

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

所有节点都从自己的硬盘启动。
node0 在 Ubuntu 16.04 LTS 上运行。
其他节点运行 Ubuntu 14.04 LTS。

我是如何开始的？ 我按照here中的步骤操作。

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

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

本次测试结果
单节点处理速度更快

---

现在我对node0进行了同样的尝试（有关计算机规格，请参见上文）

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

结果摘要如下： - 首先只使用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) = 最大磁盘写入速度node0/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 作为主机传递；和 2. 传递 node0,node1 作为主机----注意顺序。

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

我还进行了另一组测试，这次使用的是主机文件（命名为主机列表），其内容是：

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 个内核。为什么会这样？

Answer 1

_{虽然上面提到的联系地区或国家 HPC 中心的建议是公平且值得遵循的，但我可以想象，如果截止日期和预算都被授予，获得一些显着的处理配额会有多难对你不利}

---

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

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

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

3：
可用于实现时间效率的最佳内核数是多少？
首先确定最大的过程-瓶颈观察到{ CPU | MEMORY | LAN | fileIO | a-poor-algorithm }，只有下一步寻找最佳步骤以提高速度（保持迭代在这个@上前进987654328@-chain，而性能仍在增长）。切勿尝试以相反的顺序进行。

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

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

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

---

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

在做任何进一步的步骤之前，尽力尝试well understand both the original Amdahl's Law + its new overhead-strict re-formulation

如果没有掌握这个基础，没有其他方法可以帮助你决定performance-hunt-dilemma-( duality )-of-fair-accounting-of-both-{ -costs +benefits }强>

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

如果您可以更改代码，take a look on sample Test-cases 演示了一种主要方法的方法，用于隔离实际瓶颈的根本原因并保留 { cause: remedy, ... } 迭代作为修复方法可以做得更好的事情。

更广阔的视野：

从0.8 [TB]磁盘文件和get ( N - 1 )刚刚发送的get ( N - 1 )读取( N )块需要多长时间跨局域网？

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

           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

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

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

我喜欢表格，可以看到数量级，有人可能更喜欢视觉形式，其中颜色“转变”-范式，最初基于 Peter Norvig 的帖子：

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

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

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

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