转载:Linux Used内存到底到哪里去了?
2016-06-01 10:34
423 查看
转自:http://blogread.cn/it/article/6264?f=wb2
有时在Linux下会碰到这样的问题:ps aux看到的RSS内存只有不到30M,但是free看到内存却已经使用了7、8G了,已经开始swap了,这是怎么回事?
通常我们查看系统内存都是用free命令:
如何解读输出的这些信息呢?下面这个图看的挺清楚:
图中内存总共4092M,用掉了3270M,其中buffers+cached是36+1482=1518M,这部分内存是可以回收的,如果需要的话,可以释放出来,这样用掉的内存就是3270-1518=1752M,由于会有一部分计算和系统的耗费,这个值是1748M。
释放缓存:
或者:
现在清楚了几个概念:
总的内存是多少
buffer/cache内存可以释放
used内存的概率
下面就要追查以下used的空间到底去哪儿了。
首先介绍nmon这份工具,它对内存的使用显示比较直观:
使用的内存的去向我们很自然的就想到操作系统系统上的各种进程需要消耗各种内存,我们透过top工具来看下:
通常我们会看进程的RES这一项,这项到底是什么意思呢?这个数字从哪里出来的呢? 通过strace对top和nmon的追踪和结合源码,我们确定这个值是从/proc/PID/statm的第二个字段读取出来的.
resident set size 也就是每个进程用了具体的多少页的内存。由于linux系统采用的是虚拟内存,进程的代码,库,堆和栈使用的内存都会消耗内存,但是申请出来的内存,只要没真正touch过,是不算的,因为没有真正为之分配物理页面。
我们实际进程使用的物理页面应该用resident set size来算的,遍历所有的进程,就可以知道所有的所有的进程使用的内存。
实验RSS的使用情况:
从数字来看,我们的进程使用了大概7024M内存,距离7637M还有几百M内存哪里去了? 哪里去了?
仔细看一下nmon的内存统计表:
slab又是什么?PageTable又是什么?
简单的说内核为了高性能每个需要重复使用的对象都会有个池,这个slab池会cache大量常用的对象,所以会消耗大量的内存。运行命令:
可以看到
虽然没有给出,但给出了具体情况,可以自己算:
PageTables呢?
struct page是系统boot的时候就会根据内存大小算出来分配出去的,18内核是1.56%左右,32内核由于cgroup的原因会在2.3%
进程消耗
slab消耗
pagetable消耗
汇总一下:
free报告说7629M, 我们的cm脚本报告说7800.3M, 我们的CM多报了171M。
我们重新校对下我们的计算。 我们和nmon来比对下,slab和pagetable的值是吻合的。 那最大的问题可能在进程的消耗计算上。
resident resident set size 包括我们使用的各种库和so等共享的模块,在前面的计算中我们重复计算了。
有时在Linux下会碰到这样的问题:ps aux看到的RSS内存只有不到30M,但是free看到内存却已经使用了7、8G了,已经开始swap了,这是怎么回事?
通常我们查看系统内存都是用free命令:
$free -m total used free shared buffers cached Mem: 2010 1721 289 7 99 606 -/+ buffers/cache: 1015 995 Swap: 3904 0 3904
如何解读输出的这些信息呢?下面这个图看的挺清楚:
图中内存总共4092M,用掉了3270M,其中buffers+cached是36+1482=1518M,这部分内存是可以回收的,如果需要的话,可以释放出来,这样用掉的内存就是3270-1518=1752M,由于会有一部分计算和系统的耗费,这个值是1748M。
释放缓存:
$ sudo sysctl vm.drop_caches=3 vm.drop_caches = 3 $ free -m total used free shared buffers cached Mem: 48262 7676 40586 0 3 41 -/+ buffers/cache: 7631 40631 Swap: 2047 336 1711
或者:
#free -m total used free shared buffers cached Mem: 2010 1742 268 8 100 608 -/+ buffers/cache: 1033 976 Swap: 3904 0 3904 #echo 1 > /drop/sys/vm/drop_caches #free -m total used free shared buffers cached Mem: 2010 1204 806 8 0 162 -/+ buffers/cache: 1041 969 Swap: 3904 0 3904
现在清楚了几个概念:
总的内存是多少
buffer/cache内存可以释放
used内存的概率
下面就要追查以下used的空间到底去哪儿了。
首先介绍nmon这份工具,它对内存的使用显示比较直观:
使用的内存的去向我们很自然的就想到操作系统系统上的各种进程需要消耗各种内存,我们透过top工具来看下:
通常我们会看进程的RES这一项,这项到底是什么意思呢?这个数字从哪里出来的呢? 通过strace对top和nmon的追踪和结合源码,我们确定这个值是从/proc/PID/statm的第二个字段读取出来的.
/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)
resident set size 也就是每个进程用了具体的多少页的内存。由于linux系统采用的是虚拟内存,进程的代码,库,堆和栈使用的内存都会消耗内存,但是申请出来的内存,只要没真正touch过,是不算的,因为没有真正为之分配物理页面。
我们实际进程使用的物理页面应该用resident set size来算的,遍历所有的进程,就可以知道所有的所有的进程使用的内存。
实验RSS的使用情况:
#! /bin/bash for PROC in `ls /proc/ | grep "^[0-9]"` do if [ -f /proc/$PROC/statm ]; then TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'` RSS=`expr $RSS + $TEP` fi done RSS=`expr $RSS \* 4` echo $RSS"KB"
从数字来看,我们的进程使用了大概7024M内存,距离7637M还有几百M内存哪里去了? 哪里去了?
仔细看一下nmon的内存统计表:
slab又是什么?PageTable又是什么?
简单的说内核为了高性能每个需要重复使用的对象都会有个池,这个slab池会cache大量常用的对象,所以会消耗大量的内存。运行命令:
$slabtop
可以看到
虽然没有给出,但给出了具体情况,可以自己算:
$echo `cat /proc/slabinfo | awk 'BEGIN{sum=0;} {sum=sum+$3*$4;}END{print sum/1024/1024}'`MB 904.256 MB
PageTables呢?
struct page是系统boot的时候就会根据内存大小算出来分配出去的,18内核是1.56%左右,32内核由于cgroup的原因会在2.3%
$echo `grep PageTables /proc/meminfo | awk '{print $2}'` KB 58052 KB
小结
内存的去向主要有3个:进程消耗
slab消耗
pagetable消耗
汇总一下:
#/bin/bash for PROC in `ls /proc/ | grep "^[0-9]"` do if [ -f /proc/$PROC/statm ]; then TEP=`cat /proc/$PROC/statm | awk '{print $2}'` RSS=`expr $RSS + $TEP` fi done 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/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.sh 7003756KB, 59272KB, 904.334MB rss+pagetable+slabinfo=7800.334MB total used free shared buffers cached Mem: 48262 8050 40211 0 17 404 -/+ buffers/cache: 7629 40633 Swap: 2047 336 1711
free报告说7629M, 我们的cm脚本报告说7800.3M, 我们的CM多报了171M。
我们重新校对下我们的计算。 我们和nmon来比对下,slab和pagetable的值是吻合的。 那最大的问题可能在进程的消耗计算上。
resident resident set size 包括我们使用的各种库和so等共享的模块,在前面的计算中我们重复计算了。
相关文章推荐
- linux 常用命令笔记
- centos安装youcompleteme
- linux tr命令详解
- VNC远程连接CentOS6.5桌面笔记
- linux虚拟机桥连配置IP
- linux共享文件
- 使用NPAPI编写跨平台(Windows/Linux/Mac)跨浏览器(Chrome/Firefox/Safari)的插件
- Linux SWAP 交换分区配置说明
- 十二. Linux系统的环境变量的功能
- linux查询cpu
- /etc/crontab文件及 crontab命令
- Linux内vi的使用
- 关于 CentOS 7 里面 普通用户 Ulimit max user processes 值的问题
- Linux SVN 服务器配置以及客户端使用
- CentOS tengine mysql 5.7 php 5.6
- linux修改hostname
- CentOS 7 源码编译安装 Mysql 5.7
- centos学习笔记
- OpenStack - liberty CentOS 7
- 九. Linux的环境变量PATH