關於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。