隨著計(jì)算機(jī)硬件的飛速發(fā)展，內(nèi)存的容量越來越大荒典，服務(wù)器從最開始的幾G到現(xiàn)在的幾百G酪劫，各大公司從來都不會(huì)在內(nèi)存上面吝嗇，因?yàn)閮?nèi)存是服務(wù)穩(wěn)定性的基礎(chǔ)寺董，為了省一點(diǎn)點(diǎn)內(nèi)存而失去服務(wù)的穩(wěn)定性覆糟，不可謂不是因小失大。所以現(xiàn)代服務(wù)程序基本上是能靠堆機(jī)器和資源解決就靠機(jī)器和資源解決遮咖。

計(jì)算機(jī)專業(yè)的同學(xué)應(yīng)該都知道操作系統(tǒng)頁置換swap的設(shè)計(jì)理念滩字，當(dāng)物理內(nèi)存不足時(shí)，會(huì)通過LRU策略將內(nèi)存中最久為使用的頁置換回磁盤的swap分區(qū)御吞，這種置換操作由于涉及到磁盤操作麦箍，因此會(huì)對(duì)性能有較大損失，所以大部分公司都會(huì)選擇關(guān)閉swap置換來防止不必要的性能損失陶珠，寧可讓服務(wù)OOM重啟也不愿由于SWAP帶來的長期性能損失(隨著分布式理念及容器化技術(shù)的成熟挟裂，服務(wù)的重啟代價(jià)越來越低)。

上述做法對(duì)于有充足內(nèi)存的進(jìn)程來說揍诽，確實(shí)沒有什么問題诀蓉，隨著容器技術(shù)的火熱栗竖，cgroup漸漸進(jìn)入我們的視野，內(nèi)存的管理粒度從全機(jī)管理細(xì)化到單cgroup管理渠啤，我們可以將一個(gè)或者一組進(jìn)程關(guān)聯(lián)到一個(gè)cgroup來管理對(duì)應(yīng)的資源狐肢，這些資源包括CPU，MEM沥曹，BLKIO份名，NETWORK，這也是我們計(jì)算機(jī)中最關(guān)心的幾種關(guān)鍵資源架专，我們針對(duì)進(jìn)程服務(wù)的穩(wěn)定性同窘、高效性調(diào)優(yōu)，基本上就是在思考如何處理好這些資源的利用部脚。有了cgroup后，我們又回到了資源緊張的時(shí)代裤纹，我們不再是隨隨便便有幾百G內(nèi)存可用了委刘，特別是容器化部署，可能分給我們?nèi)萜鱟group的內(nèi)存就1~2G鹰椒，如何精細(xì)化的管理好內(nèi)存又開始變得重要起來了锡移。

這里有一個(gè)很典型的例子可以分享一下：曾經(jīng)我剛畢業(yè)在宜信大數(shù)據(jù)做平臺(tái)工程師的時(shí)候，經(jīng)常會(huì)遇到一些GO服務(wù)或者java服務(wù)漆际，在接近內(nèi)存cgroup上限的時(shí)候淆珊，會(huì)有一段時(shí)間出現(xiàn)很高的IO read utils，基本將讀IO打滿了奸汇，但是內(nèi)存占用又達(dá)不到被OOMkiller殺掉的閾值施符，所以會(huì)有較長的時(shí)間影響整個(gè)機(jī)器的服務(wù)(整個(gè)物理/虛擬機(jī)器是共享IO的，由于IO read utils占用100%擂找，其他進(jìn)程對(duì)對(duì)應(yīng)disk有io讀請(qǐng)求時(shí)會(huì)有影響)戳吝。當(dāng)時(shí)對(duì)linux的整體機(jī)制細(xì)節(jié)了解甚微，對(duì)于這一問題的出現(xiàn)贯涎，丈二和尚摸不著頭腦听哭，內(nèi)存不足產(chǎn)生那么高的IO read是幾個(gè)意思？而且我們當(dāng)時(shí)也是禁掉了機(jī)器的swap的塘雳，通過監(jiān)控來看進(jìn)程也確實(shí)沒有產(chǎn)生swap陆盘。所以帶著這個(gè)問題我在網(wǎng)上看了很多資料，但是最終都沒有找到自己想要的答案败明，這也就讓自己產(chǎn)生了帶著這個(gè)問題去系統(tǒng)學(xué)習(xí)一下linux內(nèi)核的想法隘马，時(shí)至今日，我終于能對(duì)這個(gè)問題有比較深刻的理解了肩刃，所以在這里分享一下祟霍。

這里面涉及到到知識(shí)點(diǎn)主要包括：(后續(xù)等我有時(shí)間了會(huì)將各個(gè)部分結(jié)合內(nèi)核源碼詳細(xì)的寫一下文章杏头，目前除了虛擬文件系統(tǒng)外其他還沒寫)

1. linux虛擬內(nèi)存管理
2. linux頁面回收和頁面置換
3. cgroup memory manage
4. linux 虛擬文件系統(tǒng)
5. linux process loading so

linux虛擬內(nèi)存管理

virtual memory

linux用戶空間虛擬地址空間主要包括以下幾個(gè)方面：

1. stack區(qū)(進(jìn)程棧，從上往下分配沸呐，大小上限一般為128M)醇王。
2. mmap區(qū)(用于各種映射：private，share崭添，anonymous寓娩，是文件映射的主要區(qū)域)。
3. heap區(qū)(用于anonymous匿名映射呼渣，是用戶內(nèi)存分配的主要區(qū)域)棘伴。
4. 數(shù)據(jù)段、代碼段之類的屁置，不做詳細(xì)介紹焊夸。

這里面重點(diǎn)簡單分析一下heap及mmap：

heap

當(dāng)用戶空間可用虛擬空間不足(沒有足夠大小的連續(xù)地址塊可供分配)時(shí)，就會(huì)通過brk系統(tǒng)調(diào)用擴(kuò)大heap的堆頂?shù)刂反笮±督牵谶@個(gè)過程中阱穗，會(huì)伴隨著一個(gè)虛擬地址空間管理對(duì)象vm_area_struct(虛擬地址塊的起始地址等元信息)的創(chuàng)建，但是并沒有完成虛擬地址到物理地址的映射使鹅，只有在上層內(nèi)存管理lib malloc內(nèi)存發(fā)現(xiàn)page fault的時(shí)候才會(huì)通過匿名映射將真正的物理頁與虛擬地址進(jìn)行映射關(guān)聯(lián)揪阶，并將映射關(guān)系寫入頁表中。

當(dāng)用戶空間釋放內(nèi)存時(shí)患朱，如果釋放的虛擬地址是處于heap的非頂部鲁僚，那么就會(huì)在heap內(nèi)產(chǎn)生空洞，這里還涉及到空洞的vm_area_struct合并操作裁厅，不做詳細(xì)討論冰沙，后續(xù)內(nèi)存分配就會(huì)優(yōu)先從這些空洞中找合適的塊進(jìn)行分配，否則就進(jìn)行brk系統(tǒng)調(diào)用擴(kuò)展虛擬地址姐直。如果釋放的虛擬地址(或者合并之后)是處于heap的頂部倦淀，內(nèi)核就自動(dòng)收縮heap。

詳細(xì)信息見http://man7.org/linux/man-pages/man2/brk.2.html

其中heap堆頂?shù)刂反笮∩罚话憔褪俏覀冋f的VIRT撞叽，內(nèi)部的非空洞實(shí)際物理內(nèi)存占用會(huì)統(tǒng)計(jì)到RES中(RES還包括后續(xù)統(tǒng)計(jì)的mmap)。

mmap

內(nèi)存映射其實(shí)也是heap內(nèi)存管理的基礎(chǔ)插龄，之所以還劃分專門的mmap區(qū)愿棋，是由于文件映射及線程棧空間分配一般都會(huì)從這個(gè)區(qū)劃分均牢，這樣的劃分能夠更清晰進(jìn)行虛擬地址空間管理糠雨。mmap主要包括私有映射，共享映射及匿名映射徘跪，可以通過pmap -x #PID命令及 cat /proc/#PID/maps查看進(jìn)程mmap信息甘邀。

文件映射mmap最常見的用途主要包括：

1. 加載進(jìn)程binary文件及依賴的共享依賴庫so文件(這是上述示例產(chǎn)生的關(guān)鍵)琅攘。
2. 共享內(nèi)存IPC。
3. 內(nèi)核文件緩存映射松邪。(open file時(shí)會(huì)內(nèi)核建立page到file的映射坞琴，但是是在內(nèi)核空間)

mmap相較于write/read系統(tǒng)調(diào)用具有更高效的特點(diǎn)，減少了從用戶空間到內(nèi)核空間memory copy的操作逗抑，因此對(duì)于有些性能要求很高的IO操作可以通過mmap來做剧辐，而另外一個(gè)用于文件之間內(nèi)存零拷貝的操作我們是sendfile(該操作直接基于兩個(gè)fd在內(nèi)核層面進(jìn)行數(shù)據(jù)拷貝，不需要在用戶空間先read再write)邮府。

mmap占用的內(nèi)存也會(huì)計(jì)入RES的統(tǒng)計(jì)中荧关，其中以share方式映射的mmap內(nèi)存大小會(huì)計(jì)入SHR統(tǒng)計(jì)。

還可以通過 cat /proc/#PID/smaps查看具體的mmap統(tǒng)計(jì)信息：

7ffba85b2000-7ffba8799000 r-xp 00000000 08:06 136724                     /lib/x86_64-linux-gnu/libc-2.27.so
Size:               1948 kB // 虛擬內(nèi)存
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                 952 kB //實(shí)際內(nèi)存
Pss:                   9 kB // 使用此庫者太多褂傀，無法統(tǒng)計(jì)忍啤。 share映射按比例計(jì)算，比如有3個(gè)進(jìn)程紊服，me當(dāng)期進(jìn)程的PSS就除以3
Shared_Clean:        952 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:          952 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                9 kB // 重點(diǎn)關(guān)注檀轨，是解決上述問題的關(guān)鍵

詳細(xì)信息見http://man7.org/linux/man-pages/man2/mmap.2.html

這里有一個(gè)MAP_LOCKED的FLAG可以重點(diǎn)看一下，對(duì)應(yīng)上面的locked字段欺嗤，這個(gè)我后面會(huì)提到。

我們通過查看進(jìn)程status來分析一下各個(gè)字段：
cat /proc/$PID/status

Name:   ash
State:  S (sleeping)
Tgid:   1990
Pid:    1990
PPid:   1
TracerPid:  0
Uid:    0   0   0   0
Gid:    0   0   0   0
FDSize: 32  // 打開fd文件描述符上線
Groups: 0 
VmPeak:     1592 kB // 堆虛擬內(nèi)存占用峰值
VmSize:     1592 kB // 堆虛擬內(nèi)存大小
VmLck:         0 kB // 被lock的大小卫枝，被lock的頁無論如何都不會(huì)被換出或者釋放煎饼，通過mlock可以申請(qǐng)這種內(nèi)存
VmPin:         0 kB
VmHWM:       552 kB // 實(shí)際物理內(nèi)存大小峰值
VmRSS:       552 kB // 實(shí)際物理內(nèi)存大小
VmData:      268 kB // 數(shù)據(jù)段大小
VmStk:       136 kB // 棧大小
VmExe:       688 kB // 程序binary大小
VmLib:       472 kB // 依賴動(dòng)態(tài)共享內(nèi)存庫so大小
VmPTE:        16 kB // 頁表項(xiàng)內(nèi)存大小
VmSwap:        0 kB // swap內(nèi)存占用大小
Threads:    1
...

通過對(duì)linux虛擬內(nèi)存管理，我們可以建立兩個(gè)信息：這也是解釋上述案例的關(guān)鍵

1. 對(duì)于應(yīng)用程序本身內(nèi)存分配是通過mmap匿名映射分配的校赤。沒有后備存儲(chǔ)介質(zhì)
2. 對(duì)于動(dòng)態(tài)依賴共享庫是通過mmap私有或者共享映射加載的吆玖。存在后備存儲(chǔ)介質(zhì)

有了上述兩個(gè)信息后我們繼續(xù)來看linux回收和頁置換，也就是我們標(biāo)題中提到的swap马篮。

頁回收和頁置換

在最早期的linux版本中沾乘，在內(nèi)存不足時(shí)會(huì)置換整個(gè)進(jìn)程，如果這樣做的話浑测，上下文切換代價(jià)加大翅阵，性能特別差，所以就產(chǎn)生了一種機(jī)制迁央，當(dāng)內(nèi)存吃緊時(shí)掷匠，只置換進(jìn)程中的一些頁。

所以內(nèi)核就需要一個(gè)機(jī)制來判斷具體回收哪些頁才能保證效率高而且不用頻繁的回收和加載頁岖圈，這里就要介紹一下LRU(latest recently used)算法讹语，通過歷史演推未來，過去不咋使用的頁在未來使用的概率也相對(duì)可能性較低蜂科。LRU的基本原理簡單顽决，但是其復(fù)雜性對(duì)于內(nèi)核來說還是太重了(需要處理大量的數(shù)據(jù)結(jié)構(gòu))短条，所以需要一種更加簡單的機(jī)制來代替原始實(shí)現(xiàn)，而且這個(gè)值不需要太過精確才菠。

內(nèi)核為了簡化LRU的邏輯茸时，提供了一種類似于二次復(fù)活的策略，來近似模擬LRU鸠儿，通過兩個(gè)FLAG來判斷一個(gè)頁是否可以被回收屹蚊，這兩個(gè)FLAG分別稱為ACTIVE位及REFERENCE位。標(biāo)志著四種狀態(tài)：

1. unreferenced & unactive // 很久沒被訪問
2. referenced & unactive // 之前不活躍进每，但是最近被訪問了一次
3. unreferenced & active // 之前活躍汹粤，但是最近一次掃描未被訪問
4. referenced & active // 之前活躍，最近也被訪問了
   linux將物理內(nèi)存頁放入到兩大類列表中管理：inactive和active田晚，當(dāng)物理內(nèi)存達(dá)到一定閾值時(shí)嘱兼，將inactive中的內(nèi)存頁進(jìn)行回收或者置換。

具體狀態(tài)轉(zhuǎn)移見下圖：

state graph

kswapd定期掃描內(nèi)存中所有已分配的物理頁贤徒，調(diào)用page_referenced芹壕，如果已標(biāo)記為unreferenced，則將對(duì)應(yīng)頁標(biāo)記為unactive接奈，如果之前是active的踢涌，則通過shrink_active_list將其放回到inactive隊(duì)列；如果之前是referenced序宦，則置為unreferenced睁壁。
當(dāng)一個(gè)頁被訪問時(shí)，就會(huì)調(diào)用mark_page_accessed互捌，如果已標(biāo)記為referenced潘明，則標(biāo)記為active，如果之前是inactive的秕噪，則通過active_page將其放入active隊(duì)列钳降；如果之前是unreferenced，則置為referenced腌巾。
通過上述狀態(tài)轉(zhuǎn)移可以清晰的獲知一個(gè)頁如果被認(rèn)為可回收的話就是兩次連續(xù)掃描內(nèi)沒有訪問遂填，而一個(gè)進(jìn)入inactive隊(duì)列的頁要想被當(dāng)做active必須在一個(gè)掃描周期內(nèi)連續(xù)訪問兩次以上。

為了更好的區(qū)分對(duì)于緩存的訪問以及進(jìn)程內(nèi)部的內(nèi)存使用壤躲，linux又將內(nèi)存lru隊(duì)列細(xì)分為inactive_anon城菊，active_anon，inactive_file碉克，active_file四類凌唬，另外還有一類unevictable(被lock住不能置換的頁)，具體見如下：

enum lru_list {
    LRU_INACTIVE_ANON = LRU_BASE,
    LRU_ACTIVE_ANON = LRU_BASE + LRU_ACTIVE,
    LRU_INACTIVE_FILE = LRU_BASE + LRU_FILE,
    LRU_ACTIVE_FILE = LRU_BASE + LRU_FILE + LRU_ACTIVE,
    LRU_UNEVICTABLE,
    NR_LRU_LISTS
};

一般來說我們禁掉swap只會(huì)禁掉對(duì)于匿名映射的置換回收，而對(duì)于文件映射相關(guān)的訪問我們得必須能夠置換回收客税，因?yàn)閮?nèi)核文件緩存內(nèi)存訪問是屬于這一類的况褪，如果禁掉文件映射內(nèi)存回收，那么緩存機(jī)制將不能很好的工作更耻，Linux會(huì)在內(nèi)存充足時(shí)將大力的內(nèi)存用于文件緩存测垛，如果這一部分不能被置換回收，那么可用空間將會(huì)變得少的可憐秧均，而禁用文件緩存將會(huì)極大降低linux文件訪問性能食侮。一般做法都是通過禁掉swap文件分區(qū)來禁掉匿名映射的內(nèi)存置換策略。

內(nèi)存回收的時(shí)機(jī)

搞清楚了內(nèi)存回收選擇的內(nèi)存頁P(yáng)age的策略后目胡，那么內(nèi)核是什么時(shí)候來觸發(fā)頁面的真正回收呢锯七？

1. 這里就要介紹一下kswapd，它會(huì)定期掃描各個(gè)NUMA下內(nèi)存節(jié)點(diǎn)pglist_data中的所有mem_cgroup內(nèi)存分配情況誉己。每個(gè)Page會(huì)關(guān)聯(lián)到一個(gè)mem_cgroup對(duì)象眉尸，page的分配和釋放都會(huì)更新mem_cgroup中的usage(內(nèi)存分配總量anon+file)信息，當(dāng)mem_cgroup的內(nèi)存使用usage達(dá)到mem_cgroup的min值則認(rèn)為無藥可救巨双，不管了噪猾，否則通過shrink_list操作進(jìn)行標(biāo)記和隊(duì)列移動(dòng)，并在結(jié)尾時(shí)回收掉inactive隊(duì)列中的內(nèi)存頁筑累。
2. 還有一種情況就是當(dāng)內(nèi)存比較緊張時(shí)袱蜡，內(nèi)核檢測(cè)到某個(gè)操作期間內(nèi)存嚴(yán)重不足，將調(diào)用try_to_free_pages慢宗，該函數(shù)檢查當(dāng)前內(nèi)存域zone(存在一個(gè)內(nèi)存節(jié)點(diǎn)中)所有頁戒劫，并釋放最不常用的那些，其釋放內(nèi)存的原理和機(jī)制和kswapd的做法一致婆廊，唯一不同的是kswapd會(huì)掃描節(jié)點(diǎn)中的所有域zone。

問題分析

現(xiàn)在對(duì)于linux的一些機(jī)制有了大致的了解了巫橄，那就來分析一下之前描述的場景淘邻，為啥當(dāng)內(nèi)存接近c(diǎn)group上限，離被OOMkiller殺掉還存在一點(diǎn)距離時(shí)湘换，為何會(huì)產(chǎn)生大量的io read宾舅？
想必大家結(jié)合之前的描述可能一定的見解了：

1. 進(jìn)程通過私有映射加載進(jìn)程binary及依賴共享庫，這些處于active_file lru list中
2. 進(jìn)程正常分配內(nèi)存或者程序bug終于達(dá)到了一個(gè)閾值彩倚，內(nèi)核檢測(cè)到內(nèi)存不足筹我，但是沒達(dá)到被OOMkiller殺掉的條件，此時(shí)內(nèi)核嘗試通過調(diào)用try_to_free_pages嘗試釋放最近不常使用的頁帆离。
3. 由于關(guān)閉了swap蔬蕊，inactive_anon沒有后備device可供寫回，那么可供回收的內(nèi)存頁就只能是inactive_file哥谷，也就是我們依賴通過private mmap方式加載的so共享依賴庫岸夯。
4. 由于內(nèi)存不足麻献，try_to_free_pages調(diào)用會(huì)比較頻繁，那么active_file中的page有更大的概率被認(rèn)為是inactive(具體見上述回收頁選擇策略)猜扮，這樣就會(huì)回收掉so相關(guān)的頁勉吻。
5. 然而真實(shí)情況是so中的數(shù)據(jù)隨著代碼的執(zhí)行是比較被常訪問的頁，因此又需要從文件中加載回內(nèi)存旅赢。
6. 這樣就形成了一個(gè)惡性循環(huán)齿桃，導(dǎo)致當(dāng)內(nèi)存在趨近OOM的時(shí)候會(huì)出現(xiàn)一個(gè)特別惡心的中間狀態(tài)，我們稱之為頁顛簸煮盼。

問題解決

那么有沒有什么好的方式來解決這個(gè)問題呢短纵？
首先，需要討論一下在內(nèi)存充裕的今天孕似，關(guān)閉swap是否是一個(gè)明智之舉踩娘，這個(gè)我覺得得具體問題具體分析，swap不是一個(gè)簡單的extra memory喉祭，而是對(duì)于內(nèi)存使用率的一種優(yōu)化策略养渴，將內(nèi)存中的低頻內(nèi)存置換出去，這樣對(duì)于伙伴系統(tǒng)泛烙，文件緩存系統(tǒng)的管理也是比較友好的理卑，對(duì)于資源利用率也是一種很不錯(cuò)的策略。但他確實(shí)也存在一些弊端蔽氨，后備swap device訪問的低效性藐唠，如果出現(xiàn)頁顛簸時(shí)產(chǎn)生的影響是不可忽視的，所以是否采用swap得針對(duì)不同的進(jìn)程做不同的分析鹉究。
對(duì)于IO密集型的進(jìn)程宇立，真正活躍內(nèi)存其實(shí)比較少，大量時(shí)間都是在等IO自赔，所以其內(nèi)部的不常訪問的內(nèi)存完全可以先置換到磁盤里面妈嘹。而且這類應(yīng)用對(duì)于性能要求并沒有那么高。
對(duì)于計(jì)算密集型的進(jìn)程绍妨，內(nèi)存大部分時(shí)間是活躍的润脸，如果置換回磁盤的話，很快就可能要被置換回他去，大大影響了性能毙驯。

如果有人覺得：我們公司就是有錢，內(nèi)存這點(diǎn)資源完全不在話下灾测，當(dāng)出現(xiàn)接近OOM的時(shí)候肯定是程序BUG了直接重啟好了爆价，讓他快速被殺掉重新啟動(dòng)是一種更好的做法，那么有沒有在禁掉swap的情況下，避免出現(xiàn)之前提到的那種由于so共享內(nèi)存庫的頁面回收導(dǎo)致的頁顛簸情況呢允坚？
這里我們就要提一下之前介紹mmap的時(shí)候提到的MAP_LOCKED FLAG魂那，這個(gè)FLAG的語義就是鎖定被分配的PAGE內(nèi)存頁，使其無法被置換稠项，通過這樣方式被mmap的頁就不能被回收了涯雅，這樣當(dāng)內(nèi)存不足時(shí)，不會(huì)回收該頁展运，這樣就不會(huì)產(chǎn)生頁顛簸活逆，如果內(nèi)存不足直接將進(jìn)程kill重啟就好了。

那么我們這里有一種思路就是希望進(jìn)程在加載so的時(shí)候拗胜，將加載so對(duì)應(yīng)的物理內(nèi)存頁鎖定蔗候，這樣對(duì)應(yīng)的頁就不能被換出了，但是查找了很多資料以及閱讀dlopen dlsym官方文檔相關(guān)參數(shù)都沒有設(shè)lock相關(guān)的參數(shù)埂软，因此這條路似乎走不通锈遥。

目前我能想到的方法就是通過mlockall系統(tǒng)將所有的內(nèi)存頁都鎖住，使其無法被swap out勘畔，這也是ES 中一種禁止swap策略的一種所灸。
具體做法就是：
在進(jìn)程啟動(dòng)的main函數(shù)最開始調(diào)用一把mlockall with MCL_CURRENT | MCL_FUTURE ，這樣已經(jīng)分配以及后續(xù)分配的所有內(nèi)存都會(huì)被lock住炫七，其實(shí)就跟禁用了swap一樣一樣的爬立。具體可以見例子
關(guān)于mlock，可以看看這篇文章万哪，這篇文章里面的很多內(nèi)容我覺得過時(shí)了侠驯，我覺得mlock并沒有那么恐怖，我們目前關(guān)swap的做法其實(shí)跟mlock沒啥差別奕巍，這么多公司不都用的好好的嗎吟策，不過他也有他的考慮。
如果是平臺(tái)方想要一種更通用的方式的止，比如基于docker的pass平臺(tái)可以將docker container entry的cmd指定為一個(gè)shell踊挠，shell上調(diào)用mlockall系統(tǒng)調(diào)用然后execv到真正的進(jìn)程程序。(這只是我的個(gè)人思路哈冲杀，沒測(cè)試)

總結(jié)

swap存在肯定有其存在的道理，一股腦的禁掉swap睹酌，并不是一個(gè)特別明智合理的處理方式权谁，對(duì)于很多公司來說基本上都是一些web服務(wù)，基本都是io密集型應(yīng)用憋沿，禁掉swap并沒有太多收益旺芽，相反如果不lock住so加載時(shí)的mmap內(nèi)存，還會(huì)出現(xiàn)頁顛簸的場景出現(xiàn)〔烧拢總而言之运嗜，盡量不要禁掉swap，如果選擇禁用掉swap悯舟，就得想辦法用mlockall鎖定當(dāng)前進(jìn)程的其他內(nèi)存分配担租，以防止由于private file映射出現(xiàn)的頁顛簸。