Linux服務器Cache占用過多內存導致系統內存不足問題的排查解決(續)


作者: 大圓那些事 | 文章可以轉載,請以超鏈接形式標明文章原始出處和作者信息

網址: http://www.cnblogs.com/panfeng412/archive/2013/12/17/drop-caches-under-linux-system-2.html

前一篇文章里已經描述了具體遇到的問題及一些解決方法。但是還有些疑問點沒有搞清楚,進一步學習了Linux系統下內存的分配使用機制,這里有兩個資料講的比較全面:

Where is the memory going? Memory waste under Linux

Where is the memory going?Memory usage in the 2.6 kernel

以下記錄的是進一步排查的進展情況。

更深層次的原因

前一篇文章里排查到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

 4. 舉個例子,當low閾值被設置為1GB的時候,當系統free的內存小於1GB時,觀察到kswapd進程開始工作(進程狀態從Sleeping變為Running),同時dcache開始被系統回收,直到系統free的內存介於low閾值和high閾值之間,停止回收。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM