liunx的Slab占用比较高的问题

最近经常报内存超过80%的阀值.

统计了下内存实际使用只有1.6G,希望能帮我们分析下为什么内存的使用率显示使用了3178M.

 

-bash-3.2$ ps -eo 'pid,rss' --sort=-rss

(Not all processes could be identified, non-owned process info

 will not be shown, you would have to be root to see it all.)

  PID   RSS

20872 732320

 5030 617408

15583 219672

15320 15940

 9654 10088

 1846  9100

 8580  8748

 9665  8588

 3938  8304

 2711  3996

 8575  3276

 7753  3260

19912  2464

 2689  2140

14368  2036

28490  1968

 2690  1800

 7755  1748

 7756  1568

 2049  1548

 2429  1480

 1841  1304

 2588  1304

23519  1212

23559  1176

 2687  1052

 8587  1048

 8592  1040

 2386   888

 1897   864

 8593   856

 1833   808

 8588   804

 8594   740

 8590   736

29128   672

 2526   652

    1   648

 1842   648

 1788   584

 1946   572

 1864   568

 1856   556

 1806   448

 2558   416

 2559   416

 2562   416

 2585   416

 2586   416

 2587   416

  450   368

 1791   332

 2405   284

    2     0

    3     0

    4     0

    5     0

    6     0

    7     0

    8     0

    9     0

   10     0

   45     0

   50     0

   51     0

   52     0

   97     0

   98     0

  101     0

  103     0

  177     0

  180     0

  181     0

  182     0

  318     0

  331     0

  332     0

  360     0

  361     0

  362     0

  372     0

  391     0

  417     0

 1339     0

 1340     0

 1341     0

 1368     0

 6460     0

 6468     0

 

然后统计 rss列的内存总数是1,680M 远小于显示使用的3G.请问那部分内存被什么程序占用了?

确认应用进程占用内存不多，可以安装工具atop，或者执行命令cat /proc/meminfo |grep -i slab看看slab占用的内存是否较多。

 

SLAB是Linux操作系统的一种内存分配机制。其工作是针对一些经常分配并释放的对象，您可以看看哪些应用进程的slab占用的内存比较多，是否这些应用需要频繁的请求和释放内存，比如进行一些小文件的读写。如果都是应用的正常使用，可以考虑升级服务器内存，如果内存不足影响业务，需要临时释放一下slab占用的内存，

可以参考以下步骤： #echo 2 > /proc/sys/vm/drop_caches

等内存回收完毕后再 #echo 0 > /proc/sys/vm/drop_caches

其中drop_caches的4个值有如下含义：

0：不做任何处理，由系统自己管理 1：清空pagecache 2：清空dentries和inodes 3：清空pagecache、dentries和inodes

 

--------------------------------------------------

问题描述

Linux服务器内存使用量超过阈值，触发报警。

问题排查

首先，通过free命令观察系统的内存使用情况，显示如下：

total       used       free     shared    buffers     cached
Mem:      24675796   24587144      88652          0     357012    1612488
-/+ buffers/cache:   22617644    2058152
Swap:      2096472     108224    1988248

其中，可以看出内存总量为24675796KB，已使用22617644KB，只剩余2058152KB。

然后，接着通过top命令，shift + M按内存排序后，观察系统中使用内存最大的进程情况，发现只占用了18GB内存，其他进程均很小，可忽略。

因此，还有将近4GB内存（22617644KB-18GB，约4GB）用到什么地方了呢？

进一步，通过cat /proc/meminfo发现，其中有将近4GB（3688732 KB）的Slab内存：

......
Mapped:          25212 kB
Slab:          3688732 kB
PageTables:      43524 kB
......

Slab是用于存放内核数据结构缓存，再通过slabtop命令查看这部分内存的使用情况：

OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
13926348 13926348 100%    0.21K 773686       18   3494744K dentry_cache
334040 262056  78%    0.09K   8351       40     33404K buffer_head
151040 150537  99%    0.74K  30208        5    120832K ext3_inode_cache

发现其中大部分（大约3.5GB）都是用于了dentry_cache。

问题解决

1. 修改/proc/sys/vm/drop_caches，释放Slab占用的cache内存空间（参考drop_caches的官方文档）：

Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
* echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
* echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
* echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are notfreeable, the user should run "sync" first in order to make sure allcached objects are freed.
This tunable was added in 2.6.16.

2. 方法1需要用户具有root权限，如果不是root，但有sudo权限，可以通过sysctl命令进行设置：

$sync
$sudo sysctl -w vm.drop_caches=3
$sudo sysctl -w vm.drop_caches=0 #recovery drop_caches

操作后可以通过sudo sysctl -a | grep drop_caches查看是否生效。

3. 修改/proc/sys/vm/vfs_cache_pressure，调整清理inode/dentry caches的优先级（默认为100），LinuxInsight中有相关的解释：

At the default value of vfs_cache_pressure = 100 the kernel will attempt to reclaim dentries and inodes at a “fair” rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes.

具体的设置方法，可以参考方法1或者方法2均可。

参考资料

• https://www.kernel.org/doc/Documentation/sysctl/vm.txt
• http://major.io/2008/12/03/reducing-inode-and-dentry-caches-to-keep-oom-killer-at-bay/
• http://linux-mm.org/Drop_Caches

---

以下记录的是进一步排查的进展情况。

更深层次的原因

上文排查到Linux系统中有大量的dentry_cache占用内存，为什么会有如此多的dentry_cache呢？

1. 首先，弄清楚dentry_cache的概念及作用：目录项高速缓存，是Linux为了提高目录项对象的处理效率而设计的；它记录了目录项到inode的映射关系。因此，当应用程序发起stat系统调用时，就会创建对应的dentry_cache项（更进一步，如果每次stat的文件都是不存在的文件，那么总是会有大量新的dentry_cache项被创建）。

2. 当前服务器是storm集群的节点，首先想到了storm相关的工作进程，strace一下storm的worker进程发现其中有非常频繁的stat系统调用发生，而且stat的文件总是新的文件名：

sudo strace -fp <pid> -e trace=stat

3. 进一步观察到storm的worker进程会在本地目录下频繁的创建、打开、关闭、删除心跳文件，每秒钟一个新的文件名：

sudo strace -fp <pid> -e trace=open,stat,close,unlink

以上就是系统中为何有如此多的dentry_cache的原因所在。

一个奇怪的现象

通过观察/proc/meminfo发现，slab内存分为两部分：

SReclaimable // 可回收的slab
SUnreclaim // 不可回收的slab

当时服务器的现状是：slab部分占用的内存，大部分显示的都是SReclaimable，也就是说可以被回收的。

但是通过slabtop观察到slab内存中最主要的部分（dentry_cache）的OBJS几乎都是ACTIVE的，显示100%处于被使用状态。

OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
13926348 13926348 100%    0.21K 773686       18   3494744K dentry_cache
334040 262056  78%    0.09K   8351       40     33404K buffer_head
151040 150537  99%    0.74K  30208        5    120832K ext3_inode_cache

为什么显示可回收的，但是又处于ACTIVE状态呢？求Linux内核达人看到后热心解释下：（

会不会由于是ACTIVE状态，导致dcache没有被自动回收释放掉呢？

让系统自动回收dcache

上一小节，我们已经提到，服务器上大部分的slab内存是SReclaimable可回收状态的，那么，我们能不能交给操作系统让他在某个时机自动触发回收操作呢？答案是肯定的。

查了一些关于Linux dcache的相关资料，发现操作系统会在到了内存临界阈值后，触发kswapd内核进程工作才进行释放，这个阈值的计算方法如下：

1. 首先，grep low /proc/zoneinfo，得到如下结果：

        low      1
        low      380
        low      12067

2. 将以上3列加起来，乘以4KB，就是这个阈值，通过这个方法计算后发现当前服务器的回收阈值只有48MB，因此很难看到这一现象，实际中可能等不到回收，操作系统就会hang住没响应了。

3. 可以通过以下方法调大这个阈值：将vm.extra_free_kbytes设置为vm.min_free_kbytes和一样大，则/proc/zoneinfo中对应的low阈值就会增大一倍，同时high阈值也会随之增长，以此类推。

$ sudo sysctl -a | grep free_kbytes       
vm.min_free_kbytes = 39847
vm.extra_free_kbytes = 0
$ sudo sysctl -w vm.extra_free_kbytes=836787  ######1GB
####系统中 没有vm.extra_free_kbytes 这个参数,修改下面的参数
$ /sbin/sysctl -w vm.min_free_kbytes=836787

4. 举个例子，当low阈值被设置为1GB的时候，当系统free的内存小于1GB时，观察到kswapd进程开始工作（进程状态从Sleeping变为Running），同时dcache开始被系统回收，直到系统free的内存介于low阈值和high阈值之间，停止回收。

原文链接：http://www.cnblogs.com/panfeng412/p/drop-caches-under-linux-system.html

http://www.cnblogs.com/panfeng412/p/drop-caches-under-linux-system-2.html

----------------------------------

 

http://os.51cto.com/art/201402/430458.htm

http://www.yidianzixun.com/article/news_e7e6ffd66c01fff1687c17dd3af9ce86?s=3

内存模块泄露排查

http://blog.csdn.net/cjf_iceking/article/details/19191595

 

http://leejia.blog.51cto.com/4356849/1431756

 

http://blog.csdn.net/vanbreaker/article/details/7671618

http://www.oenhan.com/size-512-slab-kmalloc

http://blog.chinaunix.net/uid-9543173-id-3571436.html

 

http://blog.csdn.net/bullbat/article/details/7194794