前几天 纯上 同学问了一个问题:
这个问题不止一个同学遇到过了,之前子嘉同学也遇到这个问题,内存的计算总是一个迷糊账。 我们今天来把它算个清楚下!
通常我们是这样看内存的剩余情况的:
- $free-mtotal usedfreeshared buffers cachedMem: 48262 7913 40349 0 14 267-/+ buffers/cache: 7631 40631Swap: 2047 336 1711
那么这个信息是如何解读的呢,以下这个图解释的挺清楚的!
补充(不少人反映图不清晰,请参考:http://www.redbooks.ibm.com/redpapers/pdfs/redp4285.pdf P46-47)
上面的情况下我们总的内存有 48262M,用掉了 7913M。 其中 buffer+cache 总共 14+267=281M, 由于这种类型的内存是可以回收的,虽然我们用掉了 7913M,但是实际上我们如果实在需要的话,这部分 buffer/cache 内存是可以放出来的。
我们来演示下:
$sudosysctl vm.drop_caches=3vm.drop_caches = 3$free-mtotal usedfreeshared buffers cachedMem: 48262 7676 40586 0 3 41-/+ buffers/cache: 7631 40631Swap: 2047 336 1711
我们把 buffer/cache 大部分都清除干净了,只用了 44M,所以我们这次 used 的空间是 7676M。
到现在我们比较清楚几个概念:
1. 总的内存多少
2. buffer/cache 内存可以释放的。
3. used 的内存的概率。
即使是这样我们还是要继续追查下 used 的空间(7637M) 到底用到哪里去了?
这里首先我们来介绍下 nmon 这个工具,它对内存的使用显示比较直观。
使用的内存的去向我们很自然的就想到操作系统系统上的各种进程需要消耗各种内存,我们透过 top 工具来看下:
通常我们会看进程的 RES 这一项,这项到底是什么意思呢?这个数字从哪里出来的呢? 通过 strace 对 top 和 nmon 的追踪和结合源码,我们确定这个值是从 / proc/PID/statm 的第二个字段读取出来的.
那这个字段什么意思呢?
man proc 或者 http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html 会详细的解释 / proc / 下的文件的具体意思,我们摘抄下:
resident set size 也就是每个进程用了具体的多少页的内存。由于 linux 系统采用的是虚拟内存,进程的代码,库,堆和栈使用的内存都会消耗内存,但是申请出来的内存,只要没真正 touch 过,是不算的,因为没有真正为之分配物理页面。
我们实际进程使用的物理页面应该用 resident set size 来算的,遍历所有的进程,就可以知道所有的所有的进程使用的内存。
我们来实验下 RSS 的使用情况:
$catRSS.sh#/bin/bashforPROCin`ls/proc/|grep"^[0-9]"`doif[-f /proc/$PROC/statm];thenTEP=`cat/proc/$PROC/statm |awk'{print ($2)}'`RSS=`expr$RSS + $TEP`fidoneRSS=`expr$RSS \* 4`echo$RSS"KB"$ ./RSS.sh7024692KB
从数字来看,我们的进程使用了大概 7024M 内存,距离 7637M 还有几百 M 内存哪里去了? 哪里去了? 猫吃掉了?
我们再回头来仔细看下 nmon 的内存统计表。
那个该死的 slab 是什么呢? 那个 PageTables 又是什么呢?
简单的说内核为了高性能每个需要重复使用的对象都会有个池,这个 slab 池会 cache 大量常用的对象,所以会消耗大量的内存。运行命令:
我们可以看到:
vcA=="class="alignnone size-full wp-image-2464"height="211" lazyload="/uploadfile/Collfiles/20170225/20170225120127613.jpg" width="860"/>
从图我们可以看出各种对象的大小和数目,遗憾的是没有告诉我们 slab 消耗了多少内存。
我们自己来算下好了:
$echo`cat/proc/slabinfo |awk'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'` MB904.256 MB
好吧,把每个对象的数目 * 大小,再累加,我们就得到了总的内存消耗量: 904M
那么 PageTables 呢? 我们万能的内核组的同学现身了:
好吧,知道是干嘛的啦,管理这些物理页面的硬开销,那么具体是多少呢?
$echo`grepPageTables /proc/meminfo |awk'{print $2}'` KB58052 KB
好吧,小结下!内存的去向主要有 3 个:1. 进程消耗。 2. slab 消耗 3.pagetable 消耗。
我把三种消耗汇总下和 free 出的结果比对下, 这个脚本的各种计算项仲同学帮忙搞定的:
$catcm.sh#/bin/bashforPROCin`ls/proc/|grep"^[0-9]"`doif[-f /proc/$PROC/statm];thenTEP=`cat/proc/$PROC/statm |awk'{print ($2)}'`RSS=`expr$RSS + $TEP`fidoneRSS=`expr$RSS \* 4`PageTable=`grepPageTables /proc/meminfo |awk'{print $2}'`SlabInfo=`cat/proc/slabinfo |awk'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'` echo$RSS"KB", $PageTable"KB", $SlabInfo"MB"printf"rss+pagetable+slabinfo=%sMB\n"`echo$RSS/1024 + $PageTable/1024 + $SlabInfo|bc`free-m $ ./cm.sh7003756KB, 59272KB, 904.334MBrss+pagetable+slabinfo=7800.334MBtotal usedfreeshared buffers cachedMem: 48262 8050 40211 0 17 404-/+ buffers/cache: 7629 40633Swap: 2047 336 1711
free 报告说 7629M, 我们的 cm 脚本报告说 7800.3M, 我们的 CM 多报了 171M。
damn, 这又怎么回事呢?
我们重新校对下我们的计算。 我们和 nmon 来比对下,slab 和 pagetable 的值是吻合的。 那最大的问题可能在进程的消耗计算上。
resident resident set size 包括我们使用的各种库和 so 等共享的模块,在前面的计算中我们重复计算了。
$ pmap `pgrepbash`...22923: -bash0000000000400000 848K r-x-- /bin/bash00000000006d3000 40K rw--- /bin/bash00000000006dd000 20K rw--- [anon]00000000008dc000 36K rw--- /bin/bash00000000013c8000 592K rw--- [anon]000000335c400000 116K r-x-- /lib64/libtinfo.so.5.7...0000003ec5220000 4K rw--- /lib64/ld-2.12.so0000003ec5221000 4K rw--- [anon]0000003ec5800000 1628K r-x-- /lib64/libc-2.12.so...0000003ec5b9c000 20K rw--- [anon]00007f331b910000 96836K r---- /usr/lib/locale/locale-archive00007f33217a1000 48K r-x-- /lib64/libnss_files-2.12.so...00007f33219af000 12K rw--- [anon]00007f33219bf000 8K rw--- [anon]00007f33219c1000 28K r--s- /usr/lib64/gconv/gconv-modules.cache00007f33219c8000 4K rw--- [anon]00007fff5e553000 84K rw--- [stack]00007fff5e5e4000 4K r-x-- [anon]ffffffffff600000 4K r-x-- [anon]total 108720K
多出的 171M 正是共享库重复计算的部分。
但是由于每个进程共享的东西都不一样,我们也没法知道每个进程是如何共享的,没法做到准确的区分。
所以只能留点小遗憾,欢迎大家来探讨。
总结:内存方面的概念很多,需要深入挖掘!
就爱阅读 www.92to.com 网友整理上传, 为您提供最全的知识大全, 期待您的分享,转载请注明出处。
来源: http://www.92to.com/bangong/2017/02-27/17747860.html