在不同系统下分配大内存的测试(c.c.l.c上一人的帖子,在老家网吧不方便实验,记下啦,试试)

今天在solaris下做这个测试

测试代码如下:
#include <stdlib.h>
#include <unistd.h>
int main(){
       void* p=malloc(512*1024*1024);
       if(p==NULL) return -1;
          sleep(10000000);
             return 0;

}


然后我用g++ 4.3.2编译
g++-4.3.2 -o testm testm.c

开了5个,开到第6个的时候,malloc就返回-1了。可是,可是,令人惊奇的是
这个时候,我无论是用vmstat还是用mdb看,我都还有大量的空闲的物理内存
>::memstat
Page Summary                Pages                MB  %Tot
------------     ----------------  ----------------  ----
Kernel                     144849               565   14%
ZFS File Data               62043               242    6%
Anon                       146323               571   14%
Exec and libs                3640                14    0%
Page cache                  34357               134    3%
Free (cachelist)            35896               140    3%
Free (freelist)            600734              2346   58%

Total                     1027842              4015
Physical                  1027841              4015
这与我开这几个程序之前,没有明显的变化。(相比而下,在windows下,这个时 候系统已经卡的快嗝屁了)

然后我用ps来看
# ps -eo pid,vsz,rss,args |grep testm
 1298 527292 1356 ./testm
 1309 4224 1256 grep testm
 1300 527292 1356 ./testm
 1302 527292 1356 ./testm
 1296 527292 1356 ./testm
 1304 527292 1356 ./testm

# pmap 1296
1296:    ./testm
08046000       8K rwx--    [ stack ]
08050000       4K r-x--  /tmp/testm
08060000       8K rwx--  /tmp/testm
08062000  524296K rwx--    [ heap ]
FEB70000     320K r-x--  /lib/libm.so.2
FEBCF000       8K rwx--  /lib/libm.so.2
FECD0000      24K rwx--    [ anon ]
FECE0000    1280K r-x--  /usr/lib/libc/libc_hwcap1.so.1
FEE20000      28K rwx--  /usr/lib/libc/libc_hwcap1.so.1
FEE27000       8K rwx--  /usr/lib/libc/libc_hwcap1.so.1
FEE30000      52K r-x--  /usr/lib/libgcc_s.so.1
FEE4C000       4K rwx--  /usr/lib/libgcc_s.so.1
FEE50000       4K rwx--    [ anon ]
FEE60000     856K r-x--  /usr/lib/libstdc++.so.6.0.10
FEF45000     160K rwx--  /usr/lib/libstdc++.so.6.0.10
FEF6D000      24K rwx--  /usr/lib/libstdc++.so.6.0.10
FEF80000       4K r--s-  /var/ld/ld.config
FEF90000       4K rwx--    [ anon ]
FEFA0000       4K rw---    [ anon ]
FEFB0000       4K rw---    [ anon ]
FEFBE000     180K r-x--  /lib/ld.so.1
FEFFB000       8K rwx--  /lib/ld.so.1
FEFFD000       4K rwx--  /lib/ld.so.1
 total    527292K


系统的确给这个进程分配了地址空间(看它的heap有多大),但是压根儿就没有给 它分配物理内存。我想不出的是,它依据什么来拒绝新的申请。
由于环境有限,我没有找到良好的环境在freebsd下重复这个实验。我在 freebsd.unix-center.net上做这个测试,但是把每个进程分配的内存缩小到64M, 然后开了100个这样的进程,据估计至少需要6G的内存,malloc一直都是成功的, 我的手酸了,懒得弄了。


最有趣的在于这个:
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

int main(){
       void* p=malloc(512*1024*1024);
       if(p==NULL) return -1;
    memset(p,0,512*1024*1024);
    free(p);
          sleep(10000000);
             return 0;

}

用ps/pmap去看,事实证明,free函数根本就没有释放物理内存。free是把malloc 得到的物理内存还给了自己进程,而不是还给了操作系统。
在这一点上,freebsd是有差别的。执行完free之后,rss明显降了下来



posted on 2010-02-18 20:01 杨帆 阅读(418) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

<2010年2月>
31123456
78910111213
14151617181920
21222324252627
28123456
78910111213

统计

常用链接

留言簿

随笔档案

搜索

最新评论

阅读排行榜

评论排行榜