3.6G？超过linux下32位程序只能使用3G内存？

老师在我上大学时提到了这样的知识点

32位程序的寻址能力为2 ^ 32，即4G。对于32位程序，只能应用4G内存。在4G内存中，windows下的2G和linux下的1G保留用于内核模式，无法在用户模式下访问。因此，只能分配2G和3G内存使用情况。

服务器已在几天前发出警报，无法加载更多用户进行访问。我迅速查看了该程序的自我评价，结果表明内存使用率达到3. 6G，无法继续工作。

WTF？ 3. 6G？是否超出了Linux下32位程序只能使用3G内存的限制？

这时，我怀疑计分程序编写不正确。我迅速用TOP检查了内存，它也达到了3. 4G ...，这很尴尬。

这时，他们开始怀疑自己已经定制了内核并修改了系统保留的内存。

但这只是猜测，只需编写代码，一次仅分配malloc10M内存，然后耗尽系统直到干dry。

然后我计算了总共404个分配，这接近4G的内存...我再次在32位服务器上运行它，这一次在分配3G内存后耗尽了它。

结论：64位系统下的32位程序不受系统保留内存的限制，并且实际上可以使用4G内存。毕竟，该系统具有64位寻址功能，无需转到您的小型机箱上，它不是在抢资源吗？

放置在程序得分3. 6G中，并实际使用了3. 4G，我再次遵循计分程序，发现了一件痛苦的事...所谓的内存统计信息就是调用getrusage函数来获取ru_maxrss要显示“是”，这可能意味着最大的常驻内存使用量值（它必须再次与虚拟内存相关……不远）。为什么会这样...因为我确实没有找到清晰的文档，所以我只知道这是英语中的最大常驻集大小的缩写，然后根据我的测试，当分配内存时，它一直在增加，但是释放内存后，它永远不会掉落。

我不知道为什么编写此功能的人使用此功能来获得内存统计信息和得分。感觉毫无意义，因为评分提高后，服务器拒绝提供服务，导致其他服务器处理该请求，最终所有服务器都拒绝了它们。 Service ...旁边是已注释的功能，其中包含正确的代码，可从proc中读取内存使用情况。

然后是...根据该得分计算出的CPU使用率不同于顶部看到的CPU使用率。得分的cpu仅占0.几个百分点，而top可以看到包括cpu核心在内的占用率达到20〜30％。经过计算，它仍然不正确，可能是一个坑...

先记录这么多，然后在这段时间内完成扩展后再研究...

最后一句话...那时，直接开发64位程序并不那么麻烦。现在，内存不足只能通过多个进程来弥补，但是多个进程会浪费大量内存，并且CPU相对处于空闲状态。显然，64位多线程可以很好地解决问题，使32个以上的进程陷入困境，并带来很多麻烦。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-360158-1.html