32位Linux（CONFIG_VMSPLIT_1G配置）用户态可用虚拟地址空间精准查询及内存分配失败问题咨询

首先，你遇到的问题很典型：虽然CONFIG_VMSPLIT_1G给用户态分配了理论上1GB的虚拟地址空间，但实际能用来malloc的内存远小于这个值——因为用户态虚拟地址还要被程序自身的代码段、数据段、栈、共享库（比如libc、动态链接器）、环境变量等占用，这些加起来通常会占几十MB，所以900MB已经接近实际可用的上限，导致分配失败。

下面是几种精准查询用户态实际可用虚拟地址空间的方法，以及对应的命令：

1. 查看当前进程的虚拟地址空间布局与占用 #

方法一：直接读取/proc/self/maps #

这个文件会列出当前进程（比如你的shell）的所有虚拟地址段，包括每个段的起始/结束地址、权限、所属文件等：

cat /proc/self/maps

你可以手动计算所有已占用段的大小总和，再用1024MB减去这个值，得到大致的可用空间。

方法二：用pmap工具快速统计 #

pmap会帮你汇总进程的虚拟内存使用情况，针对当前shell的话，直接运行：

pmap -x $$ | tail -2

输出的最后一行total字段就是已占用的虚拟内存总量（单位KB），换算成MB后用1024MB减去它，就是实际可用的近似值。

2. 检查系统虚拟内存限制 #

有时候系统会通过ulimit设置用户态虚拟内存的上限，你可以用下面的命令查看：

ulimit -v

如果输出是unlimited，说明没有人为限制；如果是具体数值（单位KB），那这个就是当前用户能使用的最大虚拟内存。

3. 一键计算实际可用空间 #

用awk脚本自动统计已占用的虚拟内存，并计算实际可用值：

awk '/^[0-9a-f]/ {split($1, a, "-"); sum += strtonum("0x"a[2]) - strtonum("0x"a[1])} END {print "已占用虚拟内存: " sum/1024/1024 " MB\n用户态理论可用: 1024 MB\n实际可用近似值: " (1024 - sum/1024/1024) " MB"}' /proc/self/maps

这个脚本会直接输出你能用来分配的大致内存大小。

针对你的stressapptest问题的建议 #

先运行上面的命令得到实际可用空间，然后分配这个值的80%左右（比如实际可用920MB的话，分配736MB），避免接近上限导致分配失败。

附上你提供的命令执行及工具运行日志：

root@:/# 
root@:/# cat /proc/meminfo | head -5
MemTotal: 1826896 kB
MemFree: 1708308 kB
MemAvailable: 1694060 kB
Buffers: 2484 kB
Cached: 9520 kB
root@:/# 
root@:/# ./stressapptest -M 900
2021/09/25-06:48:59(UTC) Log: Commandline - ./stressapptest -M 900
2021/09/25-06:48:59(UTC) Stats: SAT revision 1.0.7_autoconf, 32 bit binary
2021/09/25-06:48:59(UTC) Log: varada @ CHEPSSW01 on Wed Aug 27 12:05:13 IST 2014 from open source release
2021/09/25-06:48:59(UTC) Log: 1 nodes, 4 cpus.
2021/09/25-06:48:59(UTC) Log: Defaulting to 4 copy threads
2021/09/25-06:48:59(UTC) Log: Flooring memory allocation to multiple of 4: 900MB
2021/09/25-06:48:59(UTC) Log: Prefer plain malloc memory allocation.
2021/09/25-06:48:59(UTC) Process Error: memalign returned 0
2021/09/25-06:48:59(UTC) Process Error: failed to allocate memory
2021/09/25-06:48:59(UTC) Process Error: Sat::Initialize() failed
2021/09/25-06:48:59(UTC) 
2021/09/25-06:48:59(UTC) Status: FAIL - test encountered procedural errors
2021/09/25-06:48:59(UTC) 
2021/09/25-06:48:59(UTC) Process Error: Fatal issue encountered. See above logs for details.
root@OpenWrt:/#

内容的提问来源于stack exchange，提问作者Kavin A