Linux內(nèi)核內(nèi)存管理問題

前言

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

【OOM - Out of Memory】內(nèi)存溢出

內(nèi)存溢出的解決辦法：

1、等比例縮小圖片

2、對圖片采用軟引用，及時進(jìn)行 recycle( ) 操作。

3、使用加載圖片框架處理圖片，如專業(yè)處理圖片的 ImageLoader 圖片加載框架，還有XUtils 的 BitMapUtils 來處理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)進(jìn)程在用戶態(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)，這就是為什么當(dāng)我們調(diào)用 free 回收內(nèi)存之后，再次訪問這塊內(nèi)存時，可能不會報錯的原因。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 共享文件映射

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

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

當(dāng)我在本地新建一個1G的文件：

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

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

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

3.2 私有文件映射段

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

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

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

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

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

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

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

3.3 私有匿名映射

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

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

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

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

3.4 共享匿名映射

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

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

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

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

當(dāng)系統(tǒng)內(nèi)存不足時，有兩種方式進(jìn)行內(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)于這個的簡介

從這個介紹可以看出，當(dāng) drop_caches 文件為1時，這時將釋放 pagecache 中可釋放的部分（有些 cache 是不能通過這個釋放的），當(dāng) drop_caches 為2時，這時將釋放 dentries 和 inodes 緩存，當(dāng) 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)很復(fù)雜，之前有介紹虛擬文件系統(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ù)拷貝到用戶空間，當(dāng)我們要讀物的數(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ù)，并標(biāo)為 dirty。

如果要寫的數(shù)據(jù)不再內(nèi)存中，則判斷是否在swap 中，如果在，則先讀取出來，用新數(shù)據(jù)覆蓋老數(shù)據(jù)并標(biāo)為臟，如果即不在內(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)，最后兩個進(jìn)程操作同一個物理內(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)進(jìn)程通信，這我就不寫測試程序了，而且這也是不能回收的，因為共享內(nèi)存ipc機(jī)制生命周期是隨內(nèi)核的，也就是說你創(chuàng)建共享內(nèi)存之后，如果不顯示刪除的話，進(jìn)程退出之后，共享內(nèi)存還是存在的。

之前看了一些技術(shù)博客，說到 Poxic 和 System V 兩套 ipc 機(jī)制(消息隊列，信號量以及共享內(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則用紅黑樹了存儲消息(我下載了這兩個版本，具體什么時候開始用紅黑樹，沒深究)。

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

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

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

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

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

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

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

第二句后半部分，

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

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

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

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

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

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

LRU_UNEVICTABLE 即為不可驅(qū)逐頁 lru，我的理解就是當(dāng)調(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 隊列進(jìn)行掃描，在活躍鏈表中查找不活躍的頁，并添加不活躍鏈表。

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

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

文件頁：

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

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

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

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

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

5、總結(jié)

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

首先是回顧了進(jìn)程地址空間；

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

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