抓住致命信号：节点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的一些人，例如stacksize（某些NAS任务的默认堆栈大小太小）。

如果你的任何一台机器的dmesg输出中有“内存不足：被杀过程###”这样的行 - 这意味着你的程序需要（并试图使用）大量内存，比你的操作系统更大可以给应用程序。内存有几个限制：

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

Answer 2

我认为基准测试需要的内存比我在编译时分配的内存要多。