Solaris 10:虚拟内存耗尽

Question

我们的团队都是程序员，只使用Linux或MacOS，但是客户使用Solaris 10，我们需要代码才能在那里工作。因此，我们搜索了一个旧的SunFire V240和一个租来的Solaris 10 VM进行测试。

代码在VM上编译得很好，但在SunFire上却失败了。我们的代码有一个巨大的自动生成的C++文件作为构建的一部分。是这个巨大的文件无法编译。它失败的消息是：virtual memory exhausted: Not enough space

我搞不懂。SunFire有8GB的内存，当编译超过1.2GB时，虚拟内存就会耗尽。没有其他重要的东西在运行。下面是一些濒临失败的内存统计数据：

使用prstat -s size：

SIZE (virtual memory): 1245 MB
RSS  (real memory):    1200 MB

根据echo "::memstat" | mdb -k的说法，很多内存仍然是空闲的：

Free (cachelist) is 46%
Free (freelist)  is 26% of total.

在编译失败之前，所有用户进程都在使用大约17%的RAM。(故障后，用户RAM的使用率下降到2%。)这与其他RAM的使用编号一致。(1.2GB /8.0GB ~= 15%)

swap -l报告说，交换空间完全未使用。

其他一些细节：

我们使用g++ 6.1.0构建，编译为64位。如果我们将-m64标志传递给编译器，它就会失败。

# uname -a 
SunOS servername 5.10 Generic_147440-27 sun4u sparc SUNW,Sun-Fire-V240

VM和SunFire都设置了如下系统限制：

>ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 10
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 29995
virtual memory          (kbytes, -v) unlimited

(using su)>rctladm -l
...
process.max-address-space   syslog=off     [ lowerable deny no-signal bytes ]
process.max-file-descriptor syslog=off     [ lowerable deny count ]
process.max-core-size       syslog=off     [ lowerable deny no-signal bytes ]
process.max-stack-size      syslog=off     [ lowerable deny no-signal bytes ]
process.max-data-size       syslog=off     [ lowerable deny no-signal bytes ]
process.max-file-size       syslog=off     [ lowerable deny file-size bytes ]
process.max-cpu-time        syslog=off     [ lowerable no-deny cpu-time inf seconds ]
...

我们已经尝试将堆栈大小设置为“无限”，但这并没有造成任何可识别的差别。

# df
/                  (/dev/dsk/c1t0d0s0 ):86262876 blocks  7819495 files
/devices           (/devices          ):       0 blocks        0 files
/system/contract   (ctfs              ):       0 blocks 2147483608 files
/proc              (proc              ):       0 blocks    29937 files
/etc/mnttab        (mnttab            ):       0 blocks        0 files
/etc/svc/volatile  (swap              ):14661104 blocks  1180179 files
/system/object     (objfs             ):       0 blocks 2147483465 files
/etc/dfs/sharetab  (sharefs           ):       0 blocks 2147483646 files
/platform/sun4u-us3/lib/libc_psr.so.1(/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1):86262876 blocks  7819495 files
/platform/sun4u-us3/lib/sparcv9/libc_psr.so.1(/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1):86262876 blocks  7819495 files
/dev/fd            (fd                ):       0 blocks        0 files
/tmp               (swap              ):14661104 blocks  1180179 files
/var/run           (swap              ):14661104 blocks  1180179 files
/home              (/dev/dsk/c1t1d0s0 ):110125666 blocks  8388083 files

编辑1:设置16 up交换文件后的交换输出：

注:整块大小为512。

# swap -l
swapfile            dev    swaplo   blocks    free
/dev/dsk/c1t0d0s1   32,25  16       2106416   2106416  
/home/me/tmp/swapfile -    16       32964592  32964592

# swap -s
total: 172096k bytes allocated + 52576k reserved = 224672k used, 23875344k available 

Answer 1

结果是gmake 3.81中的一个bug。当我不使用make直接运行编译命令时，它能够使用更多的内存。在3.80：就像这样中似乎有一个已知的bug。那个窃听器应该在3.81里修好。但我也犯了一个类似的错误。

所以我尝试了gmake 3.82。编译继续进行，我没有再次看到VM错误。

我从来没有能够让它转储核心，所以我实际上不知道什么是耗尽虚拟内存，gmake，g++，或as。它就是不会把核心转储到那个错误上。我也不知道这个bug到底是什么，但它现在似乎起作用了。