前言
前几天 纯上 同学问了一个问题:
我
ps aux
看到的RSS内存只有不到30M,但是free看到内存却已经使用了7,8G了,已经开始swap了,请问ps aux的实际物理内存统计是不是漏了哪些内存没算?我有什么办法确定free中used的内存都去哪儿了呢?
这个问题不止一个同学遇到过了,之前子嘉同学也遇到这个问题,内存的计算总是一个迷糊账。 我们今天来把它算个清楚下!
解答
通常我们是这样看内存的剩余情况的:
1 | $free -m |
那么这个信息是如何解读的呢,以下这个图解释的挺清楚的!
上面的情况下我们总的内存有48262M,用掉了7913M
。 其中 buffer+cache
总共 14+267=281M
, 由于这种类型的内存是可以回收的,虽然我们用掉了 7913M
,但是实际上我们如果实在需要的话,这部分buffer/cache
内存是可以放出来的。
我们来演示下:
1 | $ sudo sysctl vm.drop_caches=3 |
我们把 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的使用情况:
1 | $ cat RSS.sh |
从数字来看,我们的进程使用了大概7024M内存,距离7637M还有几百M内存哪里去了? 哪里去了? 猫吃掉了?
我们再回头来仔细看下 nmon
的内存统计表。
那个该死的slab是什么呢? 那个PageTables又是什么呢?
简单的说内核为了高性能每个需要重复使用的对象都会有个池,这个slab池会cache大量常用的对象,所以会消耗大量的内存。运行命令:
1 | $ slabtop |
我们可以看到:
从图我们可以看出各种对象的大小和数目,遗憾的是没有告诉我们slab
消耗了多少内存。
我们自己来算下好了:
1 | $ echo `cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'` MB |
好吧,把每个对象的数目*大小,再累加,我们就得到了总的内存消耗量: 904M
那么PageTables
呢? 我们万能的内核组的同学现身了:
- 伯瑜: 你还没有计算page tables的大小,还有struct page也有一定的大小(每个页一个,64bytes),如果是2.6.32的话,每个页还有一个page_cgroup(32bytes),也就是说内存大小的2.3%(96/4096)会被内核固定使用的
- 含黛: struct page是系统boot的时候就会根据内存大小算出来分配出去的,18内核是1.56%左右,32内核由于cgroup的原因会在2.3%
好吧,知道是干嘛的啦,管理这些物理页面的硬开销,那么具体是多少呢?
1 | $ echo `grep PageTables /proc/meminfo | awk '{print $2}'` KB |
好吧,小结下!内存的去向主要有3个:
- 1、进程消耗。
- 2、slab消耗
- 3、pagetable消耗。
我把三种消耗汇总下和free出的结果比对下,这个脚本的各种计算项仲同学帮忙搞定的:
1 | $ cat cm.sh |
free 报告说 7629M
, 我们的cm脚本报告说 7800.3M
, 我们的CM多报了 171M
。
damn,这又怎么回事呢?
我们重新校对下我们的计算。 我们和nmon来比对下,slab和pagetable的值是吻合的。 那最大的问题可能在进程的消耗计算上。
resident resident set size 包括我们使用的各种库和so等共享的模块,在前面的计算中我们重复计算了。
1 | $ pmap `pgrep bash` |
多出的171M正是共享库重复计算的部分。
但是由于每个进程共享的东西都不一样,我们也没法知道每个进程是如何共享的,没法做到准确的区分。
所以只能留点小遗憾,欢迎大家来探讨。
总结:
内存方面的概念很多,需要深入挖掘!
祝玩的开心!
- 作者:Yu Feng
- 原文:http://blog.yufeng.info/archives/2456
---本文结束感谢您的阅读。微信扫描二维码,关注我的公众号---
本文链接: https://www.yp14.cn/2020/09/01/Linux-Used内存到底哪里去了/
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!