2010-02-02

solaris的ps工具是建立在procfs之上的,而freebsd的ps工具似乎是通过kvm_xxx实现的。但是kmv_xxx中还有极少数的函数依然是依赖于procfs的。
solaris的/proc目录下只有子目录,没有普通文件。freebsd的/proc的包含一个符号链接curproc。linux则是变态至极,什么的东西都往里塞。
举个例子,在linux,想看有几个cpu有多少内存,直接看/proc下的文件即可
如果是freebsd,那么最好的方式就是sysctl hw.physmem。无论是对于程序员还是系统管理者,都可以方便的使用sysctl
如果是solaris,那么就应该用prtconf

今天在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明显降了下来

此博客中的热门博文

少写代码,多读别人写的代码

在windows下使用llvm+clang

tensorflow distributed runtime初窥