关于32位程序的内存

时间:2021-08-06 13:35:36

在上大学的时候老师提到过这么一个知识点

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内存,榨干系统为止。

然后统计一共分配了404次,接近4G内存了……灵机一动的我又在32位的服务器上重新跑了一次,这次确实分配3G内存之后就榨干了。

得出结论:64位系统下的32位程序不受到系统保留内存的限制,可以实打实的用到4G内存,毕竟系统有64位的寻址能力没必要再去和你的小底盘上抢资源了不是。

 

置于程序评分3.6G,实际使用3.4G,我又去追踪了一下评分程序,发现一个很蛋疼的事情……这个所谓的内存统计是调用getrusage函数得到ru_maxrss来显示的,大概的意思是曾经最大常驻内存占用值(又要扯到虚拟内存去了……不扯远了)。为啥说大概是……因为我实在没找到明确的文档,只知道是英文maximum resident set size的缩写,然后根据我的测试分配内存的时候他不断上涨,释放内存之后却没下降过。

不知道当初写这个功能的人为啥要用这个来实现内存统计打分,感觉没啥意义,因为评分上去之后服务器就拒绝服务了,导致请求由其它的服务器处理,最终所有的服务器全部拒绝服务……而且旁边就是一段被注掉的函数,里面是正确的从proc里面读取内存占用情况的代码。

 

 

然后就是……这个打分统计出来的CPU使用情况和top看到的也不一样,打分的cpu占用才0.几%,而top看占用达到了20~30%,算上cpu核数之后还是不太正确,估计又是一个坑……

先记录这么多,等这段时间把资料片忙完之后再来研究……

 

最后吐一句……当时直接开发64位程序不就没这么多麻烦了,现在是内存不足只能靠多进程来弥补,但是多进程反而导致浪费了大量的内存,cpu却比较闲置。明明64位多线程就能好好服务的事情弄个32多进程弄了这么多麻烦事。