2014-12-19 3 views
0

Я запускаю тест 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); 

В основном я в поисках ключей, почему MPI_recv() может зависнуть, когда -np является 2/3/4/5. Пожалуйста, дайте мне знать, нужна ли другая информация. Благодарю.

+0

Это проблема InfiniBand. 'mlx4_poll_cq' вызывается для опроса очереди завершения IB HCA и, поскольку он зависает в операторе приема, это означает, что другая сторона (например, другой ранг) не завершает отправку. Проверьте оборудование InfiniBand и параметры ядра. Или, что еще лучше, отправьте свой вопрос в список рассылки [Open MPI Users] (http://www.open-mpi.org/community/lists/ompi.php). –

+0

Я тоже это подозревал. Я проверил HCAs на местном уровне, и они выглядели нормально. Я не эксперт IB, и я попрошу некоторую помощь от моих h/w инженеров. Я дам еще одну попытку в понедельник и возьму ее оттуда. Спасибо за ваше время и полезные предложения :) –

+0

IOR уже давно. Я сомневаюсь, что ошибка кроется в IOR, хотя IOR или любой контрольный файл файловой системы неплохо разбираются в аппаратных ошибках. Вы можете обнаружить, что IOR из github имеет немного лучшую отчетность: https://github.com/chaos/ior –

ответ

1

Первое, что приходит на ум: MPI_Recv является блокирующим приемом, и будет ждать, пока не будет найдено соответствующее имя MPI_Send. Однако, если то, что вы отправляете, достаточно мало (т. Е. Оно подходит в буфере, который MPI выделяет для таких задач), тогда функция фактически не будет ждать и вместо этого продолжит выполнение кода. Для более высоких коэффициентов ядра вы можете отправлять меньше с каждой командой MPI_Send/MPI_Recv, поэтому данные вписываются в буфер, и все продолжается на своем пути. При меньшем числе сердечников в буфере имеется слишком много данных, и MPI_Recv зависает, так как вы не вызывали соответствующий MPI_Send для получения информации. Быстрый и простой способ проверить эту гипотезу: существенно уменьшить размер проблемы; он все еще висит на всех этих подсчетах? Если нет, то это еще одно доказательство моей гипотезы, и вам нужно будет предоставить больше кода, чтобы мы могли понять, в чем проблема.

+0

hmmm ... но если не висеть с 1 процессом, что противоречит этому предложению. Это правда, что данные, которые я отправляю, довольно велики (порядок ГБ).Я попробую с различными размерами, включая очень маленькие значения. Источник можно увидеть в соответствующей ссылке. Это слишком много кода, и я не знаком с ним полностью, чтобы создать воспроизводимый код SO-fit-problem. Благодарю. –

+0

@BlueMoon: он не зависает с одним процессом, потому что вы не должны ничего отправлять вообще, когда у вас есть только 1 процессор (ничего не отправлять), поэтому он должен возвращаться независимо от размера проблемы. – wolfPack88

+0

Справа. Тогда я попробую с различными размерами с несколькими процессами. –