从计算机大小的角度来看,虚拟内存是一种让程序认为它有大量连续地址空间的方法;但实际上,它正在使用的部分散布在RAM中,而不活动的部分保存在磁盘文件中。(Wikipedia)
我将在Windows任务管理器中将VM Size解释为可寻址虚拟内存空间的总量或进程当前在虚拟内存空间中使用的内存量。
但在任务管理器中,WM Size在许多情况下小于Mem Usage,后者应该是进程正在使用的RAM数量。因此,我猜测WM Size意味着其他内容?
从计算机大小的角度来看,虚拟内存是一种让程序认为它有大量连续地址空间的方法;但实际上,它正在使用的部分散布在RAM中,而不活动的部分保存在磁盘文件中。(Wikipedia)
我将在Windows任务管理器中将VM Size解释为可寻址虚拟内存空间的总量或进程当前在虚拟内存空间中使用的内存量。
但在任务管理器中,WM Size在许多情况下小于Mem Usage,后者应该是进程正在使用的RAM数量。因此,我猜测WM Size意味着其他内容?
进程地址空间中映射的内存量。这可能包括共享内存映射。
在一个进程中,每个共享对象(DLL)都有自己的内存空间,以及一些用于堆栈和进程本身分配的区域。
例如,在我的系统上查看cat
命令的内存映射,我可以看到它的内存映射。在这种情况下,我使用cat /proc/self/maps
来调查cat进程本身。它的虚拟内存中映射了二进制文件本身、一些堆、区域信息、libc(带有各种权限标志)、ld.so(动态链接器)、堆栈、vdso和vsyscall部分以及一些匿名映射(映射页面没有支持文件)。
00400000-00408000 r-xp /bin/cat
00607000-00608000 rw-p /bin/cat
008ac000-008cd000 rw-p [heap]
7fbd54175000-7fbd543cf000 r--p /usr/lib/locale/locale-archive
7fbd543cf000-7fbd54519000 r-xp /lib/libc-2.7.so
7fbd54519000-7fbd54718000 ---p /lib/libc-2.7.so
7fbd54718000-7fbd5471b000 r--p /lib/libc-2.7.so
7fbd5471b000-7fbd5471d000 rw-p /lib/libc-2.7.so
7fbd5471d000-7fbd54722000 rw-p
7fbd54722000-7fbd5473e000 r-xp /lib/ld-2.7.so
7fbd5491d000-7fbd5491f000 rw-p
7fbd5493a000-7fbd5493d000 rw-p
7fbd5493d000-7fbd5493f000 rw-p /lib/ld-2.7.so
7fff5c929000-7fff5c93e000 rw-p [stack]
7fff5c9fe000-7fff5c9ff000 r-xp [vdso]
ffffffffff600000-ffffffffff601000 r-xp [vsyscall]
对于每个映射,从结束地址中减去起始地址以确定其大小,例如[stack]
行:0x7fff5c9ff000 - 0x7fff5c9fe000 = 0x1000
。在十进制中,4096字节-4 kiB堆栈。
如果将所有这些数字相加,您将得到进程的虚拟内存(VM)大小。
VM大小不是确定进程使用多少内存的可靠方法。例如,无论有多少进程使用它,只会在物理内存中存在每个只读/lib/libc-2.7.so
映射的一个副本。
关于虚拟内存大小,哪个是正确的答案?
在Coding Horror中
已经被分页到磁盘上的进程较少使用的内存量。
在Coding Horror的评论中
你对虚拟内存大小的理解是错误的。它是该进程分配的所有私有(非共享)字节的总和,无论当前是否在物理内存中。它比“内存使用情况”更适合跟踪内存泄漏。同样的值在性能监视器中可用作“进程:私有字节”。
在MSDN中
虚拟内存大小: 分配给进程的虚拟内存或地址空间的数量。
我很困惑哪个是正确的。
可以写一篇编程恐怖故事来回答这个问题:http://www.codinghorror.com/blog/archives/000393.html
"VM尺寸:进程中有多少不经常使用的内存被分页到磁盘上。"
我在Windows任务管理器中看不到虚拟机大小,但Whatup Gold在其任务管理器中有虚拟机大小 - 你是指这个吗?如果是这种情况,我相信它与虚拟机可用的总量有关。