前言

問題真是一個(gè)接一個(gè)，做開發(fā)就是解決一個(gè)又一個(gè)問題嗎？

像死機(jī)、內(nèi)存泄漏這些問題很多時(shí)候是沒有框架、設(shè)計(jì)或有了框架和設(shè)計(jì)但是團(tuán)隊(duì)沒有統(tǒng)一遵循標(biāo)準(zhǔn)按著自己性子來導(dǎo)致的，統(tǒng)一的框架和設(shè)計(jì)也許會(huì)損失一定的靈活性，但是他會(huì)讓你在編碼的時(shí)候遵從一定的范式，且通過規(guī)范格式可以做到良好的自檢查，例如將一個(gè)代碼的實(shí)現(xiàn)分別放在A、B、C三個(gè)地方，A、B、C、分別干啥，接口是啥，A、B、C的范例等都在框架和設(shè)計(jì)中定義好了，每個(gè)編碼人員按這個(gè)進(jìn)行具體的開發(fā)編碼工作，可以并行有序，甚至A、B、C進(jìn)行不同的分工開發(fā)互不影響，比如A是解析配置的，B是做初始化的，C是業(yè)務(wù)處理主體。

對(duì)于應(yīng)用開發(fā)，從框架、設(shè)計(jì)及編碼質(zhì)量這些工程角度避免低級(jí)錯(cuò)誤，把開發(fā)的大部分時(shí)間用在算法、業(yè)務(wù)邏輯實(shí)現(xiàn)與優(yōu)化等給客戶帶來良好體驗(yàn)與價(jià)值的地方，是一個(gè)軟件團(tuán)隊(duì)需要努力的方向。

好吧，回到內(nèi)存泄漏，這里指的是那些默默消耗了系統(tǒng)有限內(nèi)存的操作，不僅僅指代碼中申請(qǐng)而沒有釋放的內(nèi)存，簡單總結(jié)了下面幾種情況進(jìn)行檢查和定位：

1，應(yīng)用進(jìn)程造成的內(nèi)存泄漏

2，內(nèi)核空間/或因應(yīng)用進(jìn)程的操作導(dǎo)致內(nèi)核空間的內(nèi)存泄漏

3，用戶空間產(chǎn)生的臨時(shí)文件（如日志等）造成的內(nèi)存泄漏

應(yīng)用進(jìn)程造成的內(nèi)存泄漏

1）采用ps或top命令進(jìn)行觀察

首先，我們習(xí)慣性的會(huì)看下那個(gè)進(jìn)程在泄漏內(nèi)存，我這里使用一個(gè)test_core_dump的測試進(jìn)程，該進(jìn)程每2秒鐘會(huì)分配一個(gè)10000字節(jié)的空間，并作簡單賦值（注意：如果僅malloc而不使用，編譯器會(huì)優(yōu)化，實(shí)際測試時(shí)將看不到內(nèi)存泄漏的測試效果）：

root@OpenWrt:/# ps

? PID USER? ? ? VSZ STAT COMMAND? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

14444 root? ? 15984 S? ? test_core_dump

省略不必要的信息，這里，我們主要看VSZ這個(gè)字段，這個(gè)字段表示該進(jìn)程的虛擬內(nèi)存大小，單位為KBytes，也就是此時(shí)我的測試進(jìn)程已經(jīng)占用近16M的虛擬內(nèi)存空間，那是否意味著物理內(nèi)存就已經(jīng)被吃掉16M呢，這個(gè)我等下再講。

或者我們通過top命令，也可以觀察進(jìn)程的VSZ字段，這里我當(dāng)時(shí)沒抓速據(jù)，所以就不放速據(jù)了，不管是top還是ps，重點(diǎn)是看VSZ字段的變化，當(dāng)你發(fā)現(xiàn)VSZ字段一直在變化，則很明顯這個(gè)進(jìn)程有內(nèi)存泄漏的問題，比如我現(xiàn)使用ps再看：

root@OpenWrt:/# ps?

? PID USER? ? ? VSZ STAT COMMAND? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

14444 root 73884 S test_core_dump

我的測試進(jìn)程已經(jīng)占用近73M的虛擬地址空間。

2）查看/proc/meminfo

一般我們在發(fā)現(xiàn)有進(jìn)程內(nèi)存泄漏時(shí)，還會(huì)去查看一個(gè)文件，就是/proc/meminfo，看系統(tǒng)還有多少內(nèi)存，比如我在上一步第一次ps時(shí)就去看了這個(gè)文件：

root@OpenWrt:/# cat /proc/meminfo

MemTotal:? ? ? ? 125064 kB

MemFree:? ? ? ? ? 28536 kB

Buffers:? ? ? ? ? ? 8128 kB

Cached:? ? ? ? ? ? 27844 kB

SwapCached:? ? ? ? ? ? 0 kB

Active:? ? ? ? ? ? 23004 kB

Inactive:? ? ? ? ? 19996 kB

Active(anon):? ? ? 10888 kB

Inactive(anon):? ? ? 696 kB

Active(file):? ? ? 12116 kB

Inactive(file):? ? 19300 kB

Unevictable:? ? ? ? ? 0 kB

Mlocked:? ? ? ? ? ? ? 0 kB

SwapTotal:? ? ? ? ? ? 0 kB

SwapFree:? ? ? ? ? ? ? 0 kB

Dirty:? ? ? ? ? ? ? ? 0 kB

Writeback:? ? ? ? ? ? 0 kB

AnonPages:? ? ? ? ? 7092 kB

Mapped:? ? ? ? ? ? 4648 kB

Shmem:? ? ? ? ? ? ? 4556 kB

Slab:? ? ? ? ? ? ? 36684 kB

SReclaimable:? ? ? 5792 kB

SUnreclaim:? ? ? ? 30892 kB

KernelStack:? ? ? ? 704 kB

PageTables:? ? ? ? ? 588 kB

NFS_Unstable:? ? ? ? ? 0 kB

Bounce:? ? ? ? ? ? ? ? 0 kB

WritebackTmp:? ? ? ? ? 0 kB

CommitLimit:? ? ? 62532 kB

Committed_AS:? ? ? 37800 kB

VmallocTotal:? ? 1048372 kB

VmallocUsed:? ? ? 12308 kB

VmallocChunk:? ? 1020828 kB

看了系統(tǒng)還有MemFree:? ? ? ? ? 28536 kB，約28M內(nèi)存（我在系統(tǒng)啟動(dòng)完成時(shí)，就看了一次，大概是剩39M內(nèi)存），那是不是這11M內(nèi)存都是我的測試程序吃了呢？從第一次ps看到的虛擬內(nèi)存16M來看，好像數(shù)據(jù)對(duì)不上？

不妨在第二次ps的時(shí)候，看下/etc/meminfo的信息：

root@OpenWrt:/# cat /proc/meminfo

MemTotal:? ? ? ? 125064 kB

MemFree:? ? ? ? ? 21936 kB

Buffers:? ? ? ? ? ? 8128 kB

Cached:? ? ? ? ? ? 27940 kB

SwapCached:? ? ? ? ? ? 0 kB

Active:? ? ? ? ? ? 28940 kB

Inactive:? ? ? ? ? 19976 kB

Active(anon):? ? ? 16808 kB

Inactive(anon):? ? ? 692 kB

Active(file):? ? ? 12132 kB

Inactive(file):? ? 19284 kB

Unevictable:? ? ? ? ? 0 kB

Mlocked:? ? ? ? ? ? ? 0 kB

SwapTotal:? ? ? ? ? ? 0 kB

SwapFree:? ? ? ? ? ? ? 0 kB

Dirty:? ? ? ? ? ? ? ? 0 kB

Writeback:? ? ? ? ? ? 0 kB

AnonPages:? ? ? ? 12900 kB

Mapped:? ? ? ? ? ? 4716 kB

Shmem:? ? ? ? ? ? ? 4652 kB

Slab:? ? ? ? ? ? ? 37360 kB

SReclaimable:? ? ? 6392 kB

SUnreclaim:? ? ? ? 30968 kB

KernelStack:? ? ? ? 648 kB

PageTables:? ? ? ? ? 644 kB

NFS_Unstable:? ? ? ? ? 0 kB

Bounce:? ? ? ? ? ? ? ? 0 kB

WritebackTmp:? ? ? ? ? 0 kB

CommitLimit:? ? ? 62532 kB

Committed_AS:? ? ? 94268 kB

VmallocTotal:? ? 1048372 kB

VmallocUsed:? ? ? 12308 kB

VmallocChunk:? ? 1020828 kB

我們看到，第二次ps看到測試進(jìn)程占用的虛擬內(nèi)存為73M，而此時(shí)MemFree:? ? ? ? ? 21936 kB，約為21M，也就是物理內(nèi)存距上次的28M減少到21M，吃掉了7M，但虛擬內(nèi)存是16M增長到73M，這明顯不是一個(gè)換算關(guān)系，接下來我們看物理內(nèi)存在哪里看：

3）查看物理內(nèi)存占用，通過/proc/pid/stat或/proc/pid/statm（這里不能設(shè)置字體顏色，以粗體表示）

root@OpenWrt:/# cat /proc/14444/statm

21861 2332 202 1 0 20985 0

我們看到的21861表示VSZ，2332表示物理內(nèi)存，這里的單位是頁（page），我所用的系統(tǒng)當(dāng)前頁單位設(shè)置是4KB/頁，所以可以得出：

VSZ =?21861 *4 = 87444KB，約87M（使用3）查看時(shí)，已距73M過了一段時(shí)間）

物理內(nèi)存=2332?*4 = 9328，約9M，這時(shí)我們可以看到，基本可以和/proc/meminfo對(duì)的上了

或者，我們采用下面命令進(jìn)行查看，同樣可以看到該結(jié)果，這是下面文件參數(shù)太多，如果只是看內(nèi)存，建議使用上個(gè)文件（注：下個(gè)文件中的89702400字段單位為Bytes而不是頁，有些網(wǎng)上的文檔解釋成頁，就誤導(dǎo)了，而2332字段的單位是頁）

root@OpenWrt:/# cat /proc/14444/stat

14444 (test_core_dump) S 496 14444 496 1089 29862 4194304 2488 0 0 0 36 14 0 0 20 0 1 0 7535179 89702400 2332 2147483647 4194304 4197032 2145364880 2145364392 1999211440 0 0 4096 0 2164588092 0 0 18 3 0 0 0 0 0 4262568 4262663 11354112 2145365870 2145365885 2145365885 2145365988 0

此時(shí)，通過上面的命令及文件的分析，基本可以定位或查找出應(yīng)用進(jìn)程的內(nèi)存泄漏問題。

注：

1）ps和top命令很多網(wǎng)上的文檔會(huì)說有VIRT、RES和SHR字段，但這可能是在PC端的linux，在嵌入式中，我遇到的僅有VSZ字段，相當(dāng)于VIRT，所以要通過/proc/pid下的文件輔助

2）參考1）：/proc/pid/stat字段說明（該文章用紅色字體標(biāo)明vsize的錯(cuò)誤，贊）

3）參考2）：進(jìn)程的虛擬內(nèi)存，物理內(nèi)存，共享內(nèi)存(包括statm文件格式說明)，這里解釋了虛擬內(nèi)存和駐留內(nèi)存（我理解實(shí)際使用的內(nèi)存）的關(guān)系，就是上面VSZ和/proc/meminfo的數(shù)據(jù)關(guān)系

4）參考3）：proc/meminfo 文件內(nèi)存詳解

內(nèi)核/或因應(yīng)用進(jìn)程的操作導(dǎo)致內(nèi)核空間的內(nèi)存泄漏

排查內(nèi)核空間的內(nèi)存泄漏，這里主要爭對(duì)slab來講，嘗試下面幾步：

1）查看/proc/meminfo 中slab相關(guān)的字段：

root@OpenWrt:/# cat /proc/meminfo

MemTotal:? ? ? ? 125064 kB

MemFree:? ? ? ? ? ? 8536 kB

Buffers:? ? ? ? ? ? 8128 kB

Cached:? ? ? ? ? ? 28736 kB

SwapCached:? ? ? ? ? ? 0 kB

Active:? ? ? ? ? ? 20892 kB

Inactive:? ? ? ? ? 21356 kB

Active(anon):? ? ? 8628 kB

Inactive(anon):? ? ? 692 kB

Active(file):? ? ? 12264 kB

Inactive(file):? ? 20664 kB

Unevictable:? ? ? ? ? 0 kB

Mlocked:? ? ? ? ? ? ? 0 kB

SwapTotal:? ? ? ? ? ? 0 kB

SwapFree:? ? ? ? ? ? ? 0 kB

Dirty:? ? ? ? ? ? ? ? 0 kB

Writeback:? ? ? ? ? ? 0 kB

AnonPages:? ? ? ? ? 5336 kB

Mapped:? ? ? ? ? ? 4664 kB

Shmem:? ? ? ? ? ? ? 3936 kB

Slab:? ? ? ? ? ? ? 57380 kB

SReclaimable:? ? ? 23040 kB

SUnreclaim:? ? ? ? 34340 kB

KernelStack:? ? ? ? 640 kB

PageTables:? ? ? ? ? 552 kB

NFS_Unstable:? ? ? ? ? 0 kB

Bounce:? ? ? ? ? ? ? ? 0 kB

WritebackTmp:? ? ? ? ? 0 kB

CommitLimit:? ? ? 62532 kB

Committed_AS:? ? ? 23520 kB

VmallocTotal:? ? 1048372 kB

VmallocUsed:? ? ? 12308 kB

VmallocChunk:? ? 1020828 kB

我們看到，MemFree:? ? ? ? ? ? 8536 kB，約只剩8M內(nèi)存，通過查看slab相關(guān)字段，Slab:? ? ? ? ? ? ? 57380 kB我們看到約占用了57M空間，其中可回收的slab占，SReclaimable:? ? ? 23040 kB，不可回收的slab占，SUnreclaim:? ? ? ? 34340 kB，再看下半天前保留下來的meminfo（為了查找問題，提前保留的信息以作對(duì)比）

root@OpenWrt:/# cat /proc/meminfo

MemTotal: 125064 kB

MemFree:? ? ? ? ? 21196 kB?

Buffers:? ? ? ? ? ? 8128 kB?

Cached:? ? ? ? ? ? 26456 kB?

SwapCached:? ? ? ? ? ? 0 kB?

Active:? ? ? ? ? ? 22968 kB?

Inactive:? ? ? ? ? 21528 kB?

Active(anon):? ? ? 10984 kB?

Inactive(anon):? ? ? 588 kB?

Active(file):? ? ? 11984 kB?

Inactive(file):? ? 20940 kB?

Unevictable:? ? ? ? ? 0 kB?

Mlocked:? ? ? ? ? ? ? 0 kB?

SwapTotal:? ? ? ? ? ? 0 kB?

SwapFree:? ? ? ? ? ? ? 0 kB?

Dirty:? ? ? ? ? ? ? ? 0 kB?

Writeback:? ? ? ? ? ? 0 kB?

AnonPages:? ? ? ? ? 9948 kB?

Mapped:? ? ? ? ? ? 4680 kB?

Shmem:? ? ? ? ? ? ? 1660 kB?

Slab:? ? ? ? ? ? ? 42372 kB?

SReclaimable:? ? ? 11800 kB?

SUnreclaim:? ? ? ? 30572 kB?

KernelStack:? ? ? ? 624 kB?

PageTables:? ? ? ? ? 572 kB?

NFS_Unstable:? ? ? ? ? 0 kB?

Bounce:? ? ? ? ? ? ? ? 0 kB?

WritebackTmp:? ? ? ? ? 0 kB?

CommitLimit:? ? ? 62532 kB?

Committed_AS:? ? ? 26704 kB?

VmallocTotal:? ? 1048372 kB?

VmallocUsed:? ? ? 12308 kB?

VmallocChunk:? ? 1020828 kB?

可以看出，slab大約增加了15M內(nèi)存的使用（57-42），而我們再仔細(xì)看，這其中SReclaimable約前后相差12M（23-11），這部分空間是可以回收的。既然這塊內(nèi)存變化較大，那我們重點(diǎn)看下slab的內(nèi)存分配情況：

2）cat /proc/slabinfo， 這里信息太多，不全部放上來，我采集了兩個(gè)速據(jù)做對(duì)比，這兩個(gè)速據(jù)之間有一個(gè)動(dòng)作，第3）步再講：

圖1

圖2

有一個(gè)比較好的命令可以顯示的比cat /proc/slabinfo更直觀，但是我之前沒有去了解，因?yàn)榱?xí)慣性動(dòng)作，直接cat文件，雖然一直覺得這個(gè)文件不是很直觀，這個(gè)第4）步講一下。我們來看這個(gè)數(shù)據(jù)，按照常規(guī)的邏輯，先找最大的那個(gè)數(shù)，或者我們慣性覺得最大的數(shù)就是異常的，在圖1中我們看到dentry比較異常，共計(jì)153381個(gè)num_objs對(duì)象，每個(gè)對(duì)象136字節(jié)，占用空間約19M，我們看圖2第二個(gè)異常kmalloc-128，共計(jì)124200個(gè)num_objs對(duì)象，每個(gè)對(duì)象128字節(jié)，占空間約15M。

通過分析內(nèi)存占用較大的slab可以定位大概是哪里的問題，比如這兩個(gè)占用內(nèi)存比較大的slab，第一個(gè)dentry和文件操作相關(guān)，應(yīng)該是應(yīng)用層頻繁的文件操作導(dǎo)致內(nèi)核頻繁申請(qǐng)dentry內(nèi)存所致；第二個(gè)kmalloc-128是內(nèi)核模塊自己申請(qǐng)內(nèi)存導(dǎo)致，這個(gè)可以首先排查自己私有模塊用到128字節(jié)以內(nèi)分配的調(diào)用，然后排查內(nèi)核本身（如果這里有問題，內(nèi)核本身的問題概率較少）。

3）嘗試釋放Slab占用的cache內(nèi)存空間

雖然我們看到有兩個(gè)slab占用較多，但是不能說這就是內(nèi)存泄漏（或者也可以說是一種泄漏吧，只是不是因?yàn)閗malloc后沒有kfree），也許是他就是要用到這么多內(nèi)存，只是因?yàn)槟撤N設(shè)計(jì)原因?qū)е滤^多和過快的占用了內(nèi)存，影響到系統(tǒng)的穩(wěn)定性。因?yàn)槲覀兦懊嬉部吹剑?b>SReclaimable:? ? ? 23040 kB有23M之多，這些是可回收和利用的，只是我們的系統(tǒng)還沒有觸發(fā)回收機(jī)制。

當(dāng)前做一個(gè)簡單的嘗試，使用命令：

echo?2?>?/proc/sys/vm/drop_caches

該命令釋放dentries and inodes的可回收slab內(nèi)存。

我們再來看，釋放后的meminfo和slab：

root@OpenWrt:/# cat /proc/meminfo

MemTotal:? ? ? ? 125064 kB

MemFree:? ? ? ? ? 33912 kB

Buffers:? ? ? ? ? ? 8128 kB

Cached:? ? ? ? ? ? 27108 kB

SwapCached:? ? ? ? ? ? 0 kB

Active:? ? ? ? ? ? 20140 kB

Inactive:? ? ? ? ? 20456 kB

Active(anon):? ? ? 8616 kB

Inactive(anon):? ? ? 692 kB

Active(file):? ? ? 11524 kB

Inactive(file):? ? 19764 kB

Unevictable:? ? ? ? ? 0 kB

Mlocked:? ? ? ? ? ? ? 0 kB

SwapTotal:? ? ? ? ? ? 0 kB

SwapFree:? ? ? ? ? ? ? 0 kB

Dirty:? ? ? ? ? ? ? ? 0 kB

Writeback:? ? ? ? ? ? 0 kB

AnonPages:? ? ? ? ? 5416 kB

Mapped:? ? ? ? ? ? 4664 kB

Shmem:? ? ? ? ? ? ? 3948 kB

Slab:? ? ? ? ? ? ? 33716 kB

SReclaimable:? ? ? 2936 kB

SUnreclaim:? ? ? ? 30780 kB

我們看到，MemFree:? ? ? ? ? 33912 kB，從8M提升到了33M，slab從57M降低到33M，差不多回收了20多M內(nèi)存，基本吻合，以此也可進(jìn)一步判斷這些內(nèi)存不是因?yàn)闆]有kfree進(jìn)了黑洞，而是因?yàn)閗free后還沒有被系統(tǒng)回收和利用。那么我看在看看slabinfo，看數(shù)據(jù)是否也吻合，我們可以參考圖1與圖2的對(duì)比：drop_caches后，dentry，共計(jì)7714個(gè)num_objs對(duì)象，每個(gè)對(duì)象136字節(jié)，占用空間約1M；kmalloc-128，共計(jì)97350個(gè)num_objs對(duì)象，每個(gè)對(duì)象128字節(jié)，占空間約11M。對(duì)比drop_caches前，相當(dāng)于(19+15-1-11）=22M，和回收了20多M內(nèi)存也基本吻合。但從這里可以得出經(jīng)驗(yàn)：

1，kmalloc-128還是有嫌疑，這個(gè)還是可以通過排除私有內(nèi)核模塊來處理，比如在系統(tǒng)啟動(dòng)后，所有模塊加載完成的第一時(shí)間看slabinfo，如果在11M左右，說明確實(shí)需要，沒有泄漏的異常，如果這個(gè)數(shù)據(jù)越來越大，通過drop_caches也回收不了且回收后大于11M較多，那就要檢查內(nèi)核相關(guān)模塊；

2，dentry內(nèi)存如果是因?yàn)閼?yīng)用層導(dǎo)致，則基本是可回收的，因?yàn)椴皇莾?nèi)核本身的異常，所以這時(shí)需要優(yōu)化應(yīng)用層相關(guān)的程序避免這個(gè)問題。

4）slabtop命令

Slab是用于存放內(nèi)核數(shù)據(jù)結(jié)構(gòu)緩存，再通過slabtop命令查看這部分內(nèi)存的使用情況，這個(gè)和查看slabinfo效果一樣，但是比較直觀，具體格式這里不做解釋，和slabinfo差不多：

root@OpenWrt:/# slabtop

Active / Total Objects (% used) : 217931 / 232100 (93.9%)

Active / Total Slabs (% used)? ? ? : 9664 / 9664 (100.0%)

Active / Total Caches (% used)? ? : 97 / 199 (48.7%)

Active / Total Size (% used)? ? ? : 37514.55K / 38973.26K (96.3%)

Minimum / Average / Maximum Object : 0.01K / 0.17K / 4096.00K

? OBJS ACTIVE? USE OBJ SIZE? SLABS OBJ/SLAB CACHE SIZE NAME? ? ? ? ? ? ? ? ?

96900? 91608? 94%? ? 0.13K? 3230? ? ? 30? ? 12920K kmalloc-128

54259? 54259 100%? ? 0.13K? 1871? ? ? 29? ? ? 7484K dentry

10962? 7956? 72%? ? 0.02K? ? 54? ? ? 203? ? ? 216K ft_dic_binary_cache

? 8673? 8660? 99%? ? 0.06K? ? 147? ? ? 59? ? ? 588K buffer_head

? 8475? 8175? 96%? ? 0.01K? ? 25? ? ? 339? ? ? 100K ft_head_cache

? 5369? 5215? 97%? ? 0.06K? ? 91? ? ? 59? ? ? 364K sysfs_dir_cache

? 5010? 4974? 99%? ? 0.25K? ? 334? ? ? 15? ? ? 1336K kmalloc-256

? 2448? 2409? 98%? ? 0.50K? ? 306? ? ? ? 8? ? ? 1224K kmalloc-512

? 2424? 2421? 99%? ? 1.00K? ? 606? ? ? ? 4? ? ? 2424K kmalloc-1024

? 2175? 2154? 99%? ? 0.02K? ? 15? ? ? 145? ? ? ? 60K match_tree_feat_layer

? 2085? 1783? 85%? ? 0.25K? ? 139? ? ? 15? ? ? 556K skbuff_head_cache

? 1956? 1918? 98%? ? 2.00K? ? 978? ? ? ? 2? ? ? 3912K kmalloc-2048

? 1880? 1700? 90%? ? 0.09K? ? 47? ? ? 40? ? ? 188K vm_area_struct

? 1740? 1677? 96%? ? 0.02K? ? 12? ? ? 145? ? ? ? 48K ft_dic_tree_head_cache

? 1608? 1556? 96%? ? 0.32K? ? 134? ? ? 12? ? ? 536K inode_cache

? 1400? 1400 100%? ? 0.19K? ? 70? ? ? 20? ? ? 280K filp

注：

1）參考一篇比較好的linux內(nèi)存管理文章：詳細(xì)講解從用戶空間申請(qǐng)內(nèi)存到內(nèi)核如何為其分配內(nèi)存的過程，我把上面講的內(nèi)容放在一起，大概就是一個(gè)這樣的圖：

圖3

2）參考：Linux Malloc分析-從用戶空間到內(nèi)核空間

3）drop_caches相關(guān)參考，及設(shè)置內(nèi)存回收的條件和時(shí)機(jī)：Linux服務(wù)器Cache占用過多內(nèi)存導(dǎo)致系統(tǒng)內(nèi)存不足問題的排查解決，Linux服務(wù)器Cache占用過多內(nèi)存導(dǎo)致系統(tǒng)內(nèi)存不足問題的排查解決（續(xù)）

用戶空間產(chǎn)生的臨時(shí)文件（如日志等）造成的內(nèi)存泄漏

這個(gè)其實(shí)開發(fā)人員自己心里可能是清楚的，因?yàn)檫@些臨時(shí)文件基本是自己產(chǎn)生的，但因?yàn)槿狈y(tǒng)一設(shè)計(jì)（比如統(tǒng)一使用syslog）和沒上心，可能把這個(gè)問題帶到測試或客戶環(huán)境，可以通過命令du -sh查看：

圖4