在當今的計算機世界里，隨著硬件性能的不斷提升，Linux 內核也在持續進化以充分發揮硬件的潛力。而今天，我們要深入探討的是 Linux 內核中一個至關重要但又常常被忽視的領域 ——NUMA 節點探測。你是否曾好奇，當我們的服務器擁有多個 CPU 和大量內存時，系統是如何高效地管理和分配這些資源的呢？這背后的功臣之一就是 NUMA 架構。想象一下，在一個龐大的數據中心里，眾多服務器協同工作，如果不能精準地掌握 NUMA 節點的情況，就如同在一個巨大的倉庫中盲目地尋找貨物，效率低下且容易出錯。

Linux 內核中的 NUMA 節點探測技術，就像是一把神奇的鑰匙，能夠幫助我們打開了解系統內存架構的大門。它讓我們清楚地知道每個 CPU 與內存之間的親和關系，以及數據在不同節點之間的流動情況。無論是優化服務器性能，還是解決復雜的系統故障，NUMA 節點探測都能為我們提供關鍵的線索和方向。接下來，就讓我們一起踏上這場探索 Linux 內核 NUMA 節點探測的奇妙之旅，揭開其神秘的面紗，看看它是如何在幕后默默工作，保障我們系統高效穩定運行的。

一、什么是NUMA

傳統的SMP對稱多處理器中，所有處理器都共享系統總線，因此當處理器的數目增大時，系統總線的競爭沖突加大，系統總線將成為瓶頸，所以目前SMP系統的CPU數目一般只有數十個，可擴展能力受到極大限制；NUMA技術有效結合了SMP系統易編程性和MPP（大規模并行）系統易擴展性的特點，較好解決了SMP系統的可擴展性問題，已成為當今高性能服務器的主流體系結構之一。

基于NUMA架構的高性能服務器有HP的Superdome、SGI的Altix 3000、IBM的 x440、NEC的TX7、AMD的Opteron等；NUMA（Non Uniform Memory Access）技術可以使眾多服務器像單一系統那樣運轉，同時保留小系統便于編程和管理的優點。

在早期，對于x86架構的計算機，那時的內存控制器還沒有整合進CPU，所有內存的訪問都需要通過北橋芯片來完成。此時的內存訪問如下圖所示，被稱為UMA（uniform memory access, 一致性內存訪問）。這樣的訪問對于軟件層面來說非常容易實現：總線模型保證了所有的內存訪問是一致的，不必考慮由不同內存地址之前的差異。

之后的x86平臺經歷了一場從“拼頻率”到“拼核心數”的轉變，越來越多的核心被盡可能地塞進了同一塊芯片上，各個核心對于內存帶寬的爭搶訪問成為了瓶頸；此時軟件、OS方面對于SMP多核心CPU的支持也愈發成熟；再加上各種商業上的考量，x86平臺也順水推舟的搞了NUMA（Non-uniform memory access,非一致性內存訪問）。在這種架構之下，每個Socket都會有一個獨立的內存控制器IMC（integrated memory controllers,集成內存控制器），分屬于不同的socket之內的IMC之間通過QPI link通訊。

然后就是進一步的架構演進，由于每個socket上都會有多個core進行內存訪問，這就會在每個core的內部出現一個類似最早SMP架構相似的內存訪問總線，這個總線被稱為IMC bus。

于是，很明顯的，在這種架構之下，兩個socket各自管理1/2的內存插槽，如果要訪問不屬于本socket的內存則必須通過QPI link 。也就是說內存的訪問出現了本地/遠程（local/remote ）的概念，內存的延時是會有顯著的區別的。這也是為什么在NUMA架構下有些應用性能反而更差的原因。

回到當前世面上的CPU，工程上的實現其實更加復雜了。以來看，兩個Socket之之間通過各自的一條9.6GT/s的QPI link互訪。而每個Socket事實上有2個內存控制器。雙通道的緣故，每個控制器又有兩個內存通道（channel），每個通道最多支持3根內存條（DIMM）。理論上最大單socket支持76.8GB/s的內存帶寬，而兩個QPI link，每個QPI link有9.6GT/s的速率（~57.6GB/s）事實上QPI link已經出現瓶頸了。

NUMA in Linux

對于NUMA系統來說，Linux會為每一個NUMA節點創建一套內存管理對象的實例，每個節點包含DMA, DMA32, NORMAL等Zone。當某個節點下的某個Zone無法滿足內存分配請求時，系統會咨詢zonelist進而決定后備Zone的選擇順序。當本地Zone NORMAL內存不足時，黙認順序是從本地的Zone DMA32和DMA嘗試，然后再嘗試其它的節點。此順序可以由numa_zonelist_order參數更改，比如先去嘗試遠程節點的Zone NORMAL以節省比較稀缺的Zone DMA32和DMA內存（當然，非黙認NUMA policy有可能偏好遠程節點）。

二、NUMA系統架構

2.1內存管理的 “進化之路”

⑴SMP 架構的困境

在早期的計算機系統中，隨著應用對計算性能需求的不斷攀升，多處理器技術應運而生，其中對稱多處理（SMP）架構備受矚目。在 SMP 架構下，多個處理器平等地連接到同一條共享內存總線上，共享同一物理內存空間，就像一群小伙伴共同圍繞著一個公共的玩具箱，每個人都能平等地從中拿取玩具。這種架構的設計初衷是為了充分利用多個處理器的并行計算能力，通過操作系統的調度，讓不同的處理器協同處理各種任務，從而提升系統的整體性能。

然而，隨著處理器核心數量的持續增加，SMP 架構逐漸暴露出嚴重的性能瓶頸。想象一下，當眾多小伙伴同時沖向玩具箱想要取出自己心儀的玩具時，共享內存總線就如同那狹窄的玩具箱開口，成為了激烈競爭的焦點。多個處理器頻繁地同時訪問內存，導致總線爭用異常激烈，內存訪問延遲急劇上升。在高并發場景下，為了保證數據的一致性，處理器往往需要使用原子指令來訪問內存，例如通過鎖總線的方式獨占內存訪問權。這就好比小伙伴們在爭搶玩具時，有人直接把玩具箱的開口堵住，不讓其他人拿玩具，直到自己拿到為止，使得其他處理器只能干巴巴地等待，造成大量的處理器資源閑置浪費，系統整體性能大打折扣。

以一個典型的數據庫服務器為例，在處理大量并發事務時，多個處理器核心需要頻繁讀寫內存中的數據塊。由于 SMP 架構下內存總線的爭用，處理器常常需要等待很長時間才能獲取到所需的數據，導致事務處理的響應時間大幅增加，系統吞吐量急劇下降，無法滿足業務對高性能的要求。這種內存訪問瓶頸嚴重制約了 SMP 架構在大規模計算場景下的應用，迫切需要一種新的內存架構來打破這一困境。

⑵NUMA 架構應運而生

為了突破 SMP 架構在內存訪問方面的瓶頸，非統一內存訪問（NUMA）架構應運而生。它像是給計算機系統重新規劃了一個更合理的 “居住布局”，將整個系統劃分為多個節點（Node），每個節點都配備了自己的本地內存、處理器以及 I/O 設備，節點之間則通過高速互連網絡進行通信，就如同在一個大型社區里，劃分出了多個相對獨立的小區，每個小區都有自己的配套設施，小區之間有便捷的道路相連。

在 NUMA 架構中，處理器訪問本地內存的速度遠遠快于訪問其他節點的遠程內存，這是因為本地內存與處理器之間的物理距離更近，數據傳輸延遲更低，就像小區居民在自家樓下的小超市購物，方便快捷；而訪問其他節點的內存則像是要跑到隔壁小區的超市購物，需要經過一段路程，花費更多的時間。這種內存訪問的非一致性特性，使得 NUMA 架構能夠有效地減少內存總線的爭用，提高內存訪問的并行性，進而提升系統的整體性能。

與 SMP 架構相比，NUMA 架構最大的不同在于其內存訪問的非對稱性。SMP 架構下，所有處理器對內存的訪問延遲是一致的，就像所有居民到公共玩具箱的距離都一樣遠；而 NUMA 架構中，不同節點的內存訪問延遲存在差異，處理器會優先訪問本地內存，以獲取更快的數據讀寫速度。這種差異使得 NUMA 架構在處理大規模數據密集型應用時具有顯著優勢，能夠更好地適應現代計算機系統對高性能、高擴展性的需求。例如，在大規模科學計算、云計算數據中心等場景中，NUMA 架構能夠充分發揮各個節點的計算能力，高效地處理海量數據，為用戶提供快速、穩定的服務。

2.2Linux 內核中的 NUMA 架構 “畫像”

⑴節點的組織與表示

在 Linux 內核的世界里，對于 NUMA 架構的支持可謂是精心設計、精妙絕倫。每個 NUMA 節點在內核中是由結構體 pglist_data（在老版本內核中叫 pg_data_t，本質相同）來進行描述的，它就像是每個節點的 “管家”，掌管著節點內諸多關鍵信息。這個結構體包含了一個名為 node_zones 的數組，其類型為 struct zone，這便是內存區域的 “收納盒”，每個節點內不同特性的內存區域都被收納其中。

為了兼容不同硬件設備五花八門的特性以及應對 32 位、64 位系統各自的需求，Linux 內核將內存劃分成了不同的區域類型。常見的有 ZONE_DMA、ZONE_DMA32、ZONE_NORMAL 等。ZONE_DMA 區域，通常是低 16M 的內存范圍，它可是專為那些支持直接內存訪問（DMA）的設備量身定制的。因為有些老舊的 DMA 控制器，它們只能訪問這低 16M 的內存空間，所以內核特意劃分出這片區域，以確保這些設備能夠順暢地與內存交互，實現數據的高速傳輸，就好比為特殊需求的客人預留了特定的通道。

隨著硬件的發展，64 位系統登上舞臺，一些新的 DMA 設備能夠訪問更廣泛的內存空間，但又達不到完整的 4G 范圍，于是 ZONE_DMA32 應運而生，它主要服務于這些較新的、能訪問 4G 以內內存的 DMA 設備，為它們提供了專屬的 “棲息地”。

而 ZONE_NORMAL 區域，則涵蓋了 16M 到 896M（在 32 位系統且開啟物理地址擴展 PAE 的情況下）或者更大范圍（64 位系統）的內存，這片區域的內存可以直接映射到內核的虛擬地址空間，內核能夠直接、高效地對其進行訪問，就像是家里的 “常用物品存放區”，取用物品極為便捷，是內核日常運行時頻繁使用的內存 “主力軍”。

不同的內存區域有著不同的使命，它們緊密協作，與硬件設備默契配合，為整個系統的穩定高效運行奠定了堅實基礎。這種精細的內存區域劃分，充分展現了 Linux 內核設計的前瞻性與兼容性，使得 Linux 能夠在各種硬件平臺上縱橫馳騁，大放異彩。

⑵內存分配的 “策略藍圖”

當系統需要分配內存時，Linux 內核就像一位精明的調度大師，有著一套嚴謹且周全的策略。首先，它會依據預先計算好的節點距離信息，為內存分配指引方向。每個節點與其他節點之間的距離都被精準度量，這個距離可是影響內存分配優先級的關鍵因素。

以 ZONELIST_FALLBACK 策略為例，假設系統中有多個 NUMA 節點，節點 0 在分配內存時，會優先查看自身節點的內存情況。因為訪問自身節點的內存就如同在自家院子里取東西，速度最快，延遲最低。要是自身節點內存告急，無法滿足需求，內核就會按照節點距離由近及遠的順序，依次去相鄰節點 “借” 內存，比如先看向節點 1，再是節點 2、節點 3 等。這就好比先向隔壁鄰居求助，若鄰居也沒辦法，再往稍遠一點的人家打聽。

不過，也有些特殊場景，比如使用 __GFP_THISNODE 標志進行內存分配時，就遵循 ZONELIST_NOFALLBACK 策略，意味著內存分配只能在當前 NUMA 節點內進行，哪怕內存吃緊，也絕不 “外借”，有點像堅守自家資源，自力更生的意思。

確定好節點后，接下來就要挑選具體的內存區域了。這時候，node_zonelists 數組就派上了大用場。它就像是一張詳細的 “內存地圖”，指引著內核找到合適的內存區域。在 ZONELIST_FALLBACK 策略下，對于節點 0 的 node_zonelists[ZONELIST_FALLBACK]，其內部的 zoneref 元素會按照節點距離排序，同時每個節點內的內存區域又依據優先級從高到低排列，通常是 ZONE_NORMAL 優先級較高，優先被考慮，其次是 ZONE_DMA32，最后是 ZONE_DMA。這是因為 ZONE_NORMAL 區域的內存使用最為頻繁、便捷，而 ZONE_DMA 區域相對較為特殊，只用于特定的 DMA 設備，不能輕易動用。

當進程申請內存時，內核會從這張 “地圖” 的起始位置開始查找，優先鎖定距離最近節點中的最高優先級內存區域。若該區域內存不足，才會按照既定順序，逐步往低優先級區域或者更遠節點的內存區域探索，直到找到滿足需求的內存為止。如此精細復雜的內存分配策略，確保了在 NUMA 架構下，系統能夠充分利用各個節點、各個區域的內存資源，達到性能的最優平衡，讓計算機系統在多任務、高負載的復雜環境下依然能夠穩健運行，高效處理各種數據與任務。

三、NUMA核心技術

三種系統架構 & 兩種存儲器共享方式

從系統架構來看，目前的商用服務器大體可以分為三類：

• 對稱多處理器結構(SMP：Symmetric Multi-Processor)
• 非一致存儲訪問結構(NUMA：Non-Uniform Memory Access)
• 海量并行處理結構(MPP：Massive Parallel Processing)。

共享存儲型多處理機有兩種技術：

• 均勻存儲器存取（Uniform-Memory-Access，簡稱UMA）技術
• 非均勻存儲器存取（Nonuniform-Memory-Access，簡稱NUMA）技術

3.1UMA技術

UMA是并行計算機中的共享存儲架構，即物理存儲器被所有處理機均勻共享，對所有存儲字具有相同的存取時間。每臺處理機可以有私用高速緩存,外圍設備也以一定形式共享。UMA技術適合于普通需求和多用戶共享時間的應用，在時序要求嚴格的應用中，被用作加速單一大型程序的執行率。

3.2NUMA技術

NUMA是用于多進程計算中的存儲設計，存儲讀取取決于當前存儲器與處理器的關聯。在NUMA技術下，處理器訪問本地存儲器比非本地存儲器（另一個處理器的本地存儲器或者處理器共享的存儲器）更快。

3.4vNUMA

vNUMA消除了VM和操作系統之間的透明性，并將NUMA架構直通到VM的操作系統。值得一提的是，vNUMA在業內與NUMA同樣盛名。對于一個廣泛VM技術，VM運行的底層架構，VM的NUMA拓撲跨越多個NUMA節點。在啟用了vNUMA的VM的初始功能之后，呈現給操作系統的架構是永久定義的，并且不能被修改。這個限制通常是正面的，因為改變vNUMA體系結構可能會導致操作系統的不穩定，但是如果VM通過vMotion遷移到帶有不同NUMA架構的管理程序，則可能導致性能問題。值得一提的是，盡管大多數應用程序都可以利用vNUMA，但大多數VM都足夠小，可以裝入NUMA節點;最近對寬-VM支持或vNUMA的優化并不影響它們。

因此，客戶操作系統或它的應用程序如何放置進程和內存會顯著影響性能。將NUMA拓撲暴露給VM的好處是，允許用戶根據底層NUMA架構做出最優決策。通過假設用戶操作系統將在暴露的vNUMA拓撲結構中做出最佳決策，而不是在NUMA客戶機之間插入內存。

3.5NUMA的重要性

多線程應用程序需要訪問CPU核心的本地內存，當它必須使用遠程內存時，性能將會受到延遲的影響。訪問遠程內存要比本地內存慢得多。所以使用NUMA會提高性能。現代操作系統試圖在NUMA節點（本地內存+本地CPU=NUMA節點）上調度進程，進程將使用本地NUMA節點訪問核心。ESXi還使用NUMA技術為廣泛的虛擬機，當虛擬核心大于8時，將虛擬核心分布在多個NUMA節點上。當機器啟動時，虛擬核心將被分發到不同的NUMA節點，它將提高性能，因為虛擬核心將訪問本地內存。

四、探尋NUMA節點

4.1探測的 “魔法指令”

在 Linux 系統中，想要揭開 NUMA 節點的神秘面紗，查看其詳細信息，我們有一些非常實用的 “魔法指令”。就拿 numactl 來說，它堪稱是探索 NUMA 架構的得力助手。當我們在終端輸入 “numactl --hardware”，系統就如同一位貼心的導游，為我們展示出系統的 NUMA 拓撲全景圖。從這幅圖中，我們能清晰知曉系統里究竟有多少個 NUMA 節點，它們就像是分布在計算機世界里的不同 “領地”。

每個節點配備的 CPU 核心數量也一目了然，這些 CPU 核心可是節點的 “主力軍”，肩負著處理各種任務的重任。內存總量信息則讓我們對系統的存儲資源心中有數，清楚每個節點能容納多少數據 “寶藏”，以及當前還有多少可用內存，為資源分配提供關鍵參考。另外，節點之間的距離信息也十分關鍵，它直觀地反映了不同節點間內存訪問的 “路程遠近”，幫助我們理解數據傳輸的開銷成本。

舉個例子，在一臺配置了雙路處理器、擁有兩個 NUMA 節點的服務器上執行此命令，可能會得到類似這樣的結果：節點 0 擁有 8 個 CPU 核心，內存總量為 16GB，當前空閑內存 2GB，與節點 1 的距離為 20；節點 1 同樣有 8 個 CPU 核心，內存總量 16GB，空閑內存 3GB，節點間距離相互對稱。有了這些詳細信息，我們就能精準把握系統資源布局，為后續的應用部署、性能優化提供有力依據，讓系統運行更加高效流暢。

除了 numactl，在 /sys/devices/system/node 目錄下也隱藏著諸多關于 NUMA 節點的 “情報”。這里面的每個以 “node” 開頭的子目錄，都對應著一個具體的 NUMA 節點，仿佛是一個個裝滿信息的 “寶箱”。進入這些子目錄，查看諸如 “cpulist” 文件，就能知曉該節點所關聯的 CPU 核心列表，就像拿到了節點的 “兵力部署圖”；“meminfo” 文件則詳細記錄著內存的使用情況，包括已用內存、空閑內存等，是內存資源的 “賬本”。這些文件里的數據實時更新，時刻反映著系統運行過程中 NUMA 節點的動態變化，為系統管理員、開發者提供了一手的資源動態信息，便于及時調整策略，保障系統穩定高效運行。

4.2代碼中的 “蛛絲馬跡”

倘若我們想要深入到 Linux 內核的底層，從代碼層面去理解 NUMA 節點探測的原理，那就得走進內核源碼的 “神秘世界”。以常見的 64 位多核操作系統為例，在 Linux 內核源碼里，有一系列關鍵的結構體和函數在默默運作。

首先是 numa_node_id() 函數，它就像是一個 “導航儀”，當進程在運行過程中需要獲取當前所處的 NUMA 節點編號時，只要調用這個函數，就能快速定位。它的實現原理涉及到對硬件寄存器、內存映射等底層機制的巧妙運用。在一些基于 Intel 架構的系統中，處理器會通過特定的寄存器來記錄當前訪問內存所對應的 NUMA 節點信息，numa_node_id() 函數則會讀取這個寄存器的值，經過簡單的轉換和校驗，將準確的節點編號返回給調用者，確保進程能精準知曉自己的 “歸屬地”。

再深入探究，struct pglist_data 結構體中的諸多成員變量，為我們全方位揭示了 NUMA 節點的詳細信息。node_id 成員明確標識了節點的唯一編號，如同每個人的身份證號，在整個系統中獨一無二；node_start_pfn 記錄著節點起始物理頁幀的編號，這是內存管理的重要基石，通過它可以快速定位節點內存的起始位置，為內存分配、回收等操作劃定邊界；node_spanned_pages 則精確統計了節點所跨越的物理頁幀數量，讓我們清楚了解每個節點的內存容量大小，以便合理規劃資源。

當系統啟動初始化階段，內核會逐個遍歷識別出的 NUMA 節點，就像一位嚴謹的普查員，對每個節點的硬件信息進行仔細登記。通過讀取主板 BIOS 提供的 ACPI（高級配置與電源接口）表，獲取節點的 CPU 拓撲結構、內存布局等關鍵信息，然后將這些信息填充到相應的結構體成員中，完成對 struct pglist_data 結構體的初始化。在后續的系統運行過程中，內核就依據這些初始化后的信息，有條不紊地進行內存管理、進程調度等一系列復雜而關鍵的任務，確保整個系統在 NUMA 架構下高效協同運行，為用戶提供流暢穩定的使用體驗。

五、NUMA節點實戰

5.1進程與節點的 “綁定術”

了解了這么多關于 NUMA 節點的知識，那如何在實際應用中充分發揮它的優勢呢？關鍵就在于將進程合理地綁定到特定的 NUMA 節點或 CPU 核心上。

在 Linux 系統中，我們有一些便捷的工具來實現這一操作。就拿 numactl 來說，假如我們有一個對內存帶寬要求極高的計算密集型任務，像是大規模的科學計算模擬程序，為了減少內存訪問延遲，提升計算效率，我們可以使用 “numactl --cpunodebind=0 --membind=0 程序名” 這樣的命令，將該程序綁定到 NUMA 節點 0 上運行。這意味著程序運行過程中所涉及的 CPU 核心都來自節點 0，內存分配也優先從節點 0 的本地內存獲取，如同為這個任務開辟了一條專屬的 “高速通道”，讓數據的讀寫能夠以最快的速度完成，避免了跨節點訪問帶來的額外開銷。

除了 numactl，taskset 命令也是我們的得力幫手。它專注于 CPU 核心的綁定，例如 “taskset -c 2,3,4 程序名”，就能將指定程序固定在 CPU 核心 2、3、4 上運行。這在一些多線程應用場景中尤為實用，比如網絡服務器程序，通過將不同的線程綁定到不同的 CPU 核心，可以有效減少線程上下文切換的開銷，提高服務器的并發處理能力，確保每個請求都能得到快速響應，就像為每個任務分配了專屬的 “工作間”，互不干擾，高效協作。

合理運用這些綁定技巧，能夠讓進程與 NUMA 節點、CPU 核心之間形成默契配合，充分挖掘硬件的性能潛力，為各類應用場景帶來顯著的性能提升，讓系統運行得更加流暢、高效。

5.2優化的 “妙手回春”

為了更直觀地感受 NUMA 節點優化帶來的神奇效果，我們來看一個實際案例。

假設有一臺配備了兩個 NUMA 節點的服務器，每個節點擁有 8 個 CPU 核心，總內存為 32GB。在未進行 NUMA 優化之前，運行一個多線程的數據庫查詢應用程序，該程序會頻繁地訪問內存數據。由于進程默認的內存分配和 CPU 調度是相對隨機的，很容易出現跨節點訪問內存的情況，導致內存訪問延遲增加，系統性能受到制約。

通過使用 numactl 工具，我們將這個數據庫查詢應用程序綁定到其中一個 NUMA 節點上，例如 “numactl --cpunodebind=0 --membind=0 數據庫應用程序名”。綁定之后，再次運行該程序，并使用性能監測工具觀察相關指標。

對比綁定前后的數據，我們發現內存訪問延遲有了顯著降低。原本跨節點訪問時，平均延遲可能高達 200 納秒左右，而綁定后，在節點內部訪問內存，延遲大幅下降到 50 納秒以內，這使得查詢操作能夠更快地獲取所需數據，整體響應時間縮短了約 30%。

從帶寬利用率來看，未優化前，由于頻繁的跨節點內存訪問爭用帶寬，實際可用帶寬利用率僅能達到 50% 左右；優化后，數據基本在本地節點內流轉，帶寬利用率提升至 80% 以上，數據傳輸更加順暢，系統吞吐量明顯增加，能夠同時處理更多的查詢請求，大大提升了數據庫服務器的性能表現，為業務的高效運行提供了有力支撐。