上週發現我們的一臺應用伺服器上面的記憶體莫名其妙被吃光，檢視所有程序所使用的記憶體實際只佔用了14G左右

[root@app]# ps aux|awk '{sum+=$6} END {print sum/1024}'
14457.2

按照系統的記憶體32G來算，應該還有17G左右可用，但是檢視可用記憶體卻只有2487M

[root@app]# free -m
                         total       used       free     shared    buffers     cached
Mem:                     32177
 
      32084         93          0       1612        782
-/+ buffers/cache:                  29690       2487
Swap:                        0          0          0

那麼還有15G左右的記憶體去哪了呢？

進一步檢視meminfo

[root@app]# cat /proc/meminfo
MemTotal:     32949824 kB
MemFree:         99736 kB
Buffers:       1423264 kB
Cached:        1419108
 
 kB
SwapCached:          0 kB
Active:       15054636 kB
Inactive:      1275644 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     32949824 kB
LowFree:         99736 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:          131728 kB
Writeback:           0 kB
AnonPages:    13487512
 
 kB
Mapped:          18640 kB
Slab:         16370936 kB
PageTables:      93860 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  16474912 kB
Committed_AS: 16199820 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    264192 kB
VmallocChunk: 34359473391 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

其中的slab，檢視相關資料：
通常的說法是：核心資料結構快取的大小，可以減少申請和釋放記憶體帶來的消耗
這裡的說法太籠統了

詳細的說法如下：
在linux核心中會有許多小物件，這些物件構造銷燬十分頻繁，比如i-node，dentry。這麼這些物件如果每次構建的時候就向記憶體要一個頁，而其實際大小可能只有幾個位元組，這樣就非常浪費，為了解決這個問題就引入了一種新的機制來處理在同一頁框中如何分配小儲存器區，這個機制可以減少申請和釋放記憶體帶來的消耗，這些小儲存器區的記憶體稱為Slab

在suse和ubuntu中檢視meminfo會發現他們將slab分的很清楚，包括SReclaimable和SUnreclaim
其中SReclaimable指可收回Slab的大小，SUnreclaim不可回收的slab大小，但是在redhat之中沒有進行區分

通過檢視伺服器上面的inode（使用df -i）,發現已經佔用了40%，與同事溝通時發現report_data/generate 目錄下很多小檔案，造成了大量佔用inode，刪除掉部分之後，目前inode還佔用了16%

[root@app]# df -i
/dev/mapper/kw-DATA  53248000 8106118 45141882   16% /mnt/DATA

這時候可用記憶體達到了差不多10G左右，meminfo中的slab佔用在4G左右了。