R 并行集群工作进程永远不会返回

Question

我正在使用 doParallel使用以下语法在多台 Linux 机器上并行化作业的包:
cl <- makePSOCKcluster(machines, outfile = '', master = system('hostname -i', intern = T))
通常，每个作业在一台机器上运行所需的时间不到 10 分钟。然而，有时会有一个工作进程会“逃跑”并持续运行数小时，并且永远不会返回到主驱动程序进程。我可以看到使用 top 运行的进程，但似乎这个过程在某种程度上被卡住了，而不是真正运行任何东西。 outfile=''选项不会产生任何有用的东西，因为工作进程从未真正失败过。

这种情况发生得相当频繁，但非常随机。有时我可以重新开始工作，他们会很好地完成。因此，我无法提供可重现的示例。有没有人对如何调查这个问题有一般性的建议？或者将来再次发生这种情况时要寻找什么？

编辑:

添加更多详细信息以响应评论。我正在 10 台机器上运行数千个小型模拟。 IO 和内存使用量都很小。我注意到工作进程在不同的机器上随机运行，没有任何模式，不一定是最繁忙的。我无权查看系统日志，但根据 CPU/RAM 历史记录，似乎没有任何异常。

它发生的频率足够高，因此很容易捕捉到正在运行的失控进程。 top将显示进程正在以接近 100% 的 CPU 运行，状态为 R ，所以它肯定是在运行而不是在等待。但我也很确定每次模拟应该只需要几分钟，不知何故，逃跑的 worker 只是不停地跑。

到目前为止doParallel是我尝试过的唯一包。我正在探索其他选择，但在不知道原因的情况下很难做出明智的决定。

Answer 1

这种问题在大型计算集群上并不少见。尽管挂起的工作进程可能不会产生任何错误消息，但您应该检查执行工作进程的节点上的系统日志，以查看是否报告了任何系统问题。可能存在磁盘或内存错误，或者系统内存不足。如果某个节点出现问题，只需不使用该节点即可解决您的问题。

这是批量排队系统有用的原因之一。耗时过长的作业可以被终止并自动重新提交。不幸的是，它们经常在同一个坏节点上重新运行作业，因此检测坏节点并防止调度程序将它们用于后续作业非常重要。

您可能需要考虑向您的程序添加检查点功能。不幸的是，这通常很困难，尤其是使用 doParallel 时尤其困难。后端，因为 parallel 中没有检查点功能包裹。您可能想调查 doRedis后端，因为我相信作者有兴趣支持某些容错功能。

最后，如果你真的在行动中捕获了一个被吊死的 worker ，你应该使用“ps”或“top”获得尽可能多的信息。例如，进程状态很重要，因为它可以帮助您确定进程是否在尝试执行 I/O 时卡住。更好的是，您可以尝试将 gdb 附加到它并获得回溯以确定它实际在做什么。