我使用doParallel包使用以下语法在多台Linux机器上并行化作业：
cl <- makePSOCKcluster(machines, outfile = '', master = system('hostname -i', intern = T))
通常，每台作业在一台计算机上运行的时间不会超过10分钟。但是，有时会有一个工作进程“逃跑”并保持运行数小时并且从未返回到主驱动程序进程。我可以看到使用top运行的进程，但看起来这个过程在某种程度上被卡住而不是真正运行任何东西。 outfile=''选项不会产生任何有用的东西，因为工作进程从未真正失败过。
这种情况经常发生，但随机发生。有时我可以重新开始工作，他们会很好。因此，我无法提供可重复的例子。有没有人就如何调查此问题提出一般性建议？或者将来会再次发生什么？
编辑：
添加更多详细信息以回应评论。我在10台机器上运行了数千个小模拟。 IO和内存使用量都很小。我注意到工作进程随机地在不同的机器上运行而没有任何模式，不一定是最繁忙的模式。我没有权限查看系统日志，但根据CPU / RAM历史记录似乎没有任何异常。
它经常发生，很容易捕捉失控的过程。 top将显示该进程正在以接近100％的状态为R的CPU运行，因此它肯定在运行而不是等待。但我也很确定每次模拟只需要几分钟，而且不知何故，失控的工人只是不停地运行。
到目前为止，doParallel是我尝试过的唯一方案。我正在探索其他选择，但如果不知道原因，很难做出明智的决定。
答案 0 :(得分：0)
这种问题在大型计算群集上并不少见。虽然挂起的工作进程可能不会产生任何错误消息，但您应检查执行该工作程序的节点上的系统日志，以查看是否已报告任何系统问题。可能存在磁盘或内存错误，或者系统内存可能不足。如果节点出现问题，只需不使用该节点即可解决问题。
这是批处理排队系统有用的原因之一。花费太长时间的作业可能会被杀死并自动重新提交。不幸的是，它们经常在同一个坏节点上重新运行作业，因此检测错误节点并防止调度程序将它们用于后续作业非常重要。
您可能需要考虑为您的程序添加检查点功能。遗憾的是，由于doParallel包中没有检查点功能，因此使用parallel后端通常很困难，尤其困难。您可能想调查doRedis后端，因为我相信作者有兴趣支持某些容错功能。
最后，如果你真的抓住了一个悬挂的工人，你应该使用“ps”或“top”获得尽可能多的信息。过程状态很重要，因为这可以帮助您确定过程是否因为尝试执行I / O而陷入困境。更好的是，你可以尝试将gdb附加到它并获得追溯以确定它实际上在做什么。