关于HPC上SLURM的问题

Question

我有几个关于HPC的问题。我有一个带有串行和并行段的代码。并行部分在不同的内存块上工作，并且在某些时候它们可以相互通信。为此，我在我们的集群上使用了MPI。 SLURM是资源管理器。以下是集群中节点的规格。

规格的节点：

Processor: 2x Intel Xeon E5-2690 (totally 16 cores 32 thread) 
Memory : 256 GB 1600MHz ECC 
Disk : 2 x 600 GB 2.5" SAS (configured with raid 1) 

问题：

1）请在一个节点共享相同的内存（RAM）中的所有核心？如果是，请让所有内核以相同的速度访问内存？

2）考虑的情况下：

--nodes = 1 
--ntasks-per-node = 1 
--cpus-per-task = 16 (all cores on a node) 

如果所有内核共享相同的存储器（取决于答复问题1）将所有核心被使用或它们中的15因为OpenMP的休眠状态（用于共享内存）是不曾用过？ 3）如果需要的内存少于一个节点的总内存，使用单个节点不是更好吗，使用OpenMP来实现核心级并行性，并避免由于节点间通信造成的时间损失？也就是说，使用这种

--nodes = 1 
--ntasks-per-core = 1 

，而不是这样的：

的问题

--nodes = 16 
--ntasks-per-node = 1 

其余都在this链接相关的声明。

如果您的应用程序受CPU限制，则使用核心分配;你可以投入的处理器越多越好！

这个声明是否意味着--ntasks-per-core在核不频繁访问RAM时良好？

如果内存访问是应用程序性能的瓶颈，请使用套接字分配。由于内存中有多少数据可以限制作业的速度，因此在同一内存总线上运行更多任务不会导致加速，因为所有这些任务都在通向内存的路径上。

我只是不明白这一点。我知道的是所有插座和插座上的内核共享相同的内存。这就是为什么我不明白为什么--ntasks-per-socket选项可用？

如果某些节点范围的资源是您应用程序的瓶颈，请使用节点分配。在严重依赖磁盘访问或网络资源的应用程序中就是这种情况。每个节点运行多个任务不会导致加速，因为所有这些任务都在等待访问同一个磁盘或网络管道。

这是否意味着，如果所需内存超过单个节点的总RAM，那么它最好使用多个节点？

Answer 1

为了：

1. 是的，所有核心共享相同的内存。但通常不会以相同的速度。通常情况下，每个处理器（在您的配置中，您有2个处理器或套接字）的内存与“更接近”。通常Linux内核会尝试在附近的内存上分配内存。这不是用户应用程序通常不必担心的问题。
2. 如果它是一个串行作业，那么是的，15个核心将闲置。如果您的作业使用MPI，则它可以使用同一节点上的其他核心。实际上，同一节点上的MPI通常比跨多个节点的MPI快得多。
3. 您可以在单个节点上使用OpenMP或MPI。我不确定速度的差异，但如果你已经熟悉MPI，我会坚持下去。差异可能并不大。但是，在单个节点上运行MPI与多个节点之间的差异将会很大。在单个节点上运行MPI将比在多个节点上运行速度快得多。

如果您的应用程序受CPU限制，则使用核心分配;你可以投入的处理器越多越好！

这可能针对OpenMP或单节点并行作业。

如果内存访问是应用程序性能的瓶颈，请使用套接字分配。由于内存中有多少数据可以限制作业的速度，因此在同一内存总线上运行更多任务不会导致加速，因为所有这些任务都在通向内存的路径上。

查看1的答案。虽然它是相同的内存，但核心通常具有单独的总线到内存。

如果某些节点范围的资源是您应用程序的瓶颈，请使用节点分配。在严重依赖磁盘访问或网络资源的应用程序中就是这种情况。每个节点运行多个任务不会导致加速，因为所有这些任务都在等待访问同一个磁盘或网络管道。

如果您需要更多的RAM，而不是单个节点可以提供的内存，那么您别无选择，只能划分您的程序并使用MPI。