問題描述

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 1low 380low 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

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

轉載于:https://blog.51cto.com/lucifer119/1364760

總結

以上是生活随笔為你收集整理的Cache占用过多内存导致Linux系统内存不足问题排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。