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

- ＆GT;我使用mpich v3（我不记得确切的版本号）

依此类推......（node0以外的所有节点都与node1相同。）

所有节点都支持 1 Gbps 以太网卡出于测试目的，我已经建立了一个小型模拟工作，用于分析6天的气候。所有测试模拟都使用相同的参数和模型设置。

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

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

使用Cat 6电缆连接node1和node2，为其分配静态IP-s。（暂时离开node0） - 已编辑/etc/hosts，其中包含IP-s和相应的名称 - node1和node2，如上表所示
使用ssh设置无密码登录 - 成功
在/home/user node1中创建了一个文件夹（在此测试中将是主人）并导出文件夹（/etc/exports），将此文件夹挂载在 {{1}上{/ 1}}中的NFS和node2中已修改的/etc/fstab - 成功

使用两台计算机的14个核心 - 我的node2通过群集 - 成功

我曾使用：regcm，iotop，bmon分别监控磁盘读/写，网络流量和CPU使用情况。


htop

此测试的结果
单个节点处理的计算速度更快

现在我尝试使用$ mpirun -np 14 -hosts node0,node1 ./bin/regcmMPI test.in （请参阅上面的计算机规格）

- ＆GT;我在node0处理SSD - ＆GT;工作正常但问题是在群集中连接时的时间因素。

这里是结果摘要:: - 首先仅使用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 = regcm以秒为单位报告的CPU运行时间

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

a-rt = 以MBps实现的最大LAN速度（接收/发送）

LAN = 最高磁盘写入速度为disk(0 / 1) / node0，以MBps为单位

node1


*注意：

1,0（例如16个核心）意味着： 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

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

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

我们可以看到上面两个选项的LAN使用率和驱动器写入速度明显不同 - 1.将 $ mpirun -np 16 -hosts node0,node1 ./bin/regcmMPI test.in 作为主机传递; 2.将 node1,node0 作为主持人传递----记下订单。

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

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

现在我运行了以下脚本


node0:16 node1:6

报告了CPU运行时 $ mpirun -np 22 -f hostlist ./bin/regcmMPI test.in ，实际运行时间为 101 [s] （1 min 42 sec），实现了LAN速度 102 [s] ，磁盘写入速度大约为 10-15 [MB/s] 。

当我使用相同的主机文件设置并使用20个处理器运行代码时，获得了最佳结果


7 [MB/s]

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

当我将核心从20下降18更改为时，运行时间增加到 CPU runtime : 90 [s] Actual run time : 91 [s] LAN : 10 [MB/s] 。

我尚未将102 [s]连接到系统。

问题：

有没有办法实现更快的计算速度？我做错了吗？

具有14个内核的单台机器的计算时间比具有22个内核或20个内核的集群的计算时间更快。为什么会这样？

可用于实现时间效率的最佳核心数是多少？

如何利用可用资源实现最佳性能？

有没有最好的mpich使用手册可以回答我的问题？（我找不到任何此类信息）

有时使用更少的内核比使用更高的内核提供更快的完成时间，即使我没有使用所有可用的内核，只留下1或2个内核用于操作系统和单个节点中的其他操作。为什么会这样？

Answer 1

_{虽然上面提到的联系地区或国家HPC中心的建议是公平的，值得关注，但我可以想象，如果截止日期和预算都能获得一些非常难以获得的处理配额正在反对你}

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

<强> 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项]

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

之前更进一步，尽量尝试well understand both the original Amdahl's Law + its new overhead-strict re-formulation

如果没有掌握这个基础，没有其他任何东西可以帮助你决定表现 - 狩猎 - 困境 - （二元性） - 公平会计 - 两者 - { -costs +benefits }

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

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

更广泛的观点：

从 ( N ) 磁盘文件及其 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

然而，虽然这些英特尔公布的详细数据影响了任何和所有的绩效计划，但这些数字既没有被授予，也没有成为常数，如Intel warns所发表的评论：

_{＆＃34; 注意：这些值是粗略的近似值。他们依赖核心和UNCORE 频率，内存 SPEEDS， BIOS 设置，数量的DIMM， ETC，ETC。。你的里程可能会有所不同。＆＃34;}

我喜欢桌子，其中可以看到数量级，有人可能更喜欢视觉形式，其中颜色＆＃34;移动＆＃34; -the-paradigm，最初基于Peter Norvig的帖子：

如果我的预算，截止日期和模拟软件允许，我宁愿（性能方面，由于延迟屏蔽和基于数据位置的处理）没有mpich层到最大数量的CPU + MEM - 每个CPU的控制器通道。

对于体系结构优化的处理设计有一个常识，它表明，相同的结果可以在纯{ - {1}} - 代码中接收，甚至 [SERIAL]更快而不是＆＃34;原创＆＃34;中的最佳案例代码或使用硅架构＆＃34;天真＆＃34;编程工具和不正确的范例。

今天系统能够提供广泛的模拟服务。需要这种方式，而不是花费超过收到。

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

RegCM，MPICH，计算机集群

问题：

1 个答案:

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

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

RegCM，MPICH，计算机集群

问题：

1 个答案:

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

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

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

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