77% 的 Linux 運維都不懂的內(nèi)核問題，這篇全告訴你了

前言

之前在實習時，聽了 OOM 的分享之后，就對 Linux 內(nèi)核內(nèi)存管理充滿興趣，但是這塊知識非常龐大，沒有一定積累，不敢寫下，擔心誤人子弟，所以經(jīng)過一個一段時間的積累，對內(nèi)核內(nèi)存有一定了解之后，今天才寫下這篇博客，記錄以及分享。

【OOM - Out of Memory】內(nèi)存溢出
內(nèi)存溢出的解決辦法：
1、等比例縮小圖片
2、對圖片采用軟引用，及時進行 recycle( ) 操作。
3、使用加載圖片框架處理圖片，如專業(yè)處理圖片的 ImageLoader 圖片加載框架，還有XUtils 的 BitMapUtils 來處理。

這篇文章主要是分析了單個進程空間的內(nèi)存布局與分配，是從全局的視角分析下內(nèi)核對內(nèi)存的管理;

下面主要從以下方面介紹 Linux 內(nèi)存管理:

• 進程的內(nèi)存申請與分配；

• 內(nèi)存耗盡之后 OOM；

• 申請的內(nèi)存都在哪？

• 系統(tǒng)回收內(nèi)存；

1、進程的內(nèi)存申請與分配

之前有篇文章介紹 hello world 程序是如何載入內(nèi)存以及是如何申請內(nèi)存的，我在這，再次說明下：同樣，還是先給出進程的地址空間，我覺得對于任何開發(fā)人員這張圖是必須記住的，還有一張就是操作 disk ，memory 以及 cpu cache 的時間圖。

當我們在終端啟動一個程序時，終端進程調(diào)用 exec 函數(shù)將可執(zhí)行文件載入內(nèi)存，此時代碼段，數(shù)據(jù)段，bbs 段，stack 段都通過 mmap 函數(shù)映射到內(nèi)存空間，堆則要根據(jù)是否有在堆上申請內(nèi)存來決定是否映射。

exec 執(zhí)行之后，此時并未真正開始執(zhí)行進程，而是將 cpu 控制權(quán)交給了動態(tài)鏈接庫裝載器，由它來將該進程需要的動態(tài)鏈接庫裝載進內(nèi)存。之后才開始進程的執(zhí)行，這個過程可以通過 strace 命令跟蹤進程調(diào)用的系統(tǒng)函數(shù)來分析。

這是我上篇博客認識 pipe 中的程序，從這個輸出過程，可以看出和我上述描述的一致。

當?shù)谝淮握{(diào)用 malloc 申請內(nèi)存時，通過系統(tǒng)調(diào)用 brk 嵌入到內(nèi)核，首先會進行一次判斷，是否有關(guān)于堆的 vma，如果沒有，則通過 mmap 匿名映射一塊內(nèi)存給堆，并建立 vma 結(jié)構(gòu)，掛到 mm_struct 描述符上的紅黑樹和鏈表上。

然后回到用戶態(tài)，通過內(nèi)存分配器（ptmaloc，tcmalloc，jemalloc）算法將分配到的內(nèi)存進行管理，返回給用戶所需要的內(nèi)存。

如果用戶態(tài)申請大內(nèi)存時，是直接調(diào)用 mmap 分配內(nèi)存，此時返回給用戶態(tài)的內(nèi)存還是虛擬內(nèi)存，直到第一次訪問返回的內(nèi)存時，才真正進行內(nèi)存的分配。

其實通過 brk 返回的也是虛擬內(nèi)存，但是經(jīng)過內(nèi)存分配器進行切割分配之后（切割就必須訪問內(nèi)存），全都分配到了物理內(nèi)存

當進程在用戶態(tài)通過調(diào)用 free 釋放內(nèi)存時，如果這塊內(nèi)存是通過 mmap 分配，則調(diào)用 munmap 直接返回給系統(tǒng)。

否則內(nèi)存是先返回給內(nèi)存分配器，然后由內(nèi)存分配器統(tǒng)一返還給系統(tǒng)，這就是為什么當我們調(diào)用 free 回收內(nèi)存之后，再次訪問這塊內(nèi)存時，可能不會報錯的原因。

當然，當整個進程退出之后，這個進程占用的內(nèi)存都會歸還給系統(tǒng)。

2、內(nèi)存耗盡之后OOM

在實習期間，有一臺測試機上的 mysql 實例經(jīng)常被 oom 殺死，OOM（out of memory）即為系統(tǒng)在內(nèi)存耗盡時的自我拯救措施，他會選擇一個進程，將其殺死，釋放出內(nèi)存，很明顯，哪個進程占用的內(nèi)存最多，即最可能被殺死，但事實是這樣的嗎？

昨天早上去上班，剛好碰到了一起 OOM，突然發(fā)現(xiàn)，OOM 一次，世界都安靜下來了，哈哈，測試機上的 redis 被殺死了。?

OOM 關(guān)鍵文件 oom_kill.c，里面介紹了當內(nèi)存不夠時，系統(tǒng)如何選擇最應該被殺死的進程，選擇因素有挺多的，除了進程占用的內(nèi)存外，還有進程運行的時間，進程的優(yōu)先級，是否為 root 用戶進程，子進程個數(shù)和占用內(nèi)存以及用戶控制參數(shù) oom_adj 都相關(guān)。

當產(chǎn)生 oom 之后，函數(shù) select_bad_process 會遍歷所有進程，通過之前提到的那些因素，每個進程都會得到一個 oom_score 分數(shù)，分數(shù)最高，則被選為殺死的進程。

我們可以通過設(shè)置 /proc//oom_adj 分數(shù)來干預系統(tǒng)選擇殺死的進程。

這是內(nèi)核關(guān)于這個oom_adj調(diào)整值的定義，最大可以調(diào)整為15,最小為-16，如果為-17，則該進程就像買了vip會員一樣，不會被系統(tǒng)驅(qū)逐殺死了，因此，如果在一臺機器上有跑很多服務器，且你不希望自己的服務被殺死的話，就可以設(shè)置自己服務的 oom_adj 為-17。

當然，說到這，就必須提到另一個參數(shù) /proc/sys/vm/overcommit_memory，man proc 說明如下:?

意思就是當 overcommit_memory 為0時，則為啟發(fā)式oom，即當申請的虛擬內(nèi)存不是很夸張的大于物理內(nèi)存，則系統(tǒng)允許申請，但是當進程申請的虛擬內(nèi)存很夸張的大于物理內(nèi)存，則就會產(chǎn)生 OOM。

例如只有8g的物理內(nèi)存，然后 redis 虛擬內(nèi)存占用了24G，物理內(nèi)存占用3g，如果這時執(zhí)行 bgsave，子進程和父進程共享物理內(nèi)存，但是虛擬內(nèi)存是自己的，即子進程會申請24g的虛擬內(nèi)存，這很夸張大于物理內(nèi)存，就會產(chǎn)生一次OOM。

當 overcommit_memory 為1時，則永遠都允許 overmemory 內(nèi)存申請，即不管你多大的虛擬內(nèi)存申請都允許，但是當系統(tǒng)內(nèi)存耗盡時，這時就會產(chǎn)生oom，即上述的redis例子，在 overcommit_memory=1 時，是不會產(chǎn)生oom 的，因為物理內(nèi)存足夠。

當 overcommit_memory 為2時，永遠都不能超出某個限定額的內(nèi)存申請，這個限定額為 swap+RAM* 系數(shù)（/proc/sys/vm/overcmmit_ratio，默認50%，可以自己調(diào)整），如果這么多資源已經(jīng)用光，那么后面任何嘗試申請內(nèi)存的行為都會返回錯誤，這通常意味著此時沒法運行任何新程序

以上就是 OOM 的內(nèi)容，了解原理，以及如何根據(jù)自己的應用，合理的設(shè)置OOM。

3、系統(tǒng)申請的內(nèi)存都在哪？

我們了解了一個進程的地址空間之后，是否會好奇，申請到的物理內(nèi)存都存在哪了？可能很多人覺得，不就是物理內(nèi)存嗎？

我這里說申請的內(nèi)存在哪，是因為物理內(nèi)存有分為cache和普通物理內(nèi)存，可以通過 free 命令查看，而且物理內(nèi)存還有分 DMA，NORMAL，HIGH 三個區(qū)，這里主要分析cache和普通內(nèi)存。

通過第一部分，我們知道一個進程的地址空間幾乎都是 mmap 函數(shù)申請，有文件映射和匿名映射兩種。

3.1 共享文件映射

我們先來看下代碼段和動態(tài)鏈接庫映射段，這兩個都是屬于共享文件映射，也就是說由同一個可執(zhí)行文件啟動的兩個進程是共享這兩個段，都是映射到同一塊物理內(nèi)存，那么這塊內(nèi)存在哪了？我寫了個程序測試如下：

我們先看下當前系統(tǒng)的內(nèi)存使用情況:?

當我在本地新建一個1G的文件：

dd?if=/dev/zero?of=fileblock?bs=M?count=1024

然后調(diào)用上述程序，進行共享文件映射,此時內(nèi)存使用情況為：?

我們可以發(fā)現(xiàn)，buff/cache 增長了大概1G，因此我們可以得出結(jié)論，代碼段和動態(tài)鏈接庫段是映射到內(nèi)核cache中，也就是說當執(zhí)行共享文件映射時，文件是先被讀取到 cache 中，然后再映射到用戶進程空間中。

3.2 私有文件映射段

對于進程空間中的數(shù)據(jù)段，其必須是私有文件映射，因為如果是共享文件映射，那么同一個可執(zhí)行文件啟動的兩個進程，任何一個進程修改數(shù)據(jù)段，都將影響另一個進程了，我將上述測試程序改寫成匿名文件映射：?

在執(zhí)行程序執(zhí)行，需要先將之前的 cache 釋放掉，否則會影響結(jié)果

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

接著執(zhí)行程序，看下內(nèi)存使用情況:?

從使用前和使用后對比，可以發(fā)現(xiàn) used 和 buff/cache 分別增長了1G，說明當進行私有文件映射時，首先是將文件映射到 cache 中，然后如果某個文件對這個文件進行修改，則會從其他內(nèi)存中分配一塊內(nèi)存先將文件數(shù)據(jù)拷貝至新分配的內(nèi)存，然后再在新分配的內(nèi)存上進行修改，這也就是寫時復制。

這也很好理解，因為如果同一個可執(zhí)行文件開啟多個實例，那么內(nèi)核先將這個可執(zhí)行的數(shù)據(jù)段映射到 cache，然后每個實例如果有修改數(shù)據(jù)段，則都將分配一個一塊內(nèi)存存儲數(shù)據(jù)段，畢竟數(shù)據(jù)段也是一個進程私有的。

通過上述分析，可以得出結(jié)論，如果是文件映射，則都是將文件映射到 cache 中，然后根據(jù)共享還是私有進行不同的操作。

3.3 私有匿名映射

像 bbs 段，堆，棧這些都是匿名映射，因為可執(zhí)行文件中沒有相應的段，而且必須是私有映射，否則如果當前進程 fork 出一個子進程，那么父子進程將會共享這些段，一個修改都會影響到彼此，這是不合理的。

ok，現(xiàn)在我把上述測試程序改成私有匿名映射?

這時再來看下內(nèi)存的使用情況?

我們可以看到，只有 used 增加了1G，而 buff/cache 并沒有增長；說明，在進行匿名私有映射時，并沒有占用 cache，其實這也是有道理，因為就只有當前進程在使用這塊這塊內(nèi)存，沒有必要占用寶貴的 cache。

3.4 共享匿名映射

當我們需要在父子進程共享內(nèi)存時，就可以用到 mmap 共享匿名映射，那么共享匿名映射的內(nèi)存是存放在哪了？我繼續(xù)改寫上述測試程序為共享匿名映射 。

這時來看下內(nèi)存的使用情況：?

從上述結(jié)果，我們可以看出，只有buff/cache增長了1G，即當進行共享匿名映射時，這時是從 cache 中申請內(nèi)存，道理也很明顯，因為父子進程共享這塊內(nèi)存，共享匿名映射存在于 cache，然后每個進程再映射到彼此的虛存空間，這樣即可操作的是同一塊內(nèi)存。

4、系統(tǒng)回收內(nèi)存

當系統(tǒng)內(nèi)存不足時，有兩種方式進行內(nèi)存釋放，一種是手動的方式，另一種是系統(tǒng)自己觸發(fā)的內(nèi)存回收，先來看下手動觸發(fā)方式。

4.1 手動回收內(nèi)存

手動回收內(nèi)存，之前也有演示過，即

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

我們可以在 man proc 下面看到關(guān)于這個的簡介?

從這個介紹可以看出，當 drop_caches 文件為1時，這時將釋放 pagecache 中可釋放的部分（有些 cache 是不能通過這個釋放的），當 drop_caches 為2時，這時將釋放 dentries 和 inodes 緩存，當 drop_caches 為3時，這同時釋放上述兩項。

關(guān)鍵還有最后一句，意思是說如果 pagecache 中有臟數(shù)據(jù)時，操作 drop_caches 是不能釋放的，必須通過 sync 命令將臟數(shù)據(jù)刷新到磁盤，才能通過操作 drop_caches 釋放 pagecache。

ok，之前有提到有些pagecache是不能通過drop_caches釋放的，那么除了上述提文件映射和共享匿名映射外，還有有哪些東西是存在pagecache了？

4.2 tmpfs

我們先來看下 tmpfs ，tmpfs 和 procfs，sysfs 以及 ramfs 一樣，都是基于內(nèi)存的文件系統(tǒng)，tmpfs 和 ramfs 的區(qū)別就是 ramfs 的文件基于純內(nèi)存的，和 tmpfs 除了純內(nèi)存外，還會使用 swap 交換空間，以及 ramfs 可能會把內(nèi)存耗盡，而 tmpfs 可以限定使用內(nèi)存大小，可以用命令 df -T -h 查看系統(tǒng)一些文件系統(tǒng)，其中就有一些是 tmpfs，比較出名的是目錄 /dev/shm

tmpfs 文件系統(tǒng)源文件在內(nèi)核源碼 mm/shmem.c，tmpfs實現(xiàn)很復雜，之前有介紹虛擬文件系統(tǒng)，基于 tmpfs 文件系統(tǒng)創(chuàng)建文件和其他基于磁盤的文件系統(tǒng)一樣，也會有 inode，super_block，identry，file 等結(jié)構(gòu)，區(qū)別主要是在讀寫上，因為讀寫才涉及到文件的載體是內(nèi)存還是磁盤。

而 tmpfs 文件的讀函數(shù) shmem_file_read，過程主要為通過 inode 結(jié)構(gòu)找到 address_space 地址空間，其實就是磁盤文件的 pagecache，然后通過讀偏移定位cache 頁以及頁內(nèi)偏移。

這時就可以直接從這個 pagecache 通過函數(shù) __copy_to_user 將緩存頁內(nèi)數(shù)據(jù)拷貝到用戶空間，當我們要讀物的數(shù)據(jù)不pagecache中時，這時要判斷是否在 swap 中，如果在則先將內(nèi)存頁 swap in，再讀取。

tmpfs 文件的寫函數(shù) shmem_file_write，過程主要為先判斷要寫的頁是否在內(nèi)存中，如果在，則直接將用戶態(tài)數(shù)據(jù)通過函數(shù)__copy_from_user拷貝至內(nèi)核pagecache中覆蓋老數(shù)據(jù)，并標為 dirty。

如果要寫的數(shù)據(jù)不再內(nèi)存中，則判斷是否在swap 中，如果在，則先讀取出來，用新數(shù)據(jù)覆蓋老數(shù)據(jù)并標為臟，如果即不在內(nèi)存也不在磁盤，則新生成一個 pagecache 存儲用戶數(shù)據(jù)。

由上面分析，我們知道基于 tmpfs 的文件也是使用 cache 的，我們可以在/dev/shm上創(chuàng)建一個文件來檢測下:

看到了吧，cache 增長了1G，驗證了 tmpfs 的確使用的 cache 內(nèi)存。

其實 mmap 匿名映射原理也是用了 tmpfs，在 mm/mmap.c->do_mmap_pgoff 函數(shù)內(nèi)部，有判斷如果 file 結(jié)構(gòu)為空以及為 SHARED 映射，則調(diào)用 shmem_zero_setup(vma) 函數(shù)在 tmpfs 上用新建一個文件?

這里就解釋了為什么共享匿名映射內(nèi)存初始化為0了，但是我們知道用 mmap 分配的內(nèi)存初始化為0，就是說 mmap 私有匿名映射也為0,那么體現(xiàn)在哪了？

這個在 do_mmap_pgoff 函數(shù)內(nèi)部可沒有體現(xiàn)出來，而是在缺頁異常，然后分配一種特殊的初始化為0的頁。

那么這個 tmpfs 占有的內(nèi)存頁可以回收嗎？?

也就是說 tmpfs 文件占有的 pagecache 是不能回收的，道理也很明顯，因為有文件引用這些頁，就不能回收。

4.3 共享內(nèi)存

posix 共享內(nèi)存其實和 mmap 共享映射是同一個道理，都是利用在 tmpfs 文件系統(tǒng)上新建一個文件，然后再映射到用戶態(tài)，最后兩個進程操作同一個物理內(nèi)存，那么 System V 共享內(nèi)存是否也是利用 tmpfs 文件系統(tǒng)了？

我們可以跟蹤到下述函數(shù)?

這個函數(shù)就是新建一個共享內(nèi)存段，其中函數(shù)

shmem_kernel_file_setup

就是在 tmpfs 文件系統(tǒng)上創(chuàng)建一個文件，然后通過這個內(nèi)存文件實現(xiàn)進程通信，這我就不寫測試程序了，而且這也是不能回收的，因為共享內(nèi)存ipc機制生命周期是隨內(nèi)核的，也就是說你創(chuàng)建共享內(nèi)存之后，如果不顯示刪除的話，進程退出之后，共享內(nèi)存還是存在的。

之前看了一些技術(shù)博客，說到 Poxic 和 System V 兩套 ipc 機制(消息隊列，信號量以及共享內(nèi)存)都是使用 tmpfs 文件系統(tǒng)，也就是說最終內(nèi)存使用的都是 pagecache，但是我在源碼中看出了兩個共享內(nèi)存是基于 tmpfs 文件系統(tǒng)，其他信號量和消息隊列還沒看出來(有待后續(xù)考究)。

posix 消息隊列的實現(xiàn)有點類似與 pipe 的實現(xiàn)，也是自己一套 mqueue 文件系統(tǒng)，然后在 inode 上的 i_private 上掛上關(guān)于消息隊列屬性 mqueue_inode_info，在這個屬性上，內(nèi)核2.6時，是用一個數(shù)組存儲消息，而到了4.6則用紅黑樹了存儲消息(我下載了這兩個版本，具體什么時候開始用紅黑樹，沒深究)。

然后兩個進程每次操作都是操作這個 mqueue_inode_info 中的消息數(shù)組或者紅黑樹，實現(xiàn)進程通信，和這個 mqueue_inode_info 類似的還有 tmpfs 文件系統(tǒng)屬性shmem_inode_info 和為epoll服務的文件系統(tǒng) eventloop,也有一個特殊屬性struct eventpoll，這個是掛在 file 結(jié)構(gòu)的 private_data 等等。

說到這，可以小結(jié)下，進程空間中代碼段，數(shù)據(jù)段，動態(tài)鏈接庫(共享文件映射)，mmap 共享匿名映射都存在于 cache 中，但是這些內(nèi)存頁都有被進程引用，所以是不能釋放的，基于 tmpfs 的 ipc 進程間通信機制的生命周期是隨內(nèi)核，因此也是不能通過 drop_caches 釋放。

雖然上述提及的cache不能釋放，但是后面有提到，當內(nèi)存不足時，這些內(nèi)存是可以 swap out 的。

因此 drop_caches 能釋放的就是當從磁盤讀取文件時的緩存頁以及某個進程將某個文件映射到內(nèi)存之后，進程退出，這時映射文件的的緩存頁如果沒有被引用，也是可以被釋放的。

4.4 內(nèi)存自動釋放方式

當系統(tǒng)內(nèi)存不夠時，操作系統(tǒng)有一套自我整理內(nèi)存，并盡可能的釋放內(nèi)存機制，如果這套機制不能釋放足夠多的內(nèi)存，那么只能 OOM 了。

之前在提及 OOM 時，說道 redis 因為 OOM 被殺死，如下:?

第二句后半部分，

total-vm:186660kB,?anon-rss:9388kB,?file-rss:4kB

把一個進程內(nèi)存使用情況，用三個屬性進行了說明，即所有虛擬內(nèi)存，常駐內(nèi)存匿名映射頁以及常駐內(nèi)存文件映射頁。

其實從上述的分析，我們也可以知道一個進程其實就是文件映射和匿名映射：

• 文件映射:代碼段，數(shù)據(jù)段，動態(tài)鏈接庫共享存儲段以及用戶程序的文件映射段；

• 匿名映射：bbs段，堆，以及當 malloc 用 mmap 分配的內(nèi)存，還有mmap共享內(nèi)存段；

其實內(nèi)核回收內(nèi)存就是根據(jù)文件映射和匿名映射來進行的，在 mmzone.h 有如下定義:?

LRU_UNEVICTABLE 即為不可驅(qū)逐頁 lru，我的理解就是當調(diào)用 mlock 鎖住內(nèi)存，不讓系統(tǒng) swap out 出去的頁列表。

簡單說下 linux 內(nèi)核自動回收內(nèi)存原理，內(nèi)核有一個 kswapd 會周期性的檢查內(nèi)存使用情況，如果發(fā)現(xiàn)空閑內(nèi)存定于 pages_low，則 kswapd 會對 lru_list 前四個 lru 隊列進行掃描，在活躍鏈表中查找不活躍的頁，并添加不活躍鏈表。

然后再遍歷不活躍鏈表，逐個進行回收釋放出32個頁，知道 free page 數(shù)量達到 pages_high，針對不同的頁，回收方式也不一樣。

當然，當內(nèi)存水平低于某個極限閾值時，會直接發(fā)出內(nèi)存回收，原理和 kswapd 一樣，但是這次回收力度更大，需要回收更多的內(nèi)存。

文件頁：

• 如果是臟頁，則直接回寫進磁盤，再回收內(nèi)存。

• 如果不是臟頁，則直接釋放回收，因為如果是io讀緩存，直接釋放掉，下次讀時，缺頁異常，直接到磁盤讀回來即可，如果是文件映射頁，直接釋放掉，下次訪問時，也是產(chǎn)生兩個缺頁異常，一次將文件內(nèi)容讀取進磁盤，另一次與進程虛擬內(nèi)存關(guān)聯(lián)。

匿名頁：因為匿名頁沒有回寫的地方，如果釋放掉，那么就找不到數(shù)據(jù)了，所以匿名頁的回收是采取 swap out 到磁盤，并在頁表項做個標記，下次缺頁異常在從磁盤 swap in 進內(nèi)存。

swap 換進換出其實是很占用系統(tǒng)IO的，如果系統(tǒng)內(nèi)存需求突然間迅速增長，那么cpu 將被io占用，系統(tǒng)會卡死，導致不能對外提供服務，因此系統(tǒng)提供一個參數(shù)，用于設(shè)置當進行內(nèi)存回收時，執(zhí)行回收 cache 和 swap 匿名頁的，這個參數(shù)為:

意思就是說這個值越高，越可能使用 swap 的方式回收內(nèi)存，最大值為100，如果設(shè)為0，則盡可能使用回收 cache 的方式釋放內(nèi)存。

5、總結(jié)

這篇文章主要是寫了 linux 內(nèi)存管理相關(guān)的東西：

首先是回顧了進程地址空間；

其次當進程消耗大量內(nèi)存而導致內(nèi)存不足時，我們可以有兩種方式：第一是手動回收 cache；另一種是系統(tǒng)后臺線程 swapd 執(zhí)行內(nèi)存回收工作。

最后當申請的內(nèi)存大于系統(tǒng)剩余的內(nèi)存時，這時就只會產(chǎn)生 OOM，殺死進程，釋放內(nèi)存，從這個過程，可以看出系統(tǒng)為了騰出足夠的內(nèi)存，是多么的努力啊。

推薦閱讀