colinzhouyj 的BLOG
用户名：colinzhouyj
文章数：35
访问量：132863
注册日期：
阅读量：5863
阅读量：12276
阅读量：353682
阅读量：1051375
51CTO推荐博文
查看内存&显示每个插槽，及插槽中内存的信息&/usr/sbin/dmidecode -t memory&查看简要内存信息&/usr/sbin/dmidecode& -t memory | grep -E "Size|Locator" | grep -v Bank查看cpu&显示每个cpu的详细信息/usr/sbin/dmidecode& -t processor&显示cpu简要信息&/usr/sbin/dmidecode& -t processor| grep -E "Designation|Version"查看扩展卡&/usr/sbin/dmidecode | grep -A3 "On Board Device"查看网卡速率&dmesg | grep ^eth查看序列号dmidecode -s "system-serial-number"查看有哪些关键字输出dmidecode -s本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)如下显示free是显示的当前内存的使用,-m的意思是M字节来显示内容.我们来一起看看.$ free -m
cachedMem:
421-/+ buffers/cache:
1153第一部分Mem行:total 内存总数: 1002Mused 已经使用的内存数: 769Mfree 空闲的内存数: 232Mshared 当前已经废弃不用，总是0buffers Buffer 缓存内存数: 62Mcached Page 缓存内存数:421M关系：total(1002M) = used(769M) + free(232M)第二部分(-/+ buffers/cache):(-buffers/cache) used内存数：286M (指的第一部分Mem行中的used - buffers - cached)(+buffers/cache) free内存数: 715M (指的第一部分Mem行中的free + buffers + cached)可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。第三部分是指交换分区, 我想不讲大家都明白.我想大家看了上面,还是很晕.第一部分(Mem)与第二部分(-/+ buffers/cache)的结果中有关used和free为什么这么奇怪.其实我们可以从二个方面来解释.对操作系统来讲是Mem的参数.buffers/cached 都是属于被使用,所以它认为free只有232.对应用程序来讲是(-/+ buffers/cach).buffers/cached 是等同可用的，因为buffer/cached是为了提高程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。所以,以应用来看看,以(-/+ buffers/cache)的free和used为主.所以我们看这个就好了.另外告诉大家一些常识.Linux为了提高磁盘和内存存取效率, Linux做了很多精心的设计, 除了对dentry进行缓存(用于VFS,加速文件路 径名到inode的转换), 还采取了两种主要Cache方式：Buffer Cache和Page Cache。前者针对磁盘块的读写，后者针对文件inode的读写。这些Cache能有效缩短了 I/O系统调用(比如read,write,getdents)的时间。记住内存是拿来用的,不是拿来看的.不象windows, 无论你的真实物理内存有多少,他都要拿硬盘交换文件来读.这也就是windows为什么常常提示虚拟空间不足的原因.你们想想,多无聊,在内存还有大部分 的时候,拿出一部分硬盘空间来充当内存.硬盘怎么会快过内存.所以我们看linux,只要不用swap的交换空间,就不用担心自己的内存太少.如果常常 swap用很多,可能你就要考虑加物理内存了.这也是linux看内存是否够用的标准哦.
阅读(...) 评论()也看linux内存去哪儿了
前两天一台128G内存的oracle主机发生故障触发kdump，最终由于var目录空间不足，导致kdump生成不完全。也看linux内存去哪儿了。
也看linux内存去哪儿了
日admin发表评论评论
前两天一台128G内存的oracle主机发生故障触发kdump，最终由于var目录空间不足，导致kdump生成不完全。结合之前redhat给出的建议，crash设置的空间最好大于memory 空间。对此我们做了一个简单的计算，认为kdump主机生成的是运行在内存里的信息 ，虽然主机有128G的内存，不过通过top查看并计算后发现我实际上只使用7G多的大小，而使用free -m查看时已经使用了80G左右的内存 。站在DBA的角度看的话，这部分内存提前分配给了sga ，貌似也可以讲通。记得之前看过taobao褚霸写的一篇分析。这里再结合该文章算算。
通过褚霸的 Used内存到底哪里去了?我们已经了解到内存主要消耗在三个方面：1. 进程消耗。 2. slab消耗 3.pagetable消耗。
由于不便于直接在现网oracle主机上进行操作，这里就以本blog的云主机为例进行测试。
一、查看已用内存总量
[root@91it ~]# free -m
total used free shared buffers cached
Mem: 996 908 88 0 174 283
-/+ buffers/cache: 450 546
Swap: 0 0 0
关于已用内存和可用内存这已经是一个老生长谈的问题了。这里看到的信息如下：
1、总内存996M ，已用内存908M
2、由于buffers + cached内存实际上也是可用内存，该内存也可以通过echo 3 & /proc/sys/vm/drop_caches 回收pagechae、dentries and inodes ，所以实际上已经使用的内存是450M 。
1、关于内存的计算方法就不上图了，这点可以参考：http://www./redpapers/pdfs/redp4285.pdf
2、linux内存强制回收的方法具体可以参考：linux 下 强制回收内存 。
即然实际使用了450M内存，那这450M内存是如何分配的呢?
二、RSS内存(Resident size)
ps下命令下的RSS内存、top工具下的RES内存都是指的这一块内存。resident set size 也就是每个进程用了具体的多少页的内存。由于linux采用的是虚拟内存，进程的代码，库，堆和栈使用的内存都会消耗内存，但是申请出来的内存，只要没真正touch过，是不算的，因为没有真正为之分配物理页面，说白了也就是真正具有“数据页的物理内存”。我这里使用的是一段从python psutil 模块里演化出的一段代码进行计算的：
[root@91it ~]# cat vms.py
#!/usr/bin/python
def get_vms(pid):
with open("/proc/%s/statm" % pid, "rb") as f:
vms = f.readline().split()[1]
return int(vms)
pids = [int(x) for x in os.listdir(b'/proc') if x.isdigit()]
vmss = [get_vms(pid) for pid in pids]
print sum(vmss) * 4
[root@91it ~]# python vms.py
1、/proc/PID/statm 第二列是RSS内存使用page页的多少，而在linux下默认使用的page页大小是4KB 。所以我上面计算求和后，最后乘以4 ，而我最终计算出的结果就是386528KB 。
2、这里也可以通过/proc/PID/status里的vmRss项进行求和，因为该项直接给出的是KB值。
[root@91it ~]# cat /proc/998/status
Name: mingetty
State: S (sleeping)
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
VmPeak: 4068 kB
VmSize: 4064 kB
VmLck: 0 kB
VmHWM: 556 kB
VmRSS: 76 kB
………………………………
当然也可以使用shell 进行计算：
$ cat RSS.sh
#/bin/bash
for PROC in `ls /proc/|grep "^[0-9]"`
if [ -f /proc/$PROC/statm ]; then
TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`
RSS=`expr $RSS + $TEP`
RSS=`expr $RSS \* 4`
echo $RSS"KB"
rss内存部分，具体可以查看man proc手册或kernl 页的介绍 ，以下是man proc 里的部分提取：
/proc/[pid]/statm
Provides information about memory usage, measured in pages. The
columns are:
size total program size
(same as VmSize in /proc/[pid]/status)
resident resident set size
(same as VmRSS in /proc/[pid]/status)
share shared pages (from shared mappings)
text text (code)
lib library (unused in Linux 2.6)
data data + stack
dt dirty pages (unused in Linux 2.6)
二、slab内存
slab内存的作用是内核为了高性能每个需要重复使用的对象都会有个池，这个slab池会cache大量常用的对象，所以会消耗大量的内存。具体可以运行slabtop命令查看。
slab内存的消耗我们可以通过/proc/slabinfo文件算出，具脚本为：
# echo `cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/}'` MB
74.7215 MB
三、PageTables内存
这部分内存我并没有细研究，这里就直接拉taobao上各位大牛的说法用吧：“struct page也有一定的大小(每个页一个,64bytes)，如果是2.6.32的话，每个页还有一个page_cgroup(32bytes)，也就是说内存大小的2.3%(96/4096)会被内核固定使用 。struct page是系统boot的时候就会根据内存大小算出来分配出去的，18内核是1.56%左右，32内核由于cgroup的原因会在2.3% 。”
而具体消耗可以通过/proc/meminfo里的pagetables项获取，脚本如下：
# echo `grep PageTables /proc/meminfo | awk '{print $2}'` KB
系统的硬开销占比并不多。
四、算算总帐
三者加起来发现要大于450M 。这里我们便于查看，再跑下脚本：
$ cat cm.sh
#/bin/bash
for PROC in `ls /proc/|grep "^[0-9]"`
if [ -f /proc/$PROC/statm ]; then
TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`
RSS=`expr $RSS + $TEP`
RSS=`expr $RSS \* 4`
PageTable=`grep PageTables /proc/meminfo | awk '{print $2}'`
SlabInfo=`cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/}'`
echo $RSS"KB", $PageTable"KB", $SlabInfo"MB"
printf "rss+pagetable+slabinfo=%sMB\n" `echo $RSS/1024 + $PageTable/1024 + $SlabInfo|bc`
382048KB, 4528KB, 74.8561MB
rss+pagetable+slabinfo=451.8561MB
total used free shared buffers cached
Mem: 996 842 154 0 106 376
-/+ buffers/cache: 359 637
Swap: 0 0 0
由于上面演示时，我强制回收过内存。目前实际已用内存为359M ，而我们上面三者之和是451M，比实际使用的大了100M左右。
多出的这部分内存是我们在计算rss内存时算重复了。因为rss内存包括我们使用的各种库和so等共享的模块。具体可以使用pmap指令查看详细的每个进程调用的lib库及已用内存值。这里以最简单的bash进程为例。
[root@91it ~]# pmap `pgrep bash`
1464: -bash
K r-x-- /bin/bash
d3000 40K rw--- /bin/bash
dd000 20K rw--- [ anon ]
dc000 36K rw--- /bin/bash
aK rw--- [ anon ]
K r-x-- /lib64/ld-2.12.so
a1f000 4K r---- /lib64/ld-2.12.so
a20000 4K rw--- /lib64/ld-2.12.so
a21000 4K rw--- [ anon ]
cK r-x-- /lib64/libc-2.12.so
d8a000 2048K ----- /lib64/libc-2.12.so
f8a000 16K r---- /lib64/libc-2.12.so
f8e000 4K rw--- /lib64/libc-2.12.so
f8f000 20K rw--- [ anon ]
0000003efaK r-x-- /lib64/libdl-2.12.so
0000003efa8K ----- /lib64/libdl-2.12.so
0000003efaK r---- /lib64/libdl-2.12.so
0000003efaK rw--- /lib64/libdl-2.12.so
0000003efbK r-x-- /lib64/libtinfo.so.5.7
0000003efb81d000 2048K ----- /lib64/libtinfo.so.5.7
0000003efba1d000 16K rw--- /lib64/libtinfo.so.5.7
fcK r---- /usr/lib/locale/locale-archive
e59000 48K r-x-- /lib64/libnss_files-2.12.so
eK ----- /lib64/libnss_files-2.12.so
65000 4K r---- /lib64/libnss_files-2.12.so
66000 4K rw--- /lib64/libnss_files-2.12.so
67000 12K rw--- [ anon ]
6b000 8K rw--- [ anon ]
6d000 28K r--s- /usr/lib64/gconv/gconv-modules.cache
74000 4K rw--- [ anon ]
00007fffK rw--- [ stack ]
00007fff481ff000 4K r-x-- [ anon ]
ffffffffffK r-x-- [ anon ]
total 108472K
2757: -bash
K r-x-- /bin/bash
d3000 40K rw--- /bin/bash
dd000 20K rw--- [ anon ]
dc000 36K rw--- /bin/bash
K rw--- [ anon ]
K r-x-- /lib64/ld-2.12.so
a1f000 4K r---- /lib64/ld-2.12.so
a20000 4K rw--- /lib64/ld-2.12.so
a21000 4K rw--- [ anon ]
cK r-x-- /lib64/libc-2.12.so
d8a000 2048K ----- /lib64/libc-2.12.so
f8a000 16K r---- /lib64/libc-2.12.so
f8e000 4K rw--- /lib64/libc-2.12.so
f8f000 20K rw--- [ anon ]
0000003efaK r-x-- /lib64/libdl-2.12.so
0000003efa8K ----- /lib64/libdl-2.12.so
0000003efaK r---- /lib64/libdl-2.12.so
0000003efaK rw--- /lib64/libdl-2.12.so
0000003efbK r-x-- /lib64/libtinfo.so.5.7
0000003efb81d000 2048K ----- /lib64/libtinfo.so.5.7
0000003efba1d000 16K rw--- /lib64/libtinfo.so.5.7
00007fda04cbK r---- /usr/lib/locale/locale-archive
00007fda0ab42000 48K r-x-- /lib64/libnss_files-2.12.so
00007fda0ab4e000 2048K ----- /lib64/libnss_files-2.12.so
00007fda0ad4e000 4K r---- /lib64/libnss_files-2.12.so
00007fda0ad4f000 4K rw--- /lib64/libnss_files-2.12.so
00007fda0ad50000 12K rw--- [ anon ]
00007fda0ad54000 8K rw--- [ anon ]
00007fda0ad56000 28K r--s- /usr/lib64/gconv/gconv-modules.cache
00007fda0ad5d000 4K rw--- [ anon ]
00007fff0e9e0000 84K rw--- [ stack ]
00007fff0e9ff000 4K r-x-- [ anon ]
ffffffffffK r-x-- [ anon ]
total 108472K
从上面的指令上看出，pid为两个进程使用很多相同的so文件，而且其内存地址也相同。这里个人认为rss部分的内存理论上是可以完全计算准确的。做法就是先遍历/proc下所有的pid，再pmap所有pid，对所有的输出结果进行汇总后去重。再将第二列的占用内存值求和(具体也可以考虑从/proc/pid/smaps文件入手 )。
五、其他情况
在第四步算算总帐中，我们看出 rrs内存 + slab内存 + pagetables内存 & 实际已用内存。但该情况并非是绝对的，也有例外。在我上面提到的oracle 使用场景下，事先分配了70g左右的oracle sga 空间(即内存空间)。而三者相加要远远小于实际使用的物理内存。这又要怎么解释呢?再去除cache和buffer的空间也要远远小于实际使用的内存。
[root@irora04s ~]# free -m
total used free shared buffers cached
-/+ buffers/cache:
[root@irora04s ~]# sh /tmp/mem.sh
4339696KB, 66056KB, 745.805MB
rss+pagetable+slabinfo=MB
total used free shared buffers cached
-/+ buffers/cache:
我个人的理解是事先分配的这部分sga内存，大部分是空page页，在未使用时虽然空间被占用了，但该内存地址内并不存在数据。所以一旦该机触发kdump 时，crash 的内存空间占用的磁盘空间 接近于rss+pagetable+slabinfo ，小于rss+pagetable+slabinfo+buffers+cached 。
最后这里同样推荐有时间看下nmon的。因为从nmon的内存统计信息来看，更便于理解内存的几个去向：
转自：/whereis-the-memory/4036.html查看:11150|回复：25
初级工程师
进段时间内存占比很高。通过观察，没找到什么原因。直接上图。
32G的内存。用了90%多了，可是通过top 查看。最占用内存才3%不到，那内存被啥东西占用了？
(40.54 KB)
(138.09 KB)
在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快
used&&-/+ buffers/cache 才是实际使用的内存
本帖最后由 小鬼忻3 于
22:42 编辑
学习了啊！！
心有多大，舞台就有多大！
楼主看错了，1楼正解
引用:原帖由 小鬼忻3 于
22:24 发表
在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快
(11.23 KB)
还有一种方法：
(25.94 KB)
Good Good study，Day Day up！！！
初级工程师
引用:原帖由 小鬼忻3 于
22:24 发表
在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快
use ... 那有什么方法把关闭了的程序的内存释放出来呢？请指教。
初级工程师
引用:原帖由 yfshare 于
01:15 发表
还有一种方法：
278019 结合1楼所说的，这命令能把已经关闭的程序所占用的内存显示出来吗？
初级工程师
引用:原帖由 小鬼忻3 于
22:24 发表
在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快
use ... 不是很明白。总内存的大小计算如下，帮忙看看是不是这样算的[root@localhost ~]# free -m
& && && && & total& && & used& && & free& &&&shared& & buffers& &&&cached
Mem:& && && &&&499& && &&&233& && &&&265& && && & 0& && && &22& && &&&154& && & //取265& &22&&154&&
-/+ buffers/cache:& && && &57& && &&&441& && && &&&//取57
Swap:& && && &1023& && && & 0& && & 1023
[root@localhost ~]# expr 22 + 154 + 265 + 57
引用:原帖由 convey123 于
09:17 发表
结合1楼所说的，这命令能把已经关闭的程序所占用的内存显示出来吗？ 第二个是显示有哪些进程在大量耗CPU/内存等排序显示前15个
Good Good study，Day Day up！！！
初级工程师
1楼的正确哦。。内存还很多呀。
free 看到的是预分配出去的物理内存，top看到的是当前进程实际占用的内存
优秀技术经理
引用:原帖由 小鬼忻3 于
22:24 发表
在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快
use ... 这个给力啊
初级工程师
上网折腾了一下 。结合1楼说的 。目的就应该是把cash那里的内存释放出来、应该就没问题了。百度了一下。
sync& && && && && && & 这个是把内存的信息写回硬盘
echo 1 & /proc/sys/vm/drop_caches
echo 2 & /proc/sys/vm/drop_caches
echo 3 & /proc/sys/vm/drop_caches
后面这三条。个人感觉就是把缓存清空了& &用虚拟机测试了没问题。改天上服务器弄弄。
谢谢各位啊。
初级工程师
扩展一下。如果是oracle数据库的表占用了内存。数据库建表是会预先占用内存空间。这样的话释放内存会导致表不可用吗？或者表的数据丢失？
初级工程师
引用:原帖由 convey123 于
10:04 发表
扩展一下。如果是oracle数据库的表占用了内存。数据库建表是会预先占用内存空间。这样的话释放内存会导致表不可用吗？或者表的数据丢失？ 应该不会 ， echo 1 & /proc/sys/vm/drop_caches&&释放的应该仅仅是用做缓存的内存空间，即 buffers和cached ，那些正在被进程使用的内存空间不会受到影响。
引用:原帖由 convey123 于
10:35 发表
上网折腾了一下 。结合1楼说的 。目的就应该是把cash那里的内存释放出来、应该就没问题了。百度了一下。
sync& && && && && && & 这个是把内存的信息写回硬盘
echo 1 & /proc/sys/vm/drop_caches
echo 2 & /proc/sys ... 不作死就不会死～～～～
有些服务好不容易cache些有用的东西，你全给清空了。。。。。。
初级工程师
引用:原帖由 叮咚2012 于
15:52 发表
应该不会 ， echo 1 & /proc/sys/vm/drop_caches&&释放的应该仅仅是用做缓存的内存空间，即 buffers和cached ，那些正在被进程使用的内存空间不会受到影响。 受教了。我想应该也是这样。总不至于把我正在运行的程序也干掉吧。
初级工程师
引用:原帖由 dn833 于
16:15 发表
不作死就不会死～～～～
有些服务好不容易cache些有用的东西，你全给清空了。。。。。。 当你每天都看这内存飚红报警的时候难道你会舒服？
引用:原帖由 convey123 于
09:16 发表
当你每天都看这内存飚红报警的时候难道你会舒服？ 哥只关心swap，只要不用到swap，物理内存爱怎么红就怎么红
初级工程师
引用:原帖由 dn833 于
09:32 发表
哥只关心swap，只要不用到swap，物理内存爱怎么红就怎么红 .......
无语了 。内存都98%了&&有个啥的风吹草动什么的 都怕不能及时处理啊。总的给自己留点余地啊。网页设计教程与开发
提供各种常见网页效果
提供各种各样的设计教程
装扮QQ，让QQ变得更酷
设计参考，提高自升水平
学习服务器和操作系统
提供各种素材和工具
收藏学习资料
您现在的位置：&&>>&&>>&&>>&正文
了解与查看Linux真实的使用内存
我们使用的Linux和Windows可不太一样，用top命令得出来的可能不是真实使用的内存，用free命令第二行才是系统真实使用的内存。如果发现PHP-CGI把你的内存占满了可不要惊慌哦。
　　Page cache和buffer cache一直以来是两个比较容易混淆的概念，在网上也有很多人在争辩和猜想这两个cache到底有什么区别，讨论到最后也一直没有一个统一和正确的结论，在我工作的这一段时间，page cache和buffer cache的概念曾经困扰过我，但是仔细分析一下，这两个概念实际上非常的清晰。如果能够了解到这两个cache的本质，那么我们在分析io问题的时候可能会更加得心应手。
　　Page cache实际上是针对文件系统的，是文件的缓存，在文件层面上的数据会缓存到page cache。文件的逻辑层需要映射到实际的物理磁盘，这种映射关系由文件系统来完成。当page cache的数据需要刷新时，page cache中的数据交给buffer cache，但是这种处理在2.6版本的内核之后就变的很简单了，没有真正意义上的cache操作。
　　Buffer cache是针对磁盘块的缓存，也就是在没有文件系统的情况下，直接对磁盘进行操作的数据会缓存到buffer cache中，例如，文件系统的元数据都会缓存到buffer cache中。
　　简单说来，page cache用来缓存文件数据，buffer cache用来缓存磁盘数据。在有文件系统的情况下，对文件操作，那么数据会缓存到page cache，如果直接采用dd等工具对磁盘进行读写，那么数据会缓存到buffer cache。
　　补充一点，在文件系统层每个设备都会分配一个def_blk_ops的文件操作方法，这是设备的操作方法，在每个设备的inode下面会存在一个 radix tree，这个radix tree下面将会放置缓存数据的page页。这个page的数量将会在top程序的buffer一栏中显示。如果设备做了文件系统，那么会生成一个 inode，这个inode会分配ext3_ops之类的操作方法，这些方法是文件系统的方法，在这个inode下面同样存在一个radix tree，这里会缓存文件的page页，缓存页的数量在top程序的cache一栏进行统计。从上面的分析可以看出，2.6内核中的buffer cache和page cache在处理上是保持一致的，但是存在概念上的差别，page cache针对文件的cache，buffer是针对磁盘块数据的cache，仅此而已。
　　现在不都是只有page cache了吗？ buffer pages其实也是page cache里面的页。只是多了一层抽象，通过buffer_head来进行一些访问管理
　　对,从Linux算法实现的角度，page cache和buffer cache目前是一样的，但是从功能抽象和具体应用来讲，这两者还是存在区别的，这一点可以从top工具的统计信息中看得出来，关注一下buffer和cache这两个统计量。
　　增加一些资料：
　　A buffer is something that has yet to be "written" to disk. A cache is something that has been "read" from the disk and stored for later use.
　　在终端中敲入：free
　　显示：& total& used& free& shared& buffers& cached
　　Mem:&&& 332& 16936&&& 0&&&&& 85540&&& 126384
　　-/+ buffers/cache:2
　　系统的总物理内存：255268Kb（256M），但系统当前真正可用的内存并不是第一行free 标记的 16936Kb，它仅代表未被分配的内存。
　　我们使用total1、used1、free1、used2、free2 等名称来代表上面统计数据的各值，1、2 分别代表第一行和第二行的数据。
　　total1：表示物理内存总量。
　　used1：表示总计分配给缓存（包含buffers 与cache ）使用的数量，但其中可能部分缓存并未实际使用。
　　free1：未被分配的内存。
　　shared1：共享内存，一般系统不会用到，这里也不讨论。
　　buffers1：系统分配但未被使用的buffers 数量。
　　cached1：系统分配但未被使用的cache 数量。buffer 与cache 的区别见后面。
　　used2：实际使用的buffers 与cache 总量，也是实际使用的内存总量。
　　free2：未被使用的buffers 与cache 和未被分配的内存之和，这就是系统当前实际可用内存。
　　可以整理出如下等式：
　　total1 = used1 + free1
　　total1 = used2 + free2
　　used1 = buffers1 + cached1 + used2
　　free2 = buffers1 + cached1 + free1
转载请注明:破洛洛(谢谢合作)
上一篇文章： 下一篇文章：
网友评论：