openmpi: MPI_recv зависает для определенного количества процессов

Я запускаю тест HPC (IOR - http://sourceforge.net/projects/ior-sio/) на блеск. Я скомпилировал исходный код IOR и запустил его с openmpi 1.5.3.

Проблема в том, что он зависает, когда количество процессов (-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. Пожалуйста, дайте мне знать, если потребуется другая информация. Спасибо.


mpi openmpi lustre
person P.P    schedule 19.12.2014    source источник
comment
Кажется, это проблема, связанная с InfiniBand. mlx4_poll_cq вызывается для опроса очереди завершения IB HCA, и, поскольку он зависает в операции приема, это означает, что другая сторона (например, другой ранг) не завершает отправку. Проверьте оборудование InfiniBand и параметры ядра. Или, что еще лучше, отправьте свой вопрос в рассылку Open MPI Users. список.   -  person Hristo Iliev    schedule 20.12.2014
comment
Я тоже это подозревал. Я проверил HCA локально, и они оказались в порядке. Я не эксперт IB, и я попрошу помощи у моих аппаратных инженеров. Я попробую еще раз в понедельник и возьму оттуда. Спасибо за ваше время и полезные советы :)   -  person P.P    schedule 20.12.2014
comment
IOR существует очень давно. Я сомневаюсь, что вина лежит на IOR, хотя IOR или любой другой тест файловой системы неплохо выявляют аппаратные сбои. Вы можете обнаружить, что у IOR от github отчет немного лучше: github.com/chaos/ior   -  person Rob Latham    schedule 21.12.2014

Ответы (1)


arrow_upward
2
arrow_downward

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

person wolfPack88    schedule 19.12.2014
comment
хммм ... но если не зависает с 1 процессом, что противоречит этому предложению. Это правда, что данные, которые я отправляю, довольно велики (порядка ГБ). Я попробую с различными размерами, в том числе с очень маленькими значениями. Источник можно увидеть по указанной ссылке. На самом деле, это слишком много кода, и я не полностью знаком с ним, чтобы создавать код, воспроизводимый ТАК-подходящей проблемой. Спасибо. - person P.P; 19.12.2014
comment
@BlueMoon: он не зависает с 1 процессом, потому что вы вообще не должны ничего отправлять, когда у вас есть только 1 процессор (не на что отправлять), поэтому он должен возвращаться независимо от размера проблемы. - person wolfPack88; 19.12.2014
comment
Верно. Тогда я попробую с разными размерами и несколькими процессами. - person P.P; 19.12.2014