2. 程式人生 > >解決liunx的Slab佔用比較高的有關問題

解決liunx的Slab佔用比較高的有關問題

阿新 • • 發佈：2019-01-10

最近經常報記憶體超過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命令觀察系統的記憶體使用情況，顯示如下：

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

其中，可以看出記憶體總量為24675796KB，已使用22617644KB，只剩餘2058152KB。

然後，接著通過top命令，shift + M按記憶體排序後，觀察系統中使用記憶體最大的程序情況，發現只佔用了18GB記憶體，其他程序均很小，可忽略。

因此，還有將近4GB記憶體（22617644KB-18GB，約4GB）用到什麼地方了呢？

進一步，通過cat /proc/meminfo發現，其中有將近4GB（3688732 KB）的Slab記憶體：

  1. ...... 
  2. Mapped:          25212 kB 
  3. Slab:          3688732 kB 
  4. PageTables:      43524 kB 
  5. ...... 

Slab是用於存放核心資料結構快取，再通過slabtop命令檢視這部分記憶體的使用情況：

  1. OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME 
  2. 13926348 13926348 100%    0.21K 773686       18   3494744K dentry_cache 
  3. 334040 262056  78%    0.09K   8351       40     33404K buffer_head 
  4. 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的官方文件）：

  1. Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free. 
  2. To free pagecache: 
  3. * echo 1 > /proc/sys/vm/drop_caches 
  4. To free dentries and inodes: 
  5. * echo 2 > /proc/sys/vm/drop_caches 
  6. To free pagecache, dentries and inodes: 
  7. * echo 3 > /proc/sys/vm/drop_caches 
  8. 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. 
  9. This tunable was added in 2.6.16. 

2. 方法1需要使用者具有root許可權，如果不是root，但有sudo許可權，可以通過sysctl命令進行設定：

  1. $sync 
  2. $sudo sysctl -w vm.drop_caches=3
  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中有相關的解釋：

  1. 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

4. 舉個例子，當low閾值被設定為1GB的時候，當系統free的記憶體小於1GB時，觀察到kswapd程序開始工作（程序狀態從Sleeping變為Running），同時dcache開始被系統回收，直到系統free的記憶體介於low閾值和high閾值之間，停止回收。

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

相關推薦

解決liunx的Slab佔用比較高的有關問題

最近經常報記憶體超過80%的閥值. 統計了下記憶體實際使用只有1.6G,希望能幫我們分析下為什麼記憶體的使用率顯示使用了3178M. -bash-3.2$ ps -eo 'pid,rss' --sort=-rss (Not all processes could be identified, no

------------解決 svchost 佔用過高及磁碟最長活時間過高問題------win---------

原因分析： 先說說什麼是svchost.exe：簡單的說沒有這個RPC服務，機器幾乎就上不了網了。很多應用服務都是依賴於這個RPC介面的，如果發現這個程序佔了太多的CPU資源，直接把系統的RPC服務禁用了會是一場災難：因為連恢復這個介面的系統服務設定介面都無法使用了。恢復的方法需要使用登錄檔編輯器，找到 H

解決Mac自帶Mail CPU佔用太高

問題描述：近期發現Mac (MacOS 10.12.6) 上自帶的郵件管理Mail CPU佔用率經常居高不下，在終端用htop看其CPU佔用率高達100%以上，導致整個Mac微微發熱。而且，即使重啟Mail，一段時間後CPU佔用仍會飆升。 解決方法：(參照https://www.zhihu.co

一次JVM_OLD區佔用過高、頻繁Full GC的解決過程

最近，公司網站頻繁報警，JVM_OLD佔用過高，線上訪問超時嚴重，針對這個問題著實頭疼了一把，不過最終還是解決了，下面說下解決的過程。 1，首先 登到線上機器上去，top命令，檢視當前機器的負載，檢視當前哪個程序在消耗資源。 Shell 1

Spring cloud開發記憶體佔用過高解決方法

https://blog.csdn.net/wanhuiguizong/article/details/79289986   版權宣告：本文為博主原創文章，轉載請宣告文章來源和原文連結。 https://blog.csdn.net/wanhuiguizong/article/details/79

解決Linux buffer/cache記憶體佔用過高的辦法

-------原文地址 https://www.cnblogs.com/rocky-AGE-24/p/7629500.html --------本文只是搬運 在Linux系統中，我們經常用free命令來檢視系統記憶體的使用狀態。在一個RHEL6的系統上，fr

解決win10系統CPU佔用過高【親測非常有效】

win10 系統的到來，讓使用者體驗到了更好的視覺效果和完善的服務，但是魚和熊掌不可兼得，這些良好的優點同時也帶給電腦更多的負荷，CPU各種100%燙的要命，風扇呼呼的吹。所以我們不得不對win10進行一丟丟的改造。 以下內容是我在網上尋找的資料，我稍作了整理

Linux中buff/cache記憶體佔用過高解決辦法

如何回收cache？ Linux核心會在記憶體將要耗盡的時候，觸發記憶體回收的工作，以便釋放出記憶體給急需記憶體的程序使用。一般情況下，這個操作中主要的記憶體釋放都來自於對buffer／cache的釋放。尤其是被使用更多的cache空間。既然它主要用來做快

Linux中Cache記憶體佔用過高解決辦法

在Linux系統中，我們經常用free命令來檢視系統記憶體的使用狀態。在一個RHEL6的系統上，free命令的顯示內容大概是這樣一個狀態： 這裡的預設顯示單位是kb，我的伺服器是128G記憶體，所以數字顯得比較大。這個命令幾乎是每一個使用過Linux的人必會的命令，但越是這樣的命令，似乎真正明白的人越少（

Java如何定位佔用CPU比較高的問題

編寫Java專案時，經常會遇到兩種問題。 第一種：Java程序佔用CPU比較高 第二種：Java程序堆記憶體溢位 今天主要跟大家聊聊第一種問題如何排查。 一、確定消耗CPU的Java程序 從上圖可以看到Java程序 27459 消耗的CPU比較高。

解決線上問題-定位CPU佔用過高

如果線上伺服器CPU佔用率過高，如何定位問題呢？ 1.使用 top 命令檢視佔用CPU最高的pid 2.使用 top -H -p pid或 top -Hp pid命令檢視佔用cpu最大的執行緒id即 tid 3.使用命令 printf ‘%x/n’ tid

效能優化-Android之ANR問題分析解決 traces.txt檔案分析 CPU佔用過高

（由於公司專案特殊情況，需要使用一些小廠的三防功能手機，不能使用我們平時用的這些民用手機） 前期測試的時候是用民用手機測試的，有六七種機型（小米，華為，中興，oppo）,使用過程中均沒有出現ANR的情況，但是在公司採購的一款工程機上面用了一段時間後肯定就會出現ANR，出現了

使用"iotop -tbo -d 1"獲得佔用IO比較高的程序資訊

在一個xshell中執行dd命令：   time dd if=/dev/zero of=test bs=100M count=256 conv=fdatasync 在另一個xshell中執行"iotop -tbo -d 1"以獲得佔用IO比較高的程序資訊   [[e

window 查詢 java 程序中佔用cpu比較高的執行緒

概述 公司內部的一個產品 （java 開發的） 執行在 window 虛擬機器上，執行一段時間後CPU飆升，然後想檢視是哪個執行緒佔用。 折騰了一下午，終於定位到該執行緒。 下面我們通過兩種方式定位到佔用cpu比較高的執行緒。 * 1. 使用Proces

apache httpd佔用記憶體高解決辦法

我用2048M的aliyun 伺服器，訪問量不大，但記憶體佔用很大，使用free -h命令檢視： 使用ps -aux | sort -k4nr | head -10命令檢視記憶體佔用前10的程序，發現是httpd伺服器開啟的執行緒太多，同時每個執行緒的記憶體佔用較大：

記一次生產環境CPU佔用飆高問題解決

1 問題來源與背景 問題背景，專案對外提供查詢航班艙位介面，對航信黑屏報文做正則解析返回。由於起初對正則不熟悉，對黑屏報文格式規律不清楚，導致寫了大量的長正則表示式，生產環境併發量上來（200/s），直

win2003+iis6.0環境下w3wp.exe佔用過高的解決方案

前段時間，朋友的伺服器出現w3wp.exe程序一直處在80%至90%左右，嚴重影響其它使用者網站的訪問效率。順便說一下，朋友的伺服器為Win2003系統，大約有約100左右個網站。出現這樣的問題，只有找到對應的網站，並檢查是否被掛馬。在此記錄一下解決這次事件的過程。 因為朋

解決windows7 下svchost程序佔用cpu高問題

安裝windows7之後，有時候會出現svchost程序佔用cpu和記憶體很高的問題。一般是在啟動其他程序之後，svchost也會跟著佔用很資源，導致其他程序卡住。最直接的解決方法是在工作管理員中，右鍵svchost程

MySQL 5.6記憶體佔用過高解決方案【總結】

最近把MySQL升級到了5.6版本，無意中在工作管理員發現MySQL記憶體佔用達到400+M，這是怎麼回事呢？以前的版本可沒有遇到過這種情況啊。開始的時候還以為是快取了某個資料量較大的表的資料。於是重啟MySQL服務，但結果出乎意料，MySQL服務一起啟動，記憶體就又飆

我的計算機問題解決之：NT Kernel & System 程序CPU佔用過高（開機便保持在50%）

按CPU排序之後你就會發現是什麼後臺服務佔用了那麼高的CPU，我到後來才發現竟然是91助手（連線android和PC的一個軟體），當時雖然解除安裝了91助手，但是它竟然在C:windows\System32\drivers下面留下了91Ass**.sys的一個檔案，每次進系統都會載入，直接導致了我的CPU佔用