openmpi：MPI_recv掛起特定進程數

我正在運行HPC基準測試（IOR - http://sourceforge.net/projects/ior-sio/）。我編譯了IOR的源代碼並使用openmpi 1.5.3運行它。openmpi：MPI_recv掛起特定進程數

問題是，當進程數（-np）小於6時，它會掛起，這是奇數。刪除所有其他的事情我周圍的人，我運行的實際命令歸結爲：

/usr/lib64/openmpi/bin/mpirun --machinefile mpi_hosts --bynode -np 16 /path/to/IOR -F -u -t 1m -b 16g -i 1 -o /my/file/system/out_file

附加的過程GDB顯示過程掛起，在MPI_RECV：

#0 0x00007f3ac49e95fe in mlx4_poll_cq() from /usr/lib64/libmlx4-m-rdmav2.so 
#1 0x00007f3ac6ce0918 in ??() from /usr/lib64/openmpi/lib/openmpi/mca_btl_openib.so 
#2 0x000000385a6f0d5a in opal_progress() from /usr/lib64/openmpi/lib/libmpi.so.1 
#3 0x00007f3ac7511e05 in ??() from /usr/lib64/openmpi/lib/openmpi/mca_pml_ob1.so 
#4 0x000000385a666cac in PMPI_Recv() from /usr/lib64/openmpi/lib/libmpi.so.1 
#5 0x0000000000404bd7 in CountTasksPerNode (numTasks=16, comm=0x628a80) at IOR.c:526 
#6 0x0000000000407d53 in SetupTests (argc=11, argv=0x7fffe61fa2a8) at IOR.c:1402 
#7 0x0000000000402e96 in main (argc=11, argv=0x7fffe61fa2a8) at IOR.c:134

纔會出現這種問題當-np是2/3/4/5時。它適用於1/6/7/8/16等

如果我使用簡單的命令，如date或ls，我不能重現此問題。所以我不確定這是否是我編譯的環境或IOR二進制文件的問題（非常不可能，因爲同樣發生在舊的/穩定的IOR二進制文件中）。

此外，使用openmpi1.4.3而不是openmpi1.5.3時，會觀察到精確的行爲。

我也嘗試了使用不同數量的主機（--machinefile參數），並觀察到上述-np值的相同行爲。它掛的源代碼行是這樣的：

MPI_Recv(hostname, MAX_STR, MPI_CHAR, MPI_ANY_SOURCE, MPI_ANY_TAG, comm, &status);

基本上我尋找線索，爲什麼當-np爲2/3/4/5 MPI_recv()可能會掛起。請讓我知道是否需要其他信息。謝謝。

來源

2014-12-19 P.P.

它似乎是與InfiniBand相關的問題。調用'mlx4_poll_cq'來輪詢IB HCA的完成隊列，並且由於它掛在接收操作中，這意味着另一方（例如另一個等級）沒有完成發送。檢查您的InfiniBand設備和內核參數。或者，更好的辦法是將問題發佈到[Open MPI Users]（http://www.open-mpi.org/community/lists/ompi.php）郵件列表。 –

我也懷疑過。我在當地檢查了HCA，他們似乎沒問題。我不是國際文憑組織的專家，我會向我的工程師尋求幫助。我會在週一再試一次，然後從那裏拿下。感謝您的時間和有用的建議:) –

IOR已經有很長很長的時間了。我懷疑IOR是否存在問題，儘管IOR或任何文件系統基準測試都非常擅長揭露硬件故障。你可能會發現來自github的IOR有一些更好的報告：https://github.com/chaos/ior –

首先想到的是：MPI_Recv是一個阻塞接收，並將一直等到匹配MPI_Send被調用。但是，如果你發送的內容足夠小（即它適合MPI爲這些任務而設置的緩衝區），那麼該函數實際上不會等待，而是繼續執行代碼。對於更高的核心數量，您可能會發送較少的命令，因此數據可以放入緩衝區，一切都會繼續。由於核心數量較少，因此太多的數據無法放入緩衝區，並且MPI_Recv掛起，因爲您尚未調用適當的MPI_Send來獲取信息。測試這個假設的一種快速而簡單的方法：大大減少問題的大小;它是否仍然在所有這些核心數據上都掛着？如果沒有，那麼這是我的假設的進一步證據，你需要提供更多的代碼，以便我們看到問題是什麼。

來源

2014-12-19 15:18:05 wolfPack88

嗯......但如果不與1個進程掛起，這與這個建議相矛盾。確實，我發送的數據非常大（GB的順序）。我會嘗試各種尺寸，包括非常小的值。來源可以在有問題的鏈接中看到。它太多的代碼了，真的，我不完全熟悉它來生成一個SO-fit-problem-reproducible代碼。謝謝。 –

@BlueMoon：它不會掛起1個進程，因爲當你只有1個處理器（不需要發送）時，你根本不應該發送任何東西，所以無論問題大小如何，它都應該返回。 – wolfPack88

對。然後我會嘗試使用多個流程的各種尺寸。 –

openmpi：MPI_recv掛起特定進程數

回答

相關問題