一文總結一些記憶體問題

這篇文章主要是分析了單個程序空間的記憶體布局與配置設定，是從全局的視角分析下核心對記憶體的管理;

下面主要從以下方面介紹 Linux 記憶體管理:

• 程序的記憶體申請與配置設定；
• 記憶體耗盡之後 OOM；
• 申請的記憶體都在哪？
• 系統回收記憶體；

1、程序的記憶體申請與配置設定

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

當我們在終端啟動一個程式時，終端程序調用 exec 函數将可執行檔案載入記憶體，此時代碼段，資料段，bbs 段，stack 段都通過 mmap 函數映射到記憶體空間，堆則要根據是否有在堆上申請記憶體來決定是否映射。

exec 執行之後，此時并未真正開始執行程序，而是将 cpu 控制權交給了動态連結庫裝載器，由它來将該程序需要的動态連結庫裝載進記憶體。之後才開始程序的執行，這個過程可以通過 strace 指令跟蹤程序調用的系統函數來分析。

這是認識 pipe 中的程式，從這個輸出過程，可以看出和我上述描述的一緻。

當第一次調用 malloc 申請記憶體時，通過系統調用 brk 嵌入到核心，首先會進行一次判斷，是否有關于堆的 vma，如果沒有，則通過 mmap 匿名映射一塊記憶體給堆，并建立 vma 結構，挂到 mm_struct 描述符上的紅黑樹和連結清單上。

然後回到使用者态，通過記憶體配置設定器（ptmaloc，tcmalloc，jemalloc）算法将配置設定到的記憶體進行管理，傳回給使用者所需要的記憶體。

如果使用者态申請大記憶體時，是直接調用 mmap 配置設定記憶體，此時傳回給使用者态的記憶體還是虛拟記憶體，直到第一次通路傳回的記憶體時，才真正進行記憶體的配置設定。

其實通過 brk 傳回的也是虛拟記憶體，但是經過記憶體配置設定器進行切割配置設定之後（切割就必須通路記憶體），全都配置設定到了實體記憶體

當程序在使用者态通過調用 free 釋放記憶體時，如果這塊記憶體是通過 mmap 配置設定，則調用 munmap 直接傳回給系統。

否則記憶體是先傳回給記憶體配置設定器，然後由記憶體配置設定器統一返還給系統，這就是為什麼當我們調用 free 回收記憶體之後，再次通路這塊記憶體時，可能不會報錯的原因。

當然，當整個程序退出之後，這個程序占用的記憶體都會歸還給系統。

更多linux核心視訊教程文檔資料免費領取背景私信【核心】自行擷取.

2、記憶體耗盡之後OOM

在實習期間，有一台測試機上的 mysql 執行個體經常被 oom 殺死，OOM（out of memory）即為系統在記憶體耗盡時的自我拯救措施，他會選擇一個程序，将其殺死，釋放出記憶體，很明顯，哪個程序占用的記憶體最多，即最可能被殺死，但事實是這樣的嗎？

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

OOM 關鍵檔案 oom_kill.c，裡面介紹了當記憶體不夠時，系統如何選擇最應該被殺死的程序，選擇因素有挺多的，除了程序占用的記憶體外，還有程序運作的時間，程序的優先級，是否為 root 使用者程序，子程序個數和占用記憶體以及使用者控制參數 oom_adj 都相關。

當産生 oom 之後，函數 select_bad_process 會周遊所有程序，通過之前提到的那些因素，每個程序都會得到一個 oom_score 分數，分數最高，則被選為殺死的程序。

我們可以通過設定 /proc//oom_adj 分數來幹預系統選擇殺死的程序。

這是核心關于這個oom_adj調整值的定義，最大可以調整為15,最小為-16，如果為-17，則該程序就像買了vip會員一樣，不會被系統驅逐殺死了，是以，如果在一台機器上有跑很多伺服器，且你不希望自己的服務被殺死的話，就可以設定自己服務的 oom_adj 為-17。

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

意思就是當 overcommit_memory 為0時，則為啟發式oom，即當申請的虛拟記憶體不是很誇張的大于實體記憶體，則系統允許申請，但是當程序申請的虛拟記憶體很誇張的大于實體記憶體，則就會産生 OOM。

例如隻有8g的實體記憶體，然後 redis 虛拟記憶體占用了24G，實體記憶體占用3g，如果這時執行 bgsave，子程序和父程序共享實體記憶體，但是虛拟記憶體是自己的，即子程序會申請24g的虛拟記憶體，這很誇張大于實體記憶體，就會産生一次OOM。

當 overcommit_memory 為1時，則永遠都允許 overmemory 記憶體申請，即不管你多大的虛拟記憶體申請都允許，但是當系統記憶體耗盡時，這時就會産生oom，即上述的redis例子，在 overcommit_memory=1 時，是不會産生oom 的，因為實體記憶體足夠。

當 overcommit_memory 為2時，永遠都不能超出某個限定額的記憶體申請，這個限定額為 swap+RAM* 系數（/proc/sys/vm/overcmmit_ratio，預設50%，可以自己調整），如果這麼多資源已經用光，那麼後面任何嘗試申請記憶體的行為都會傳回錯誤，這通常意味着此時沒法運作任何新程式

以上就是 OOM 的内容，了解原理，以及如何根據自己的應用，合理的設定OOM。

3、系統申請的記憶體都在哪？

我們了解了一個程序的位址空間之後，是否會好奇，申請到的實體記憶體都存在哪了？可能很多人覺得，不就是實體記憶體嗎？

我這裡說申請的記憶體在哪，是因為實體記憶體有分為cache和普通實體記憶體，可以通過 free 指令檢視，而且實體記憶體還有分 DMA，NORMAL，HIGH 三個區，這裡主要分析cache和普通記憶體。

通過第一部分，我們知道一個程序的位址空間幾乎都是 mmap 函數申請，有檔案映射和匿名映射兩種。

3.1 共享檔案映射

我們先來看下代碼段和動态連結庫映射段，這兩個都是屬于共享檔案映射，也就是說由同一個可執行檔案啟動的兩個程序是共享這兩個段，都是映射到同一塊實體記憶體，那麼這塊記憶體在哪了？我寫了個程式測試如下：

我們先看下目前系統的記憶體使用情況:

當我在本地建立一個1G的檔案：

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

然後調用上述程式，進行共享檔案映射,此時記憶體使用情況為：

我們可以發現，buff/cache 增長了大概1G，是以我們可以得出結論，代碼段和動态連結庫段是映射到核心cache中，也就是說當執行共享檔案映射時，檔案是先被讀取到 cache 中，然後再映射到使用者程序空間中。

3.2 私有檔案映射段

對于程序空間中的資料段，其必須是私有檔案映射，因為如果是共享檔案映射，那麼同一個可執行檔案啟動的兩個程序，任何一個程序修改資料段，都将影響另一個程序了，我将上述測試程式改寫成匿名檔案映射：

在執行程式執行，需要先将之前的 cache 釋放掉，否則會影響結果

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

接着執行程式，看下記憶體使用情況:

從使用前和使用後對比，可以發現 used 和 buff/cache 分别增長了1G，說明當進行私有檔案映射時，首先是将檔案映射到 cache 中，然後如果某個檔案對這個檔案進行修改，則會從其他記憶體中配置設定一塊記憶體先将檔案資料拷貝至新配置設定的記憶體，然後再在新配置設定的記憶體上進行修改，這也就是寫時複制。

這也很好了解，因為如果同一個可執行檔案開啟多個執行個體，那麼核心先将這個可執行的資料段映射到 cache，然後每個執行個體如果有修改資料段，則都将配置設定一個一塊記憶體存儲資料段，畢竟資料段也是一個程序私有的。

通過上述分析，可以得出結論，如果是檔案映射，則都是将檔案映射到 cache 中，然後根據共享還是私有進行不同的操作。

3.3 私有匿名映射

像 bbs 段，堆，棧這些都是匿名映射，因為可執行檔案中沒有相應的段，而且必須是私有映射，否則如果目前程序 fork 出一個子程序，那麼父子程序将會共享這些段，一個修改都會影響到彼此，這是不合理的。

ok，現在我把上述測試程式改成私有匿名映射

這時再來看下記憶體的使用情況

我們可以看到，隻有 used 增加了1G，而 buff/cache 并沒有增長；說明，在進行匿名私有映射時，并沒有占用 cache，其實這也是有道理，因為就隻有目前程序在使用這塊這塊記憶體，沒有必要占用寶貴的 cache。

3.4 共享匿名映射

當我們需要在父子程序共享記憶體時，就可以用到 mmap 共享匿名映射，那麼共享匿名映射的記憶體是存放在哪了？我繼續改寫上述測試程式為共享匿名映射 。

這時來看下記憶體的使用情況：

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

4、系統回收記憶體

當系統記憶體不足時，有兩種方式進行記憶體釋放，一種是手動的方式，另一種是系統自己觸發的記憶體回收，先來看下手動觸發方式。

4.1 手動回收記憶體

手動回收記憶體，之前也有示範過，即

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

我們可以在 man proc 下面看到關于這個的簡介

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

關鍵還有最後一句，意思是說如果 pagecache 中有髒資料時，操作 drop_caches 是不能釋放的，必須通過 sync 指令将髒資料重新整理到磁盤，才能通過操作 drop_caches 釋放 pagecache。

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

4.2 tmpfs

我們先來看下 tmpfs ，tmpfs 和 procfs，sysfs 以及 ramfs 一樣，都是基于記憶體的檔案系統，tmpfs 和 ramfs 的差別就是 ramfs 的檔案基于純記憶體的，和 tmpfs 除了純記憶體外，還會使用 swap 交換空間，以及 ramfs 可能會把記憶體耗盡，而 tmpfs 可以限定使用記憶體大小，可以用指令 df -T -h 檢視系統一些檔案系統，其中就有一些是 tmpfs，比較出名的是目錄 /dev/shm

tmpfs 檔案系統源檔案在核心源碼 mm/shmem.c，tmpfs實作很複雜，之前有介紹虛拟檔案系統，基于 tmpfs 檔案系統建立檔案和其他基于磁盤的檔案系統一樣，也會有 inode，super_block，identry，file 等結構，差別主要是在讀寫上，因為讀寫才涉及到檔案的載體是記憶體還是磁盤。

而 tmpfs 檔案的讀函數 shmem_file_read，過程主要為通過 inode 結構找到 address_space 位址空間，其實就是磁盤檔案的 pagecache，然後通過讀偏移定位cache 頁以及頁内偏移。

這時就可以直接從這個 pagecache 通過函數 __copy_to_user 将緩存頁内資料拷貝到使用者空間，當我們要讀物的資料不pagecache中時，這時要判斷是否在 swap 中，如果在則先将記憶體頁 swap in，再讀取。

tmpfs 檔案的寫函數 shmem_file_write，過程主要為先判斷要寫的頁是否在記憶體中，如果在，則直接将使用者态資料通過函數__copy_from_user拷貝至核心pagecache中覆寫老資料，并标為 dirty。

如果要寫的資料不再記憶體中，則判斷是否在swap 中，如果在，則先讀取出來，用新資料覆寫老資料并标為髒，如果即不在記憶體也不在磁盤，則新生成一個 pagecache 存儲使用者資料。

由上面分析，我們知道基于 tmpfs 的檔案也是使用 cache 的，我們可以在/dev/shm上建立一個檔案來檢測下:

看到了吧，cache 增長了1G，驗證了 tmpfs 的确使用的 cache 記憶體。

其實 mmap 匿名映射原理也是用了 tmpfs，在 mm/mmap.c->do_mmap_pgoff 函數内部，有判斷如果 file 結構為空以及為 SHARED 映射，則調用 shmem_zero_setup(vma) 函數在 tmpfs 上用建立一個檔案

這裡就解釋了為什麼共享匿名映射記憶體初始化為0了，但是我們知道用 mmap 配置設定的記憶體初始化為0，就是說 mmap 私有匿名映射也為0,那麼展現在哪了？

這個在 do_mmap_pgoff 函數内部可沒有展現出來，而是在缺頁異常，然後配置設定一種特殊的初始化為0的頁。

那麼這個 tmpfs 占有的記憶體頁可以回收嗎？

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

4.3 共享記憶體

posix 共享記憶體其實和 mmap 共享映射是同一個道理，都是利用在 tmpfs 檔案系統上建立一個檔案，然後再映射到使用者态，最後兩個程序操作同一個實體記憶體，那麼 System V 共享記憶體是否也是利用 tmpfs 檔案系統了？

我們可以跟蹤到下述函數

這個函數就是建立一個共享記憶體段，其中函數shmem_kernel_file_setup

就是在 tmpfs 檔案系統上建立一個檔案，然後通過這個記憶體檔案實作程序通信，這我就不寫測試程式了，而且這也是不能回收的，因為共享記憶體ipc機制生命周期是随核心的，也就是說你建立共享記憶體之後，如果不顯示删除的話，程序退出之後，共享記憶體還是存在的。

之前看了一些技術部落格，說到 Poxic 和 System V 兩套 ipc 機制(消息隊列，信号量以及共享記憶體)都是使用 tmpfs 檔案系統，也就是說最終記憶體使用的都是 pagecache，但是我在源碼中看出了兩個共享記憶體是基于 tmpfs 檔案系統，其他信号量和消息隊列還沒看出來(有待後續考究)。

posix 消息隊列的實作有點類似與 pipe 的實作，也是自己一套 mqueue 檔案系統，然後在 inode 上的 i_private 上挂上關于消息隊列屬性 mqueue_inode_info，在這個屬性上，核心2.6時，是用一個數組存儲消息，而到了4.6則用紅黑樹了存儲消息(我下載下傳了這兩個版本，具體什麼時候開始用紅黑樹，沒深究)。

然後兩個程序每次操作都是操作這個 mqueue_inode_info 中的消息數組或者紅黑樹，實作程序通信，和這個 mqueue_inode_info 類似的還有 tmpfs 檔案系統屬性shmem_inode_info 和為epoll服務的檔案系統 eventloop,也有一個特殊屬性struct eventpoll，這個是挂在 file 結構的 private_data 等等。

說到這，可以小結下，程序空間中代碼段，資料段，動态連結庫(共享檔案映射)，mmap 共享匿名映射都存在于 cache 中，但是這些記憶體頁都有被程序引用，是以是不能釋放的，基于 tmpfs 的 ipc 程序間通信機制的生命周期是随核心，是以也是不能通過 drop_caches 釋放。

雖然上述提及的cache不能釋放，但是後面有提到，當記憶體不足時，這些記憶體是可以 swap out 的。

是以 drop_caches 能釋放的就是當從磁盤讀取檔案時的緩存頁以及某個程序将某個檔案映射到記憶體之後，程序退出，這時映射檔案的的緩存頁如果沒有被引用，也是可以被釋放的。

4.4 記憶體自動釋放方式

當系統記憶體不夠時，作業系統有一套自我整理記憶體，并盡可能的釋放記憶體機制，如果這套機制不能釋放足夠多的記憶體，那麼隻能 OOM 了。

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

第二句後半部分，

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

把一個程序記憶體使用情況，用三個屬性進行了說明，即所有虛拟記憶體，常駐記憶體匿名映射頁以及常駐記憶體檔案映射頁。

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

• 檔案映射:代碼段，資料段，動态連結庫共享存儲段以及使用者程式的檔案映射段；
• 匿名映射：bbs段，堆，以及當 malloc 用 mmap 配置設定的記憶體，還有mmap共享記憶體段；

其實核心回收記憶體就是根據檔案映射和匿名映射來進行的，在 mmzone.h 有如下定義:

LRU_UNEVICTABLE 即為不可驅逐頁 lru，我的了解就是當調用 mlock 鎖住記憶體，不讓系統 swap out 出去的頁清單。

簡單說下 linux 核心自動回收記憶體原理，核心有一個 kswapd 會周期性的檢查記憶體使用情況，如果發現空閑記憶體定于 pages_low，則 kswapd 會對 lru_list 前四個 lru 隊列進行掃描，在活躍連結清單中查找不活躍的頁，并添加不活躍連結清單。

然後再周遊不活躍連結清單，逐個進行回收釋放出32個頁，知道 free page 數量達到 pages_high，針對不同的頁，回收方式也不一樣。

當然，當記憶體水準低于某個極限門檻值時，會直接發出記憶體回收，原理和 kswapd 一樣，但是這次回收力度更大，需要回收更多的記憶體。

檔案頁：

如果是髒頁，則直接回寫進磁盤，再回收記憶體。

如果不是髒頁，則直接釋放回收，因為如果是io讀緩存，直接釋放掉，下次讀時，缺頁異常，直接到磁盤讀回來即可，如果是檔案映射頁，直接釋放掉，下次通路時，也是産生兩個缺頁異常，一次将檔案内容讀取進磁盤，另一次與程序虛拟記憶體關聯。

匿名頁：因為匿名頁沒有回寫的地方，如果釋放掉，那麼就找不到資料了，是以匿名頁的回收是采取 swap out 到磁盤，并在頁表項做個标記，下次缺頁異常在從磁盤 swap in 進記憶體。

swap 換進換出其實是很占用系統IO的，如果系統記憶體需求突然間迅速增長，那麼cpu 将被io占用，系統會卡死，導緻不能對外提供服務，是以系統提供一個參數，用于設定當進行記憶體回收時，執行回收 cache 和 swap 匿名頁的，這個參數為:

意思就是說這個值越高，越可能使用 swap 的方式回收記憶體，最大值為100，如果設為0，則盡可能使用回收 cache 的方式釋放記憶體。

5、總結

這篇文章主要是寫了 linux 記憶體管理相關的東西：

首先是回顧了程序位址空間；

其次當程序消耗大量記憶體而導緻記憶體不足時，我們可以有兩種方式：第一是手動回收 cache；另一種是系統背景線程 swapd 執行記憶體回收工作。

最後當申請的記憶體大于系統剩餘的記憶體時，這時就隻會産生 OOM，殺死程序，釋放記憶體，從這個過程，可以看出系統為了騰出足夠的記憶體，是多麼的努力啊。

- - 核心技術中文網 - 建構全國最權威的核心技術交流分享論壇

轉載位址：一文總結一些記憶體問題！ - 圈點 - 核心技術中文網 - 建構全國最權威的核心技術交流分享論壇