我写了一个程序，它处理大量的数据。 我的CPU和操作系统（Ubuntu）都是64位，我有4GB的RAM。 使用“top”（％Mem字段），我看到进程的内存消耗增加了大约87％，即3.4+ GB，然后死亡。
然后，我使用“uname -m”来检查一个进程可以访问多less内存，这个“uname -m”是“无限的”。
现在，由于操作系统和CPU都是64位的，并且还存在一个交换分区，操作系统应该已经使用了虚拟内存，即交换空间总共为> 3.4GB + yGB，并且只有当进程需要更多的内存时应该已经被杀害了。
所以，我有以下问题：
请build议。
用file和ldd检查你的可执行文件是否是64位的。
检查资源限制。 在这个过程中，你可以使用getrlimit系统调用（在可能的情况下setrlimit来改变它们）。 从bash shell中，尝试ulimit -a 。 从zsh shell尝试limit 。
还要检查你的程序确实吃掉你认为它消耗的内存。 如果它的pid是1234，你可以尝试pmap 1234 。 从这个过程中你可以读取/proc/self/maps或/proc/1234/maps （你可以从终端读取）。 还有/proc/self/smaps或/proc/1234/smaps和/proc/self/status或/proc/1234/status和其他文件在你的/proc/self/ …
free检查你是否有相信的内存（和交换空间）。 您可以使用swapon /tmp/someswapfile添加一些临时交换空间（并使用mkswap来初始化它）。
几个月前（和几年前），我在一台装有8Gb RAM的机器上运行一个7Gb进程（一个巨大的cc1编译），在Gnu / Linux / Debian / Sid / AMD64下运行。
你可以尝试一个很小的测试程序，例如用malloc分配几个32Mb的内存块。 不要忘记在里面写一些字节（至少在每个兆字节）。
标准的C ++容器，比如std::map或者std::vector被传言会消耗比我们通常想象的更多的内存。
如果需要购买更多的RAM。 这些日子相当便宜。
这不仅是数据量可能是原因。 例如，请执行ulimit -a并检查最大堆栈大小。 你有杀人的原因吗？ 设置'ulimit -c 20000'来获得一个核心文件，它显示你检查gdb的原因。
在什么地方可以解决一切必须适应它，包括您的图形适配器，操作系统内核，BIOS等，并且可以解决的数量也不能通过SWAP扩展。
另外值得注意的是，该过程本身也需要64位。 而且有些操作系统可能会变得不稳定，因此如果你使用了过多的RAM，就会中止这个过程。