Linux內(nèi)存管理優(yōu)化:面向低延遲/高吞吐量數(shù)據(jù)庫GraphDB
譯文【2013年10月11日 51CTO外電頭條】本文將 LinkedIn 工程師 Apurva Mehta 在 Blog 上分享的《面向低延遲/高吞吐量數(shù)據(jù)庫（GraphDB）的 Linux 內(nèi)存管理優(yōu)化》做了簡單的翻譯整理，希望對大家有所幫助。
簡介
GraphDB在LinkedIn的實(shí)時(shí)分布式社交圖譜服務(wù)當(dāng)中充當(dāng)著存儲層的角色。我們的服務(wù)旨在處理簡單查詢（例如來自LinkedIn成員的一級與二級網(wǎng)絡(luò)請求）與復(fù)雜查詢（例如成員之間的距離以及成員之間的關(guān)聯(lián)路徑等圖譜結(jié)果）。我們支持多種節(jié)點(diǎn)及邊界類型，而且能夠直接處理所有正處于執(zhí)行當(dāng)中的查詢。感興趣的朋友不妨點(diǎn)擊此處的博文，對應(yīng)用程序使用我們社交圖譜的方式進(jìn)行初步了解。
LinkedIn上的每一個(gè)頁面視圖都會產(chǎn)生多條指向GraphDB的查詢請求。這意味著GraphDB每秒鐘都要處理成千上萬條查詢請求，而且99%的查詢都能在微秒級別的延遲之內(nèi)得到響應(yīng)（通常延遲為十幾微秒）。有鑒于此，即使GraphDB的響應(yīng)延遲提高到僅僅5毫秒，LinkedIn的全局訪問效果也將受到嚴(yán)重影響。
在2013年的大部分時(shí)段，我們已經(jīng)發(fā)現(xiàn)GraphDB會在使用高峰當(dāng)中偶爾出現(xiàn)間歇性響應(yīng)延遲。我們深入調(diào)查了這些高峰時(shí)段，并努力了解Linux內(nèi)核如何管理NUMA（即非統(tǒng)一內(nèi)存訪問）系統(tǒng)上的虛擬內(nèi)存。概括來說，針對NUMA的一部分Linux優(yōu)化存在嚴(yán)重的負(fù)面作用，會因此對延遲產(chǎn)生直接性不利影響。我們認(rèn)為此次研究的成果足以幫助任何一套運(yùn)行在Linux系統(tǒng)環(huán)境下、對延遲要求較高的在線數(shù)據(jù)庫系統(tǒng)獲得性能改進(jìn)。經(jīng)過我們的優(yōu)化調(diào)整，問題出現(xiàn)幾率（例如響應(yīng)緩慢或者查詢超時(shí)的出現(xiàn)比例）已經(jīng)下降到原先的四分之一。
在文章的***部分，我們將共同了解相關(guān)背景資料，包括：GraphDB在數(shù)據(jù)管理方面的流程大綱、性能問題的具體表現(xiàn)以及Linux虛擬內(nèi)存管理（簡稱VMM）子系統(tǒng)的運(yùn)作方式。在文章的第二部分，我們將詳細(xì)探討解決辦法、指導(dǎo)意見以及結(jié)論匯總，旨在通過實(shí)驗(yàn)找到問題出現(xiàn)的根源。***，我們將歸納通過此次實(shí)例所獲得的經(jīng)驗(yàn)。
本文適合對操作系統(tǒng)運(yùn)行機(jī)制具備一定了解的朋友。
背景資料
1) GraphDB如何管理數(shù)據(jù)
GraphDB在本質(zhì)上是一種內(nèi)存內(nèi)數(shù)據(jù)庫。在讀取方面，我們將所有數(shù)據(jù)文件映射到虛擬內(nèi)存頁面當(dāng)中，并始終將其保留在內(nèi)存中的活動集之下。我們的讀取活動具備很強(qiáng)的隨機(jī)性，指向目標(biāo)遍布整個(gè)數(shù)據(jù)集，且99%的請求都要求將延遲控制在微秒級別。一臺典型的GraphDB主機(jī)能夠擁有48GB物理內(nèi)存，常用內(nèi)存量為20GB：其中15GB用于處理堆外虛擬內(nèi)存頁面映射數(shù)據(jù)，5GB用于JVM堆。
而在寫入方面，我們擁有一套日志-結(jié)構(gòu)化存儲系統(tǒng)。我們將全部數(shù)據(jù)劃分為以10MB為單位的純追加部分。目前，每一臺GraphDB主機(jī)大約擁有1500個(gè)活動部分，其中只有25個(gè)能夠隨時(shí)接受寫入操作，其它1475個(gè)則處于只讀狀態(tài)。
由于數(shù)據(jù)采用日志結(jié)構(gòu)化存儲方式，我們需要定期對其進(jìn)行壓縮。此外，由于我們所采取的壓縮計(jì)劃比較積極，因此每天每臺主機(jī)上約有九百個(gè)數(shù)據(jù)片段會被遺棄。換言之，每天每臺主機(jī)上約有容量達(dá)9GB的數(shù)據(jù)文件徹底消失，但這還僅僅是LinkedIn全局?jǐn)?shù)據(jù)增量中的一小部分。概括來講，每臺48GB主機(jī)在運(yùn)行五天之后頁面緩存就會被垃圾堆滿。
2) 問題癥狀
我們所遇到的性能問題主要表現(xiàn)為在使用高峰期GraphDB出現(xiàn)響應(yīng)延遲。在高峰期出現(xiàn)的同時(shí)，我們往往會面臨數(shù)量龐大的直接頁面掃描以及內(nèi)存執(zhí)行效率低下等困擾，具體情況如sar所示。在個(gè)別情況下，sar -B 下"每秒pqsand（pqscand/s）"列的輸出效率將拖慢至每秒100萬到500萬頁面掃描，虛擬內(nèi)存效率也會降至0%--這些癥狀往往會持續(xù)數(shù)小時(shí)。
在性能表現(xiàn)急劇下滑的過程中，系統(tǒng)的內(nèi)存壓力卻并不明顯：這是因?yàn)槲覀兛梢酝ㄟ^/proc/meminfo的記錄看到大量無效緩存頁面。此外，并不是pqscand/s中的所有高峰時(shí)段都會引發(fā)GraphDB的延遲問題。
最讓我們感到困惑的兩個(gè)問題是：
1、如果系統(tǒng)中不存在明顯的內(nèi)存壓力，為什么系統(tǒng)內(nèi)核會對頁面進(jìn)行掃描？
2、即使內(nèi)核開始對頁面進(jìn)行掃描，為什么我們的響應(yīng)延遲會急劇升高？只有寫入線程需要占用新的內(nèi)存分配，而且寫入與讀取線程池是彼此獨(dú)立的。因此，為什么實(shí)際結(jié)果是雙方會相互產(chǎn)生影響？
正是這些問題的答案促使我們對NUMA系統(tǒng)的Linux優(yōu)化方案做出調(diào)整。需要強(qiáng)調(diào)的是，我們最終將注意力集中在了Linux的"區(qū)回收（zone reclaim）"功能方面。如果大家對于NUMA、Linux以及區(qū)回收不太了解，別擔(dān)心，我們會在下一部分內(nèi)容中做出詳細(xì)講解。在這些資料的輔助下，大家應(yīng)該可以順利理解文章其它部分的論證過程。
3) 關(guān)于Linux、NUMA以及區(qū)回收的那些事兒
要想深入理解問題產(chǎn)生的根源，我們首先需要明確Linux系統(tǒng)如何處理NUMA架構(gòu)。我為大家甄選了一部分優(yōu)秀的講解資源，希望能幫助各位快速掌握相關(guān)的背景知識：
- Jeff Frost：《Linux中的PostgreSQL、NUMA以及區(qū)回收模式》 。 如果大家時(shí)間有限，優(yōu)先推薦各位閱讀這篇文章。
- Christoph Lameter：《非統(tǒng)一內(nèi)存訪問概述》。大家需要著重閱讀其中關(guān)于Linux如何從NUMA區(qū)中回收內(nèi)存的部分。
- Jeremy Cole：《MySQL“交換錯(cuò)亂”問題以及NUMA架構(gòu)的影響》。
同樣重要的是，大家需要理解Linux從頁面緩存中使用回收頁面的具體機(jī)制。
簡而言之，Linux為每個(gè)NUMA區(qū)保留著一組三個(gè)頁面列表：活動列表、非活動列表以及空閑列表。新頁面進(jìn)行分配時(shí)會被從空閑列表轉(zhuǎn)移到活動列表。而LRU算法則負(fù)責(zé)將頁面從活動列表轉(zhuǎn)移到非活動列表，而后再由非活動列表轉(zhuǎn)移至空閑列表。下面我為大家推薦一份學(xué)習(xí)Linux頁面緩存管理知識的***資料：
- Mel Gorman: 《了解Linux虛擬內(nèi)存管理器》，第十三章：頁面回收。
我們首先認(rèn)真閱讀了上述資料，而后嘗試關(guān)閉掉生產(chǎn)主機(jī)上的區(qū)回收模式。關(guān)閉之后，我們的性能表現(xiàn)立刻獲得顯著提升。有鑒于此，我們決定在本文中詳細(xì)描述區(qū)回收的運(yùn)作機(jī)制以及對性能造成影響的原因。
本文的其它內(nèi)容深入探討了Linux區(qū)回收的相關(guān)內(nèi)容，如果大家對區(qū)回收還不太熟悉，請首先閱讀前文推薦的Jeff Frost的相關(guān)論述。
重現(xiàn)并理解Linux的區(qū)回收活動
1) 設(shè)置實(shí)驗(yàn)環(huán)境
為了理解區(qū)回收的觸發(fā)原理以及區(qū)回收如何影響性能表現(xiàn)，我們編寫了一款程序，用于模擬GraphDB的讀取與寫入活動。我們以二十四小時(shí)為期限運(yùn)行該程序，在前面十七個(gè)小時(shí)內(nèi)、我們開啟了區(qū)回收模式。而在***七個(gè)小時(shí)中，我們關(guān)閉了區(qū)回收模式。該程序在整個(gè)二十四小時(shí)當(dāng)中不間斷地運(yùn)行，環(huán)境中的惟一變化就是在第十七小時(shí)通過向/proc/sys/vm/zone_reclaim_mode中寫入"0"來禁用區(qū)回收。
下面我們來解讀該程序的運(yùn)行內(nèi)容：
1、它將2500個(gè)10MB數(shù)據(jù)文件映射至頁面緩存當(dāng)中，全部讀取一遍，而后取消映射，這樣Linux頁面緩存當(dāng)中就充斥著垃圾數(shù)據(jù)。如此一來，系統(tǒng)的運(yùn)行狀態(tài)類似于GraphDB主機(jī)在正常運(yùn)行數(shù)天后的情況。
2、一組讀取線程會將另一組2500個(gè)10MB文件映射至頁面緩存當(dāng)中，再隨機(jī)讀取其中的一部分內(nèi)容。這2500個(gè)文件構(gòu)成了活動集合，用于模擬GraphDB在日常使用中的讀取狀態(tài)。
3、一組寫入進(jìn)程不斷創(chuàng)建10MB文件。一旦某個(gè)文件創(chuàng)建完成，寫入線程就會從活動集合中隨機(jī)挑選一個(gè)文件、取消其映射并用剛剛創(chuàng)建的新文件加以取代。這一過程旨在模擬GraphDB在日常使用中的寫入活動。
4、***，如果讀取線程完成讀取所消耗的時(shí)間超過100毫秒，則自動輸出該次訪問流程的usr、sys以及elapsed time。這使我們得以成功追蹤到讀取性能的變化軌跡。
我們用于運(yùn)行該程序的主機(jī)擁有48GB物理內(nèi)存。我們的工作組大約占用了其中的25GB，除此之外系統(tǒng)中沒有運(yùn)行其它任何任務(wù)。通過這種方式，我們保證主機(jī)不會遇到任何形式的內(nèi)存壓力。
大家可以點(diǎn)擊此處在Github上查看我們的模擬流程。
2) 了解區(qū)回收機(jī)制如何被觸發(fā)
當(dāng)某個(gè)進(jìn)程針對頁面發(fā)出請求時(shí)，系統(tǒng)內(nèi)核會首先檢查***NUMA區(qū)是否擁有足夠的空余內(nèi)存以及是否存在1%以上可以回收的頁面。這一百分比可以調(diào)節(jié)，并由vm.min_unmapped_ratio sysctl來決定。可回收頁面屬于由文件支持的頁面（即與頁面緩存存在映射關(guān)系的文件所產(chǎn)生的頁面），但其目前并未被映射到任何進(jìn)程當(dāng)中。在/proc/meminfo中，我們可以很清楚地看到，所謂"可回收頁面（reclaimable pages）"就是那些"活動（文件）-非活動（文件）-被映射"（Active(file)+Inactive(file)-Mapped）的內(nèi)容。
那么系統(tǒng)內(nèi)核如何判斷多少空閑內(nèi)存才夠用呢？內(nèi)存會使用區(qū)"水平標(biāo)記（watermarks）"，通過/proc/sys/vm/min_free_kbytes 中的值來進(jìn)行判斷。它們同時(shí)也會檢查/proc/sys/vm/lowmem_reserve_ratio 中的值。特定主機(jī)內(nèi)經(jīng)過計(jì)算的值會被保存在/proc/zoneinfo 當(dāng)中，并搭配如下所示的"低/中/高（low/min/high）"標(biāo)簽：
- Node 1, zone Normal
- pages free 17353
- min 11284
- low 14105
- high 16926
- scanned 0
- spanned 6291456
- present 6205440
內(nèi)存會在區(qū)內(nèi)空閑頁面數(shù)量低于水平標(biāo)記時(shí)執(zhí)行頁面回收。而當(dāng)空閑頁面的數(shù)量高于"低"水平標(biāo)記后，頁面回收操作就會中止。此外，這一計(jì)算過程針對的是各獨(dú)立區(qū)：即使其它區(qū)仍擁有足夠的空閑內(nèi)存，只要當(dāng)前區(qū)被觸發(fā)，回收機(jī)制就會付諸實(shí)施。
下面我們通過圖表來展示實(shí)驗(yàn)過程中的活動表現(xiàn)。其中值得注意的包括以下幾點(diǎn)：
- 黑色線條代表區(qū)中的頁面掃描，并以右側(cè)的y軸為基準(zhǔn)生成圖形。
- 紅色線條代表區(qū)中的空閑頁面數(shù)量。
- 綠色線條代表的是"低"水平標(biāo)記。
通過實(shí)驗(yàn)，我們觀察到了與生產(chǎn)主機(jī)類似的表現(xiàn)。在所有情況下，頁面掃描情況都與空閑頁面情況保持吻合--二者的數(shù)值恰好相反。換句話來說，Linux會在空閑頁面數(shù)量低于"低"水平標(biāo)記時(shí)觸發(fā)區(qū)回收機(jī)制。
3) 系統(tǒng)區(qū)回收機(jī)制的特性
理解了區(qū)回收模式的觸發(fā)原理，下面我們將關(guān)注重點(diǎn)放在其它方面--區(qū)回收模式如何影響性能表現(xiàn)。為了實(shí)現(xiàn)這一目標(biāo)，我們在實(shí)驗(yàn)過程中每秒一次收集來自下列源的信息：
- /proc/zoneinfo
- /proc/vmstat
- /proc/meminfo
- numactl -H
在根據(jù)這些文件中的數(shù)據(jù)繪制圖表并總結(jié)活動模式后，我們發(fā)現(xiàn)了一些非常有趣的特性--這些特性正是解答區(qū)回收機(jī)制對讀取性能產(chǎn)生負(fù)面影響的關(guān)鍵所在。
在前期觀察中，區(qū)回收機(jī)制處于啟用狀態(tài)，這時(shí)Linux執(zhí)行的大多是直接回收（即回收任務(wù)在應(yīng)用程序線程內(nèi)直接執(zhí)行，并被計(jì)作直接頁面掃描）。一旦區(qū)回收模式被關(guān)閉，直接回收活動立刻停止，但由kswapd執(zhí)行的回收數(shù)量卻開始增加。這就解釋了我們?yōu)楹螘趕ar中觀察到每秒pqscand如此之高：
其次，即使我們的讀取與寫入操作并未發(fā)生變化，Linux活動與非活動列表內(nèi)的頁面數(shù)量也在區(qū)回收模式關(guān)閉后發(fā)生了顯著變化。需要強(qiáng)調(diào)的是，在區(qū)回收機(jī)制的開啟時(shí)，Linux會在活動列表中保留總大小約20GB的頁面信息。而在區(qū)回收機(jī)制關(guān)閉后，Linux在活動列表內(nèi)的信息保留量增加到約25GB，這正是我們整個(gè)工作集的大小：
***，我們觀察到在區(qū)回收模式被關(guān)閉后，頁面內(nèi)活動出現(xiàn)了顯著差別。值得關(guān)注的一點(diǎn)在于，雖然從頁面緩存到磁盤駐留的速率保持不變，但區(qū)回收被關(guān)閉后從磁盤駐留到頁面內(nèi)的速率顯著降低。主要故障率的變動情況與頁面內(nèi)傳輸速率完全一致。下面的圖表證明了這一結(jié)論：
***，我們發(fā)現(xiàn)程序中的高占用內(nèi)存訪問活動的數(shù)量在區(qū)回收模式被關(guān)閉后大幅減少。以下圖表顯示了內(nèi)存訪問延遲（單位為毫秒）以及響應(yīng)時(shí)間在系統(tǒng)及用戶CPU層面的具體消耗?？梢钥吹剑摮绦虻拇蟛糠诌\(yùn)行時(shí)間被消耗在了I/O等待方面，而且偶爾還會在系統(tǒng)CPU當(dāng)中遭遇阻塞。
4) 區(qū)回收模式如何影響讀取性能
基于以上統(tǒng)計(jì)結(jié)果，看起來由區(qū)回收所觸發(fā)的直接回收途徑似乎在將頁面從活動列表中移除并轉(zhuǎn)移到非活動列表方面表現(xiàn)得太過激進(jìn)。特別是在區(qū)回收機(jī)制啟用時(shí)，活動頁面似乎會被直接清盤并被塞進(jìn)非活動列表，而后再被移出到空閑列表當(dāng)中。有鑒于此，讀取活動會遭遇極高的主要故障機(jī)率，性能表現(xiàn)也變得一落千丈。
導(dǎo)致問題進(jìn)一步加劇的則是shrink_inactive_list函數(shù)，作為直接回收路徑的組成部分、它似乎在區(qū)中采用了一種全局自旋鎖，從而阻止其它線程在回收過程中對區(qū)產(chǎn)生修改。正因?yàn)槿绱?，我們才會在高峰時(shí)段發(fā)現(xiàn)系統(tǒng)CPU在讀取線程中出現(xiàn)鎖定，這很可能是因?yàn)槎鄠€(gè)線程之間存在沖突。
NUMA內(nèi)存平衡機(jī)制同樣會觸發(fā)直接頁面掃描
我們剛剛了解了區(qū)回收模式如何觸發(fā)直接頁面掃描，也證實(shí)了這類將頁面數(shù)據(jù)擠出活動列表的粗暴掃描正是讀取性能下滑的罪魁禍?zhǔn)住３藚^(qū)回收之外，我們還發(fā)現(xiàn)一項(xiàng)名為Transparent HugePages （簡稱THP）的紅帽Linux功能在對NUMA區(qū)進(jìn)行內(nèi)存"平衡調(diào)整"時(shí)同樣會觸發(fā)直接頁面掃描。
在THP功能的推動下，系統(tǒng)會以透明化方式為匿名（即非文件支持）內(nèi)存分配2MB"大型頁面"。這種做法能夠提高TLB中的命中率并降低系統(tǒng)中頁面列表的大小。紅帽方面表示，THP在特定工作負(fù)載中能夠帶來高達(dá)10%的性能提升。
另外，由于這項(xiàng)功能以透明化方式運(yùn)作，因此它還利用一部分代碼將大型頁面分割成多個(gè)常規(guī)頁面（在/proc/vmsat中被統(tǒng)計(jì)為thp_split），或者將多個(gè)常規(guī)頁面匯聚成巨大頁面（被統(tǒng)計(jì)為thp_collapse）。
我們已經(jīng)看到，即使區(qū)中不存在內(nèi)存壓力，thp_split仍然會導(dǎo)致很高的直接頁面掃描比率。我們還發(fā)現(xiàn)Linux系統(tǒng)會將我們的5GB Java堆分割成巨大頁面，從而將其在不同NUMA區(qū)之間進(jìn)行移動。大家請看如下圖表：總大小約5GB、來自兩個(gè)NUMA區(qū)的數(shù)據(jù)被分割成巨大頁面，其中一部分被從Node 1移動到了Node 0。這類活動必然會帶來很高的直接頁面掃描比率。
我們無法在自己的實(shí)驗(yàn)環(huán)境下重現(xiàn)這一狀況，而且這似乎也不能算是導(dǎo)致直接頁面掃描的常見原因。不過我們手中有大量數(shù)據(jù)可以證明，Transparent HugePages功能與NUMA系統(tǒng)的協(xié)作效果并不理想，因此我們決定在自己的RHEL設(shè)備上運(yùn)行下列命令來禁用該功能。
- echo never > /sys/kernel/mm/transparent_hugepage/enabled
經(jīng)驗(yàn)教訓(xùn)
1) Linux的NUMA優(yōu)化對于典型數(shù)據(jù)庫負(fù)載并無意義
數(shù)據(jù)庫的主要性能提升源自在內(nèi)存中對大量數(shù)據(jù)進(jìn)行緩存處理，而NUMA優(yōu)化并不能做到這一點(diǎn)。需要強(qiáng)調(diào)的是，利用內(nèi)存緩存規(guī)避磁盤讀寫所節(jié)約的時(shí)間要遠(yuǎn)遠(yuǎn)超過將內(nèi)存接入多插槽系統(tǒng)中特定插槽所換來的延遲改進(jìn)。
Linux的NUMA優(yōu)化機(jī)制可以通過以下幾種方式禁用，從而提高性能表現(xiàn)：
- 關(guān)閉區(qū)回收模式:向 /etc/sysctl.conf 中添加vm.zone_reclaim_mode = 0并運(yùn)行sysctl -p以載入新設(shè)定。
- 為自己的應(yīng)用程序啟用NUMA交叉存取功能: 在運(yùn)行應(yīng)用時(shí)加入numactl --interleave=all 命令。
以上兩種設(shè)置已經(jīng)成為我們?nèi)可a(chǎn)系統(tǒng)中的默認(rèn)狀態(tài)。
2) 不要對Linux設(shè)置掉以輕心：親手管理頁面緩存中的垃圾內(nèi)容
由于GraphDB的日志結(jié)構(gòu)化存儲系統(tǒng)無法重新使用其數(shù)據(jù)片段，因此承受著時(shí)間的推移我們在Linux頁面緩存中產(chǎn)生了大量垃圾內(nèi)容。事實(shí)證明，Linux在正確清理這類垃圾內(nèi)容時(shí)表現(xiàn)得相當(dāng)糟糕：它通常會不由分說地把一切數(shù)據(jù)扔進(jìn)廢紙簍，這種過分激進(jìn)的處理方式令我們的讀取性能遭遇極高的主要故障比率。直接回收與kswapd都起到了助紂為虐的作用，但前者的負(fù)面作用更為明顯。
我們已經(jīng)為自己的存儲系統(tǒng)添加了片段池，這樣我們就能夠重復(fù)使用這些片段。通過這種方式，我們降低了需要?jiǎng)?chuàng)建的文件數(shù)量，同時(shí)減小了對Linux頁面緩存造成的處理壓力。通過初步測試，我們發(fā)現(xiàn)片段池機(jī)制帶來了令人鼓舞的出色效果。
寫在***的話
自從對區(qū)回收機(jī)制產(chǎn)生懷疑，我們就立即著手在生產(chǎn)系統(tǒng)中關(guān)閉這一模式。事實(shí)證明，我們的調(diào)整帶來了顯著成效。在過去的四個(gè)月中，我們的生產(chǎn)主機(jī)一直處于中位延遲狀態(tài)下。不必掌聲鼓勵(lì)、也無需鮮花簇?fù)恚P(guān)閉區(qū)回收機(jī)制這樣一個(gè)小小的決定讓LinkedIn迎來了顯而易見的性能提升--這正是我們技術(shù)人員的***樂趣！
