捕获到致命信号：节点 2/32 上的 SIGBUS(7)

Question

我正在尝试在 32 节点集群上运行 NAS-UPC 基准测试。

在问题规模较小的情况下它工作得很好。当我毕业到更大的问题规模（CLASS D）时，我得到了这个错误（对于 MG 基准）

*** Caught a fatal signal: SIGBUS(7) on node 2/32
 p4_error: latest msg from perror: Bad file descriptor
*** Caught a signal: SIGPIPE(13) on node 0/32
    p4_error: latest msg from perror: Bad file descriptor
   p4_error: latest msg from perror: Bad file descriptor

*** FATAL ERROR: recursion failure in AMMPI_SPMDExit
*** Caught a signal: SIGPIPE(13) on node 27/32
*** Caught a signal: SIGPIPE(13) on node 20/32
*** Caught a signal: SIGPIPE(13) on node 21/32
    p4_error: latest msg from perror: Bad file descriptor
*** FATAL ERROR: recursion failure in AMMPI_SPMDExit
*** FATAL ERROR: recursion failure in AMMPI_SPMDExit
*** FATAL ERROR: recursion failure in AMMPI_SPMDExit
*** Caught a signal: SIGPIPE(13) on node 16/32
*** FATAL ERROR: recursion failure in AMMPI_SPMDExit

任何人都可以解释为什么会发生这种情况，如果有人以前看到过这个错误并修复它？

编辑：发现这是一个与内存相关的问题。但我无法在编译时为应用程序分配适量的内存

Answer 1

检查dmesg 输出 - 这可能是内存不足问题。或者，再次，它可以是来自ulimit -a 的一些命中，例如堆栈大小（对于某些 NAS 任务，默认堆栈大小太小）。

如果您在任何机器上的dmesg 输出中有类似“Out of Memory: Killed process ###”这样的行 - 这意味着您的程序需要（并试图使用）大量内存，大于您的操作系统可以提供给应用程序。内存有几个限制：

1. ulimit -v - 虚拟内存大小的用户限制。检查所有ulimit -a 限制，但似乎你的情况不是这样
2. 您使用的内存不能超过总 RAM 和所有交换大小（使用 free 命令检查）。但是，如果您的应用程序使用的内存大于 RAM 大小，并开始进行交换 - 性能会很差（在大多数情况下）。
3. 存在最大内存的架构限制，允许单个进程拥有。对于 32 位节点，此限制可以从 1（非常罕见的情况）到 2、3、4 GB。即使您的 32 位系统具有 >4 GB 的内存，例如使用 PAE - 没有一个进程可以占用 > 4 Gb。操作系统也占用了 4Gb 虚拟空间的很大一部分（从数百 MB 到 GB）。

Answer 2

我认为基准测试需要比我在编译期间分配的更多内存是一个问题。