我使用通过OpenMPI连接的多台计算机在Amazon EC3平台上进行计算。为了降低计算成本,使用了现场实例,当机器的成本超过最大预设价格时,它们会自动关闭:: http://aws.amazon.com/ec2/spot-instances/。出现奇怪的行为:当机器关闭时,MPI通信器中的其他进程仍然继续运行。我认为在进程有时间向其他进程指示已收到kill信号之前,网络接口是静默的。
我在多篇文章中读过MPI没有提供很多关于容错的高级资源。另一方面,我的程序结构非常简单:从属进程查询主进程,以获得执行部分代码的权限。主进程仅跟踪它已回复的查询数,并告知从属进程达到上限时停止。奴隶之间没有耦合。
我希望能够检测到进程如前所述默默死亡的时间。在那种情况下,我会将他正在做的工作重新归因于一个仍然活着的奴隶。有没有一种简单的方法来检查是否死亡?我曾想过使用线程和套接字独立于MPI层的其余部分来做这件事,但这看起来很麻烦。我还要维护主进程(在非现场实例上启动)一个上次与每个进程通信的时间列表,并指定超时,但这并不能保证我的从属进程已经死了。还有一个问题是“屏障”和“最终确定功能不会看到所有进程,并且可能会挂起。
那么我的问题是你会用什么样的解决方案来检测进程是否已经无声无息?那么如何修改代码的其余部分以与减少的进程数量兼容?
答案 0 :(得分:2)
您使用的是哪个版本的Open MPI?
我不确定Open MPI可能正在做什么(或没做什么),因为它不能检测到进程消失了。失败后Open MPI的通常行为是运行时将中止整个作业。
不幸的是,Open MPI中没有用于发现失败进程的机制(特别是在听起来像Open MPI甚至不知道它们失败的情况下)。但是,正在进行大量工作以将其添加到所有MPI库的未来版本中。支持此行为的示例实现之一是Open MPI的一个分支,称为ULFM(www.fault-tolerance.org)。那里有很多文档可以看到究竟发生了什么,但实际上,它是MPI标准中增加容错能力的新篇章。
MPICH 3.0.3中有一个较旧的功能(不幸的是,它在3.0.4中被破坏了,但它应该回到3.1)(www.mpich.org)。使用该工作的文档在README中。
这两项努力的问题在于它们不符合MPI标准。最终,将会有一章描述MPI中的容错,并且所有MPI实现都将兼容,但与此同时,并不是每个人都有好的解决方案。
答案 1 :(得分:0)