PARALLEL.RU

Ситуация такая: я использую MS-MPI + OpenMP + HPC Pack 2008 + Visual Studio 2008,
пишу клиент-сервер: клиент посылает на кластер задачи, сервер распределяет их решения по своим MPI-терминалам (узлы с ненулевым ранком)

уровень синхронизации - MPI_THREAD_SERIALIZED

на серверной стороне реализовано нечто вроде коммутатора между клиентом и MPI-сервером, т.е. клиент посылает по сокетам команды серверу,
а тот, в зависимости от команды делает свою организаторскую работу MPI-рута,

на терминальной стороне реализован цикл:

в основном задачи такие: сервер раскидывает данные по терминалам и собирает с них ответы, после чего на основе этих ответов принимает решение что ответить клиенту,

все это общение уже работает нормально, но появилась критическая проблема:
в какой-то момент один из терминалов перестает слышать сервер, т.е. из MPI_Probe перестает возвращаться один из процессов,

проверял я это локально, отлаживая MPI в Visual Studio, т.е. там есть такие средства отладки,
сначала грешил на связь между клиентом и сервером, но после детального изучения логов и стека вызовов от термииналов, четко определил проблему:


т.е. тут смысл такой: NCC_DELETE_HANDLE посылается с сервера всем терминалам с определенным индексом (дескриптором), связанный с которым объект они должны у себя удалить

а из лога видно, что дескриптор D8 был удален только терминалом 1, тогда как терминал 2 такой команды не получил вообще

пробовал перепосылать запрос с сервера, если через 1-2 секунды не пришел ответ и в некоторых случаях проблема решается ( я это делал на основе неблокирующего MPI_Iprobe, прокручивая в цикле по всем терминалам )

это решение я тоже долго тестировал и определил, что не отвечает всегда только какой-то один из терминалов,
начинаю думать, что придется реализовывать на терминальной стороне "маяк", который они будут периодически посылать и/или принимать с сервера вместо "пожизненного" ожидания в MPI_Probe

но не думаю, что даже такой маяк может помочь, ведь тут связь теряется (хотя в логе mpiexec ни о каких ошибках речи нет)

я хотел бы услышать о том, были ли какие-то подобные случаи,
предложения по поводу как оживить этот терминал,
может как-то перевключить в коммуникатор или еще чего?

заменил на терминальной стороне

на

и терминал перестал зависать вообще, но из-за 10мс задержки появилась большая инертность терминалов,
поставил задержку в 1мс, инертность пропала, но вернулось зависание терминалов:

поставил задержку в 2мс, инертность так же пропала, вернулось зависание терминалов, но уже с изредким оживлением:

поставил задержку в 3мс - результат примерно тот же, что и для 10мс

странный эффект, если учесть нереальность реализации задержки в ядре менее 10мс впринципе

тестировал я все это с количеством попыток повторных рассылок от сервера на протяжении 2 минут, каждая из которых предварительно крутит MPI_Iprobe в течении секунды,

т.е. стандартное общение:

заменил на что-то вроде такого (псевдокод):

аналогичная проблема и с синхронным MPI_Recv,
для 3-х узлов проблема не проявляется, а вот если поставить 10, то некоторые терминалы начинают виснуть на вызове MPI_Recv

пока решил проблему примерно так же как и с MPI_Probe, т.е. на терминальной стороне реализовл ожидание приема через MPI_IRecv, и завернул MPI_Request в пользовательском цикле с тестированием ( MPI_Test )

p.s.: если вместо цикла MPI_Test поставить вызов MPI_WaitAll, зависания снова возвращаются ( но теперь, конечно уже в MPI_WaitAll )

вобщем, пока пришел к выводу, что если на стороне мастера вызывать асинхронные MPI_ISend, то на приемной стороне (slave) следует так же использовать асинхронные методы