這篇文章將為大家詳細(xì)講解有關(guān)Linux系統(tǒng)中內(nèi)存不足如何排查,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),獨山子企業(yè)網(wǎng)站建設(shè),獨山子品牌網(wǎng)站建設(shè),網(wǎng)站定制,獨山子網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,獨山子網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿,時刻以成就客戶成長自我,堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
問題描述
Linux服務(wù)器內(nèi)存使用量超過閾值,觸發(fā)報警。
問題排查
首先,通過free命令觀察系統(tǒng)的內(nèi)存使用情況,顯示如下:
total used free shared buffers cached Mem: 24675796 24587144 88652 0 357012 1612488 -/+ buffers/cache: 22617644 2058152 Swap: 2096472 108224 1988248
其中,可以看出內(nèi)存總量為24675796KB,已使用22617644KB,只剩余2058152KB。
然后,接著通過top命令,shift + M按內(nèi)存排序后,觀察系統(tǒng)中使用內(nèi)存***的進(jìn)程情況,發(fā)現(xiàn)只占用了18GB內(nèi)存,其他進(jìn)程均很小,可忽略。
因此,還有將近4GB內(nèi)存(22617644KB-18GB,約4GB)用到什么地方了呢?
進(jìn)一步,通過cat /proc/meminfo發(fā)現(xiàn),其中有將近4GB(3688732 KB)的Slab內(nèi)存:
...... Mapped: 25212 kB Slab: 3688732 kB PageTables: 43524 kB ......
Slab是用于存放內(nèi)核數(shù)據(jù)結(jié)構(gòu)緩存,再通過slabtop命令查看這部分內(nèi)存的使用情況:
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
發(fā)現(xiàn)其中大部分(大約3.5GB)都是用于了dentry_cache。
問題解決
1. 修改/proc/sys/vm/drop_caches,釋放Slab占用的cache內(nèi)存空間(參考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權(quán)限,如果不是root,但有sudo權(quán)限,可以通過sysctl命令進(jìn)行設(shè)置:
$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,調(diào)整清理inode/dentry caches的優(yōu)先級(默認(rèn)為100),LinuxInsight中有相關(guān)的解釋:
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.
具體的設(shè)置方法,可以參考方法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
以下記錄的是進(jìn)一步排查的進(jìn)展情況。
更深層次的原因
上文排查到Linux系統(tǒng)中有大量的dentry_cache占用內(nèi)存,為什么會有如此多的dentry_cache呢?
1. 首先,弄清楚dentry_cache的概念及作用:目錄項高速緩存,是Linux為了提高目錄項對象的處理效率而設(shè)計的;它記錄了目錄項到inode的映射關(guān)系。因此,當(dāng)應(yīng)用程序發(fā)起stat系統(tǒng)調(diào)用時,就會創(chuàng)建對應(yīng)的dentry_cache項(更進(jìn)一步,如果每次stat的文件都是不存在的文件,那么總是會有大量新的dentry_cache項被創(chuàng)建)。
2. 當(dāng)前服務(wù)器是storm集群的節(jié)點,首先想到了storm相關(guān)的工作進(jìn)程,strace一下storm的worker進(jìn)程發(fā)現(xiàn)其中有非常頻繁的stat系統(tǒng)調(diào)用發(fā)生,而且stat的文件總是新的文件名:
sudo strace -fp <pid> -e trace=stat
3. 進(jìn)一步觀察到storm的worker進(jìn)程會在本地目錄下頻繁的創(chuàng)建、打開、關(guān)閉、刪除心跳文件,每秒鐘一個新的文件名:
sudo strace -fp <pid> -e trace=open,stat,close,unlink
以上就是系統(tǒng)中為何有如此多的dentry_cache的原因所在。
一個奇怪的現(xiàn)象
通過觀察/proc/meminfo發(fā)現(xiàn),slab內(nèi)存分為兩部分:
SReclaimable // 可回收的slab SUnreclaim // 不可回收的slab
當(dāng)時服務(wù)器的現(xiàn)狀是:slab部分占用的內(nèi)存,大部分顯示的都是SReclaimable,也就是說可以被回收的。
但是通過slabtop觀察到slab內(nèi)存中最主要的部分(dentry_cache)的OBJS幾乎都是ACTIVE的,顯示100%處于被使用狀態(tài)。
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狀態(tài)呢?求Linux內(nèi)核達(dá)人看到后熱心解釋下:(
會不會由于是ACTIVE狀態(tài),導(dǎo)致dcache沒有被自動回收釋放掉呢?
讓系統(tǒng)自動回收dcache
上一小節(jié),我們已經(jīng)提到,服務(wù)器上大部分的slab內(nèi)存是SReclaimable可回收狀態(tài)的,那么,我們能不能交給操作系統(tǒng)讓他在某個時機自動觸發(fā)回收操作呢?答案是肯定的。
查了一些關(guān)于Linux dcache的相關(guān)資料,發(fā)現(xiàn)操作系統(tǒng)會在到了內(nèi)存臨界閾值后,觸發(fā)kswapd內(nèi)核進(jìn)程工作才進(jìn)行釋放,這個閾值的計算方法如下:
1. 首先,grep low /proc/zoneinfo,得到如下結(jié)果:
low 1 low 380 low 12067
2. 將以上3列加起來,乘以4KB,就是這個閾值,通過這個方法計算后發(fā)現(xiàn)當(dāng)前服務(wù)器的回收閾值只有48MB,因此很難看到這一現(xiàn)象,實際中可能等不到回收,操作系統(tǒng)就會hang住沒響應(yīng)了。
3. 可以通過以下方法調(diào)大這個閾值:將vm.extra_free_kbytes設(shè)置為vm.min_free_kbytes和一樣大,則/proc/zoneinfo中對應(yīng)的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. 舉個例子,當(dāng)low閾值被設(shè)置為1GB的時候,當(dāng)系統(tǒng)free的內(nèi)存小于1GB時,觀察到kswapd進(jìn)程開始工作(進(jìn)程狀態(tài)從Sleeping變?yōu)镽unning),同時dcache開始被系統(tǒng)回收,直到系統(tǒng)free的內(nèi)存介于low閾值和high閾值之間,停止回收。
關(guān)于Linux系統(tǒng)中內(nèi)存不足如何排查就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學(xué)到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
文章標(biāo)題:Linux系統(tǒng)中內(nèi)存不足如何排查
URL地址:http://jinyejixie.com/article32/jjpgsc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供商城網(wǎng)站、關(guān)鍵詞優(yōu)化、外貿(mào)建站、外貿(mào)網(wǎng)站建設(shè)、域名注冊、網(wǎng)站改版
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)