案例一

問(wèn)題

最近一臺(tái) CentOS 服務(wù)器，發(fā)現(xiàn)內(nèi)存無(wú)端損失了許多，free 和 ps 統(tǒng)計(jì)的結(jié)果相差十幾個(gè)G，非常奇怪，后來(lái)Google了許久才搞明白。

分析

1、linux系統(tǒng)內(nèi)存消耗主要有三個(gè)地方：

• 進(jìn)程
• slab
• pagecacge

用 free 命令查看到的是系統(tǒng)整體的內(nèi)容使用情況，而使用 ps 和 top 看到的內(nèi)存使用情況都是以進(jìn)程維度來(lái)看的，因此看不到 slabcache 和pagecache 的內(nèi)存占用信息。

2、判斷應(yīng)用程序是否有內(nèi)存泄露問(wèn)題，只根據(jù)進(jìn)程的內(nèi)存使用或機(jī)器的內(nèi)存變化來(lái)判定都不太準(zhǔn)確，如果單憑進(jìn)程的內(nèi)存變化可能會(huì)疏忽一些小對(duì)象的內(nèi)存泄露問(wèn)題。

同時(shí)對(duì)于機(jī)器的內(nèi)存的使用也要做是否合理的判斷。對(duì)于不同語(yǔ)言的應(yīng)用都有相應(yīng)的神器可以輔助定位內(nèi)存泄露問(wèn)題，同時(shí)結(jié)合linux內(nèi)存的監(jiān)控工具進(jìn)行分析， 除了 top，free還有 pmap，/proc/meminfo 和 /slabinfo，slaptop等。

3、通過(guò)這個(gè)問(wèn)題，有一點(diǎn)比較重要的是，在使用監(jiān)控工具進(jìn)行監(jiān)控和分析時(shí)，對(duì)其值的具體含義還是要了解的很清楚，否則會(huì)造成誤判，使問(wèn)題變得更加復(fù)雜。

4、此外 page cache，dentries和inodes cache，系統(tǒng)是會(huì)自動(dòng)回收的。

可以通過(guò)以下幾種方式加速其回收，不過(guò)實(shí)際并不需要這么做。

手工清除內(nèi)存 緩存

• echo 1 > /proc/sys/vm/drop_caches 清除page cache
• echo 2 > /proc/sys/vm/drop_caches 清除denries和inodes
• echo 3 > /proc/sys/vm/drop_caches 清除page cache ，dentries及inodes
• 調(diào)整 vm.vfs_cache_pressure 值大小，默認(rèn)是100。值越大，dentries和inodes cache的回收速度會(huì)越快
• 調(diào)整 vm.min_free_kbytes 值大小，該值為系統(tǒng)開(kāi)始內(nèi)存回收的閥值，越大表示系統(tǒng)會(huì)越早開(kāi)始回收(一般情況下此值不建議調(diào)整)。

問(wèn)題描述和初步調(diào)查

$?free?-g

這臺(tái)服務(wù)器有 16G內(nèi)存，但是結(jié)果顯示除了2G左右的文件Buffer緩存外，其余十幾G都被確確實(shí)實(shí)的用光了。(free按1024進(jìn)制計(jì)算，總內(nèi)存可能比實(shí)際偏小)

這里大概介紹下 free 結(jié)果的含義:

然后 top 看了下，沒(méi)有特別吃?xún)?nèi)存的程序。用 ps 大概統(tǒng)計(jì)下所有程序占用的總內(nèi)存:

$?echo?`ps?aux?|awk?'{mem?+=?$6}?END?{print?mem/1024/1024}'`?GB

0.595089

結(jié)果顯示所有進(jìn)程占用的內(nèi)存還不到 1G，實(shí)際上，因?yàn)閒ree, ps的統(tǒng)計(jì)方式的差別和 Copy-on-write 和 Shared libraries等內(nèi)存優(yōu)化機(jī)制的存在，這兩者的統(tǒng)計(jì)結(jié)果通常是不一樣的。但是一般情況下絕對(duì)不會(huì)相差十幾個(gè)G，肯定是有什么隱藏的問(wèn)題，Google了許久后發(fā)現(xiàn)，free沒(méi)有專(zhuān)門(mén)統(tǒng)計(jì)另一項(xiàng)緩存: Slab。

Slab 簡(jiǎn)介和進(jìn)一步調(diào)查

Slab Allocation 是Kernel 2.2之后引入的一個(gè)內(nèi)存管理機(jī)制，專(zhuān)門(mén)用于緩存內(nèi)核的數(shù)據(jù)對(duì)象，可以理解為一個(gè)內(nèi)核專(zhuān)用的對(duì)象池，可以提高系統(tǒng)性能并減少內(nèi)存碎片。(Kernel 2.6.23之后，SLUB成為了默認(rèn)的allocator)

查看Slab緩存

$?cat?/proc/meminfo

#?其中，Slab相關(guān)的數(shù)據(jù)為
Slab:?154212?kB
SReclaimable:?87980?kB
SUnreclaim:?66232?kB

SReclaimable(Linux 2.6.19+) 都是 clean 的緩存，隨時(shí)可以釋放。回到之前的內(nèi)存問(wèn)題，

查看服務(wù)器上Slab占用的內(nèi)存：

方法1：

$?cat?/proc/meminfo|grep?Slab

Slab:?12777668?kB

方法2：

echo?`cat?/proc/meminfo|grep?Slab|awk?'{mem?+=?$2}?END?{print?mem/1024/1024}'`?GB

12G

12G的Slab緩存，有意思的是free把Slab緩存統(tǒng)計(jì)到了 usedmemory 中，這就是之前那個(gè)問(wèn)題的癥結(jié)所在了。另外，還可以查看 /proc/slabinfo (或使用 slabtop 命令)來(lái)查看Slab緩存的具體使用情況。

結(jié)果發(fā)現(xiàn)，ext3_inode_cache 和 dentry_cache 占用了絕大部分內(nèi)存。考慮到這臺(tái)服務(wù)器會(huì)頻繁地用 rsync 同步大量的文件，這個(gè)結(jié)果也并不意外。

解決問(wèn)題

先說(shuō)明一下，如果問(wèn)題僅僅是Slab占用了太多的內(nèi)存(SReclaimable)，那么通常不需要太操心，因?yàn)檫@根本不是個(gè)問(wèn)題(如果是SUnreclaim太多且不斷增長(zhǎng)，那么很有可能是內(nèi)核有bug)。但是，如果是因?yàn)镾lab占用內(nèi)存太多而引起了其他的問(wèn)題，建議繼續(xù)往下閱讀。

清除Slab可回收緩存

通過(guò) /proc/sys/vm/drop_caches 這個(gè)配置項(xiàng)，可以手動(dòng)清除指定的可回收緩存(SReclaimable)

echo 2 > /proc/sys/vm/drop_caches 或者 sysctl vm.drop_caches=2

上面的命令會(huì)主動(dòng)釋放 Slab 中 clean的緩存(包括inode和dentry的緩存)，然后再 free -g 一下，空閑的內(nèi)存陡增了十幾個(gè)G

注意的是，手動(dòng)清除緩存可能會(huì)在一段時(shí)間內(nèi)降低系統(tǒng)性能。原則上不推薦這么做，因?yàn)槿绻行枰?#xff0c;系統(tǒng)會(huì)自動(dòng)釋放出內(nèi)存供其他程序使用。另外，手動(dòng)清除Slab緩存是一個(gè)治標(biāo)不治本的辦法。因?yàn)閱?wèn)題不在Slab，實(shí)際操作的時(shí)候發(fā)現(xiàn)，清除緩存一段時(shí)間后，Slab緩存很快又會(huì)反彈回去。

如果需要治本，要么搞定問(wèn)題進(jìn)程，要么修改系統(tǒng)配置，要么增加物理內(nèi)存。

調(diào)整系統(tǒng) vm 配置

風(fēng)險(xiǎn)預(yù)警: 調(diào)整以下系統(tǒng)配置可能會(huì)對(duì)系統(tǒng)性能造成負(fù)面影響，請(qǐng)仔細(xì)測(cè)試并謹(jǐn)慎操作。

/etc/sysctl.conf 里有以下幾個(gè)對(duì)內(nèi)存管理影響比較大的內(nèi)核參數(shù)配置：

vm.vfs_cache_pressure

系統(tǒng)在進(jìn)行內(nèi)存回收時(shí)，會(huì)先回收page cache, inode cache, dentry cache和swap cache。vfs_cache_pressure 越大，每次回收時(shí)，inode cache和dentry cache所占比例越大。

vfs_cache_pressure

默認(rèn)是100，該值越大inode cache和dentry cache的回收速度會(huì)越快，越小則回收越慢，為0的時(shí)候完全不回收，內(nèi)存溢出(OOM!)。

vm.min_free_kbytes

系統(tǒng)的"保留內(nèi)存"的大小，"保留內(nèi)存"用于低內(nèi)存狀態(tài)下的"atomic memory allocation requests"(eg. kmalloc + GFP_ATOMIC)，該參數(shù)也被用于計(jì)算開(kāi)始內(nèi)存回收的閥值，默認(rèn)在開(kāi)機(jī)的時(shí)候根據(jù)當(dāng)前的內(nèi)存計(jì)算所得，越大則表示系統(tǒng)會(huì)越早開(kāi)始內(nèi)存回收。vm.min_free_kbytes 過(guò)大可能會(huì)導(dǎo)致 OOM，太小可能會(huì)導(dǎo)致系統(tǒng)出現(xiàn)死鎖等問(wèn)題。查看默認(rèn)設(shè)置：cat /proc/sys/vm/min_free_kbytes

vm.swappiness

該配置用于控制系統(tǒng)將內(nèi)存 swap out 到交換空間的積極性，取值范圍是[0, 100]。vm.swappiness 越大，系統(tǒng)的交換積極性越高，默認(rèn)是60， 如果為0則不會(huì)進(jìn)行交換。

$?vim?/etc/sysctl.conf

vm.swappiness?=?1

查看默認(rèn)設(shè)置：cat /proc/sys/vm/swappiness

drop_caches

默認(rèn)值為0，將此值設(shè)置為1，2或3，使內(nèi)核刪除頁(yè)面緩存和slab緩存的各種組合。

• 1 系統(tǒng)使所有的頁(yè)面緩沖存儲(chǔ)器失效并釋放。
• 2 系統(tǒng)釋放所有未使用的slab緩存內(nèi)存。
• 3 系統(tǒng)釋放所有的頁(yè)面緩存和slab緩存內(nèi)存。

查看默認(rèn)設(shè)置：cat /proc/sys/vm/drop_caches

注：以上參數(shù)設(shè)置是非破壞性的操作，由于臟數(shù)據(jù)不能被釋放，建議設(shè)置以上參數(shù)的值之前運(yùn)行sync把內(nèi)存數(shù)據(jù)寫(xiě)入硬盤(pán)。在生產(chǎn)環(huán)境中不建議使用drop_caches釋放內(nèi)存。

案例二 (物理內(nèi)存的外碎片回收)

問(wèn)題

執(zhí)行 docker ps 命令掛住

問(wèn)題分析

查找 /var/log/messages，發(fā)現(xiàn)有錯(cuò)誤信息：XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250)

在linux中使用buddy算法解決物理內(nèi)存的碎片問(wèn)題，其把所有空閑的內(nèi)存，以2的冪次方的形式，分成11個(gè)塊鏈表，分別對(duì)應(yīng)為1、2、4、8、16、32、64、128、256、512、1024個(gè)頁(yè)塊。

Linux支持NUMA技術(shù)，對(duì)于NUMA設(shè)備，NUMA系統(tǒng)的結(jié)點(diǎn)通常是由一組CPU和本地內(nèi)存組成，每一個(gè)節(jié)點(diǎn)都有相應(yīng)的本地內(nèi)存，因此buddyinfo 中的Node0表示節(jié)點(diǎn)ID；而每一個(gè)節(jié)點(diǎn)下的內(nèi)存設(shè)備，又可以劃分為多個(gè)內(nèi)存區(qū)域(zone)，因此下面的顯示中，對(duì)于Node0的內(nèi)存，又劃分類(lèi)DMA、Normal、HighMem區(qū)域。而后面則是表示空閑的區(qū)域。

此處以 Normal 區(qū)域進(jìn)行分析，第二列值為100，表示當(dāng)前系統(tǒng)中normal區(qū)域，可用的連續(xù)兩頁(yè)的內(nèi)存大小為1002PAGE_SIZE；第三列值為52，

表示當(dāng)前系統(tǒng)中normal區(qū)域，可用的連續(xù)四頁(yè)的內(nèi)存大小為 52*2^2* PAGE_SIZE

$?cat?/proc/buddyinfo

Node?0,?zone?DMA?23?15?4?5?2?3?3?2?3?1?0
Node?0,?zone?Normal?149?100?52?33?23?5?32?8?12?2?59
Node?0,?zone?HighMem?11?21?23?49?29?15?8?16?12?2?142

可以看到從第5列開(kāi)始，只剩下 44*16*PAGE_SIZE 的頁(yè)塊，后面剩下的分別是1 * 32 *PAGE_SIZE, 1 * 64 *PAGE_SIZE, 2 *128 * PAGE_SIZE，剩下256,512的頁(yè)塊都沒(méi)有了因此推測(cè)，導(dǎo)致這個(gè)問(wèn)題出現(xiàn)的時(shí)候，該機(jī)器的內(nèi)存碎片很多，當(dāng)某個(gè)應(yīng)用執(zhí)行時(shí)，在xfs的申請(qǐng)內(nèi)存中有這種連續(xù)的大塊的內(nèi)存申請(qǐng)的操作的請(qǐng)求。

比如：6000: map = kmem_alloc(subnex * sizeof(*map), KM_MAYFAIL | KM_NOFS); 就會(huì)導(dǎo)致內(nèi)存一直分配不到。

例如：執(zhí)行 docker ps，docker exec這些命令時(shí)，會(huì)一直阻塞在 kmem_alloc 的循環(huán)中，反復(fù)申請(qǐng)內(nèi)存，由于內(nèi)存碎片沒(méi)有被組合，因此就一直申請(qǐng)不到，執(zhí)行這些命令也會(huì)卡住，這也就驗(yàn)證了執(zhí)行某些命令如ls、ssh都不會(huì)失敗(因?yàn)樾枰獌?nèi)存的 PAGE 不是那么大)。

臨時(shí)解決方法：

echo 1 > /proc/sys/vm/drop_caches

上述命令操作會(huì)把碎片化的 PAGE 重新分配，之后在申請(qǐng)大塊的PAGE內(nèi)存就可以申請(qǐng)到，不阻塞了。

永久解決方法：

優(yōu)化內(nèi)核參數(shù)：

#?保留1G空閑內(nèi)存，達(dá)到該值，觸發(fā)內(nèi)存回收
$?cat?>>?/etc/sysctl.conf?<vm.min_free_kbytes?=?1048576
EOF

#立即生效
$?sysctl?-p

什么是 overcommit or oom 問(wèn)題

Linux對(duì)大部分申請(qǐng)內(nèi)存的請(qǐng)求都回復(fù)"yes"，以便能跑更多更大的程序，因?yàn)樯暾?qǐng)內(nèi)存后，并不會(huì)馬上使用內(nèi)存，這種技術(shù)叫做 Overcommit。

當(dāng)linux發(fā)現(xiàn)內(nèi)存不足時(shí)，會(huì)發(fā)生OOM killer(OOM=out-of-memory)，它會(huì)選擇殺死一些進(jìn)程(用戶(hù)態(tài)進(jìn)程，不是內(nèi)核線程)，以便釋放內(nèi)存。

當(dāng) oom-killer 發(fā)生時(shí)，linux會(huì)選擇殺死哪些進(jìn)程？選擇進(jìn)程的函數(shù)是oom_badness函數(shù)(在mm/oom_kill.c中)，該函數(shù)會(huì)計(jì)算每個(gè)進(jìn)程的點(diǎn)數(shù)(0~1000)，點(diǎn)數(shù)越高，這個(gè)進(jìn)程越有可能被殺死。

每個(gè)進(jìn)程的點(diǎn)數(shù)跟 oom_score_adj 有關(guān)，而且 oom_score_adj 可以被設(shè)置(-1000最低，1000最高)。

內(nèi)核參數(shù) overcommit_memory, 它是內(nèi)存分配策略

可選值：0、1、2。

• 0：表示內(nèi)核將檢查是否有足夠的可用內(nèi)存供應(yīng)用進(jìn)程使用；如果有足夠的可用內(nèi)存，內(nèi)存申請(qǐng)?jiān)试S；否則，內(nèi)存申請(qǐng)失敗，并把錯(cuò)誤返回給應(yīng)用進(jìn)程。
• 1：表示內(nèi)核允許分配所有的物理內(nèi)存，而不管當(dāng)前的內(nèi)存狀態(tài)如何。
• 2：表示內(nèi)核允許分配超過(guò)所有物理內(nèi)存和交換空間總和的內(nèi)存。

參考鏈接

• https://www.mawenbao.com/research/linux-ate-my-memory.html
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-tunables
• http://blog.51yip.com/nosql/1776.html
• http://linuxperf.com/?p=102

• 案例一原文出處：http://blog.atime.me/research/linux-ate-my-memory.html
• 案例二原文出處：https://www.cnblogs.com/beilong/p/8192676.html

熱門(mén)文章推薦

• 如何實(shí)現(xiàn)rsync多并發(fā)同步？
• Kubernetes YAML 生成器
• Kubernetes 臨時(shí)存儲(chǔ)需要限制嗎？
• Harbor v2.0 鏡像回收那些事
• IT運(yùn)維面試問(wèn)題總結(jié)-數(shù)據(jù)庫(kù)、監(jiān)控、網(wǎng)絡(luò)管理
• 前端本地緩存概況之瀏覽器緩存策略

最后

• 歡迎您加我微信【ypxiaozhan01】，拉您進(jìn)技術(shù)群，一起交流學(xué)習(xí)...
• 歡迎您關(guān)注【YP小站】，學(xué)習(xí)互聯(lián)網(wǎng)最流行的技術(shù)，做個(gè)專(zhuān)業(yè)的技術(shù)人...

---

【文章讓您有收獲，??贊或者在看支持我吧】

總結(jié)

以上是生活随笔為你收集整理的linux 内存占用_分享Linux内存占用几个案例的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。