标签：处理 windows ide 64位 根据 意义 用户 set 调用
在上大学的时候老师提到过这么一个知识点
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多进程弄了这么多麻烦事。
标签：处理 windows ide 64位 根据 意义 用户 set 调用
原文地址：http://www.cnblogs.com/reskai/p/7528627.html
