【问题标题】:How to anticipate MPI process being killed如何预测 MPI 进程被杀死
【发布时间】:2018-11-05 20:19:57
【问题描述】:

就以下问题寻求一些建议。

我在 SLURM 系统上使用 mpi4py 运行了许多作业。 我注意到,当给定的工作太大(即要处理的数据太多)时,我会收到以下错误:

mpirun noticed that process rank 0 with PID 62208 on node node1 exited on signal 9 (Killed).

我曾尝试在提交之前将一些作业分解为更小的块,但我想知道是否有办法预测 Killed 信号并添加一个 except 语句以在需要时将作业分解为块。

【问题讨论】:

  • 这完全取决于您的工作和程序。只有您或程序的作者才能知道您的程序可以或不能计算什么。
  • 我是代码的作者,我知道它在计算什么。我只是想知道处理器何时达到最大容量,这样我就可以在作业被终止之前分解数据。
  • 但只有你能知道会发生什么,我们怎么知道?这取决于你的代码!
  • 我看不出它如何依赖于我的代码。据我了解,Killed 信号是在处理器过载时发送的。因此,我正在寻找一种方法,以便在处理器的内存达到其极限时,在发送 Killed 信号之前从处理器获取读数。
  • 不像其他 Linux 程序那样只监控可用内存量。保护 malloc 将无济于事,因为操作系统很可能会为进程提供比实际可用内存更多的内存。我相信您会在这里找到很多关于此的问答。

标签: python mpi slurm mpi4py


【解决方案1】:

KILL 信号无法被捕获、阻止或 忽略,但它通常前面有一个 INT 或 TERM 信号,您可以抓住这些信号并借此机会采取行动。 INT 信号here 见 Python 中的示例

【讨论】:

    【解决方案2】:

    您的应用程序分配了过多的内存。不幸的是,SIGKILL 无法在您的应用程序中处理;所以你需要积极主动(确保你永远不会超过可能的记忆)而不是被动(捕捉信号并采取行动)。目前尚不清楚您所说的“要处理的数据过多”究竟是什么意思,或者您如何将问题分解成更小的部分,因此我只能提供一些一般性建议。

    如果您可以合理地估计您尝试解决的问题的内存需求,您可以警告用户并在问题大小超过节点可以处理的情况下提前中止作业。然后,该脚本可以减小问题大小或增加节点数量,直到它适合内存。如果节点是共享的,或者您事先不知道可用内存量,您可以使用get_phys_pages()get_avphys_pages 等函数来确定。

    【讨论】:

      猜你喜欢
      • 2011-07-28
      • 2010-12-08
      • 1970-01-01
      • 2011-09-23
      • 2013-04-07
      • 2012-09-21
      • 1970-01-01
      • 1970-01-01
      • 2011-09-09
      相关资源
      最近更新 更多