專用伺服器的 NUMA 感知與 CPU 固定
16 分鐘閱讀 - 2026年6月16日

如何檢查 NUMA 拓撲結構,並將 Linux 工作負載分配至正確的核心與記憶體。內容涵蓋 numactl、taskset、systemd、BIOS 設定,以及針對特定工作負載的策略。
專用伺服器的 NUMA 感知與 CPU 固定
在任何多插槽伺服器上,進程的執行位置與其記憶體的駐留位置是兩個不同的問題,而讓兩者失去同步,正是導致效能流失最常見的原因之一。 NUMA 意識與 CPU 固定正是解決此問題的兩大關鍵。本文將探討 NUMA 的運作原理、如何在 Linux 上進行檢視,以及如何針對資料庫、AI 訓練及對延遲敏感的服務,正確地固定工作負載。
NUMA 在多插槽伺服器上的運作原理
NUMA(非均勻記憶體存取)節點是一組透過專用記憶體控制器與本地 RAM 區塊綁定的 CPU 核心群組。在雙插槽伺服器上,通常會有兩個節點。 任何核心皆可讀取任意位址,但本地存取時間約為 80 奈秒,而透過 Intel 的 UPI 或 AMD 的 Infinity Fabric 進行跨插槽傳輸則約需 130–150 奈秒。在擁有更多插槽的大型系統中,最差情況下的節點傳輸時間可能超過 250 奈秒。
頻寬表現亦遵循相同模式。雙插槽的 Sapphire Rapids 系統在核心存取本地記憶體時,可維持約 600 GB/s 的頻寬,但插槽間的連線頻寬僅為其一小部分,因此穿越該連線的流量很快就會形成瓶頸。 高核心數的處理器使這現象更為細微:Intel 的 Sub-NUMA Clustering (SNC) 和 AMD 的 Nodes Per Socket (NPS) 會將每個插槽分割成多個 NUMA 區域,因此一個「雙插槽」系統對 Linux 而言,很容易呈現出四個或八個節點。
若缺乏 NUMA 意識,Linux 排程器會樂於將執行緒在插槽間遷移,而其工作集卻仍留在原始節點上。隨後的每次存取都將變成遠端存取。顯而易見的症狀是 CPU 使用率偏高但實際吞吐量偏低,因為核心正耗費時間等待記憶體。I/O 裝置會使情況更加惡化。 GPU 或 NIC 連接至特定的 PCIe 根總線,而該總線隸屬於某個 NUMA 節點。若負責供料的程序運行在另一顆插槽上,每次 DMA 傳輸都必須穿越互連架構。
在 Linux 上檢查 NUMA 拓撲
四種工具幾乎涵蓋了您所需的一切:
lscpu用於快速檢視套接字與節點摘要。numactl --hardware用於查看節點記憶體總量及節點間距離矩陣。numastat用於查看各進程的命中/未命中計數器。lstopo(來自 hwloc) 用於查看快取層級與 PCIe 裝置的局部性。
從 numactl --hardware。此處列出每個節點、其所屬的核心與記憶體,以及距離矩陣。數值 10 表示本地,20+ 則為遠端。若在多插槽系統上僅看到單一節點,表示您的 BIOS 已啟用「節點交錯 (Node Interleaving)」並隱藏了拓撲結構,請先修正此設定(參見下方)。
針對特定程序, numastat -p <PID> 會詳細顯示其記憶體實際分配的位置。有四個計數器值得關注:
numa_hit: 記憶體分配在目標節點上。此數值應盡可能高。numa_miss:目標節點已滿,分配溢出至其他節點。numa_foreign:表示其他節點嘗試在本地分配記憶體但未成功,顯示記憶體壓力。other_node:在非進程運行節點上分配的頁面。此處數值偏高是固定策略不佳的典型徵兆。
對於 GPU 或 NIC 工作負載,請執行 lstopo-no-graphics 並查看每個 PCIe 裝置連接至哪個 NUMA 節點。若驅動該裝置的核心位於其他節點上,這便是首要解決的問題。
CPU 固定與記憶體政策
CPU 固定(或稱 CPU 親和性)會將程序綁定至特定核心,使排程器無法將其遷移。僅靠這一點尚不足夠,因為 Linux 預設採用「首次觸及」記憶體政策:頁面會分配在第一個對其寫入的節點上。 如果一個執行緒在被固定之前在錯誤的節點上啟動,其記憶體就會留在該節點。您需要同時控制放置和分配。
有三種工具可處理常見情況:
| 工具 | 控制項目 | 適用於 |
|---|---|---|
taskset | 僅限 CPU 核心 | 快速將現有程序進行一次性綁定 |
numactl | CPU 核心與記憶體 | 啟動具有嚴格局部性的工作負載 |
| systemd | CPU 核心與記憶體,持久化 | 需要跨重啟固定配置的服務 |
numactl 支援四種記憶體政策:
--membind=N:僅在節點 N 上分配,若已滿則失敗。--preferred=N: 優先使用節點 N,若滿載則退而求其次。--interleave=all:在各節點間輪詢分配,以實現均勻的頻寬分配。--localalloc:在執行中 CPU 所在的任一節點上進行分配。
將工作負載固定至單一節點
首先,識別哪些核心屬於您的目標節點:
numactl --hardware接著啟動應用程式,並將其核心與記憶體綁定至該節點:
numactl --cpunodebind=0 --membind=0 ./your_application對於已執行的程序,請使用 taskset:
taskset -cp 0-7 <PID>若要使其在系統重啟後仍能維持設定,請在 systemd 單元中設定:
[Service]
CPUAffinity=0-7
NUMAPolicy=bind
NUMAMask=0重新載入並重新啟動:
sudo systemctl daemon-reload && sudo systemctl restart <service>當您手動進行核心綁定時,請關閉核心的自動負載平衡機制,以免其干擾您的配置:
sysctl -w kernel.numa_balancing=0將其加入 /etc/sysctl.conf 以確保設定持久化。接著透過 numastat -p <PID> 在幾分鐘的實際工作負載下進行驗證。若 other_node 值維持在接近零,表示固定配置已生效。
根據工作負載選擇策略
合適的策略取決於您的工作負載是更需要低延遲,還是需要所有節點的總合頻寬。
| 工作負載 | 策略 | 原因 |
|---|---|---|
| 資料庫(PostgreSQL、MySQL、SQL Server) | --cpunodebind + --membind | 大型共用緩衝區、對延遲敏感的查詢路徑 |
| 記憶體內快取(Redis、Memcached) | 單節點綁定 | 所有操作皆為 RAM 存取,遠端延遲會立即顯現 |
| AI/ML 訓練與推論 | 綁定至 GPU 的 NUMA 節點 | 避免張量傳輸跨越 PCIe 根節點 |
| 分析(Spark、Elasticsearch) | --interleave=all | 大型工作集需要跨所有節點的頻寬 |
| 對延遲敏感的 API,權衡取捨 | 嚴格的針腳 + 中斷請求 (IRQ) 親和性 | 可預測性比峰值吞吐量更重要 |
| 網路密集型(RoCEv2、InfiniBand) | 將引腳綁定至 NIC 的 NUMA 節點,並為中斷請求 (IRQ) 專用核心 | 將中斷處理維持在本地,避免干擾應用程式執行緒 |
針對 GPU 工作負載,請執行 lstopo 以找出 GPU 所在的 NUMA 節點,接著使用 numactl --cpunodebind=N --membind=N 針對該相同 N 啟動訓練或推論程序。這是多插槽 GPU 伺服器上最容易獲得成效的方法之一,因為預設排程器的配置往往不正確。
對於橫跨兩個插槽的 HPC 和 MPI 工作負載,請使用 localalloc 將每個 rank 固定在單一節點上,而非將所有內容交錯配置。每個 rank 皆擁有本地記憶體,並行處理則在 rank 層級進行。
一項實務建議:若將工作負載固定在單一節點上,請在該節點預留 2–4 GB 的記憶體餘裕。若節點使用率接近滿載,將觸發記憶體回收機制,這會導致您原本試圖節省的延遲反而增加。
需檢查的 BIOS 與核心設定
工具輸出的準確性取決於韌體所揭露的拓撲結構。需確認的幾項設定:
- 節點交錯 (Node Interleaving):請關閉此功能。若啟用此功能,BIOS 會將所有記憶體呈現為單一平面記憶體池,並完全隱藏 NUMA 結構不讓作業系統偵測到。
numactl --hardware若此設定生效,多插槽主機上將僅顯示一個節點。 - 次 NUMA 叢集 (Intel) 或 每插槽節點數 (AMD):若需更精細的局部性,請在高核心數處理器上啟用此功能。
lscpu重新開機後確認。 vm.zone_reclaim_mode:對於大多數生產環境伺服器,請設定為 0。非零值會積極回收本地記憶體而非進行遠端分配,這可能導致有用的頁面快取被驅逐。kernel.numa_balancing:針對通用工作負載請保持啟用,若需手動固定資源則應關閉。自動平衡器會以與您的策略相衝突的方式遷移頁面與執行緒。
若您在裸機環境中執行 NUMA 調校,且能控制 BIOS、核心參數及 IRQ 親和性,則無需繞過虛擬化層的抽象機制,即可直接套用上述所有設定。這正是此類工作在專用硬體上比在雲端虛擬機器中更為簡便的主要原因。
若您擁有具備完整 root 權限的多插槽專用伺服器,請參閱 FDC 的專用伺服器服務。

Linux 伺服器工作負載最佳化的調校設定檔
如何為 GPU、資料庫和高頻寬 Linux 伺服器選擇、應用和客製化已調整的配置文件,並提供範例和 Ansible 部署技巧。
16 分鐘閱讀 - 2026年6月9日
Linux OOM Killer Tuning for VPS:實用指南
12 分鐘閱讀 - 2026年6月8日