專屬伺服器工作負載的 CPU 綁定與核心隔離
專屬伺服器可讓工作負載直接使用實體 CPU 資源，但並不代表延遲自然穩定。其他程序、核心工作、硬件中斷、執行緒遷移及 NUMA 配置，仍會影響重要工作何時獲得 CPU 時間。CPU 綁定與核心隔離是兩種相關技術，可令執行環境更容易預測。
甚麼是 CPU 綁定與核心隔離？
CPU 綁定又稱 CPU 親和性（CPU affinity），會限制程序、執行緒或控制群組，只能在指定的一組邏輯 CPU 上執行。taskset、sched_setaffinity 及 cgroup v2 cpuset 等工具，都可實施這種配置策略。核心隔離則更進一步：為特定工作預留 CPU，並減少無關的排程及系統 housekeeping 活動。
在專屬伺服器上，管理者可以查看實體硬件拓撲，決定應用程式執行緒、記憶體、中斷及背景服務如何分配。CPU 綁定主要是位置安排；核心隔離則是作業系統層面的政策。兩者都不能彌補容量不足、程式效率低或執行緒池設定不當。
甚麼情況值得使用這些設定？
當尾端延遲、可重複性或工作之間的干擾，比平均 CPU 使用率更重要時，這些設定最有價值。例如有嚴格回應時間目標的交易工作、封包處理服務、媒體處理流程，以及需要避免受建置或批次工作影響的生產工作負載。
資料庫、分析及程式編譯等 CPU 密集工作，在需要與其他工作競爭時也可能受惠。固定 CPU 集合可減少執行緒遷移及快取干擾，但同時會降低排程器平衡工作的彈性。因此，應在實際關心的負載模式下量度改善幅度。
這並不是所有網站應用程式的預設設定。突發流量服務有時在排程器可以使用整台伺服器時表現更好；若隔離過多核心，也可能令作業系統及中斷處理缺乏容量。應先分析，再按工作負載需要預留核心。
- 對尾端延遲敏感的 API 及交易工作
- 封包處理、媒體或接近即時處理的服務
- 不可干擾生產服務的建置及 CI 工作
- 受控容器或虛擬機器使用的專用 CPU 池
先繪製實體 CPU 拓撲
應先了解伺服器的實際硬件拓撲，而不是只看邏輯 CPU 編號。lscpu、numactl –hardware 及 /sys/devices/system/cpu 可顯示 CPU 插槽、NUMA 節點、實體核心及 SMT 兄弟執行緒。兩個邏輯 CPU 可能只是同一實體核心上的兄弟執行緒，提供的資源並不等同於兩個獨立核心。
應有意識地選擇實體核心，決定是否把兩條 SMT 兄弟執行緒一起分配，並讓應用程式執行緒靠近所使用的記憶體。跨插槽運行的工作可能因存取遠端記憶體而增加延遲。合適的配置取決於處理器、記憶體通道及工作負載的通訊模式。
對容器化服務而言，CPU 綁定應與配額、權重及 cpuset 一起考慮。Dataplugs 的「裸機伺服器上的容器資源限制與 cgroups」說明 cgroup 如何控制資源使用；配額限制 CPU 時間，而綁定則控制工作可以在哪些 CPU 上執行。若不了解兩者的差異，測試結果可能會產生誤導。
提示：把 CPU 綁定視為位置安排政策，而不是容量規劃的替代方案。在分配應用程式核心前，先為系統 housekeeping 工作預留足夠容量。
CPU 綁定與核心隔離並不相同
CPU 綁定會把程序、執行緒或控制群組限制在允許的 CPU 集合內。除非另行排除，其他工作仍然可以在這些 CPU 上執行。這可以減少遷移及改善快取局部性，但本身不會令所選核心成為私人核心。
核心隔離會令指定 CPU 減少處理排程及核心背景活動。視乎核心版本及工作負載，isolcpus、nohz_full 及 rcu_nocbs 等 Linux 設定可能有用，但 IRQ、核心執行緒及裝置工作仍需明確處理。「已隔離」的 CPU 並不代表自動變成「沒有其他工作」的 CPU。
- CPU 親和性及 cpuset 位置安排
- 排程器及核心 housekeeping 工作
- 中斷及網卡佇列親和性
- NUMA 感知的記憶體配置
- 應用程式執行緒池行為
當環境涉及容器或虛擬機器時，隔離模式與主機 CPU 配置同樣重要。Dataplugs 的「容器化與虛擬化：裸機上的隔離與效能」比較兩種方式的取捨。在主機上綁定程序，並不代表每條客戶機執行緒都會獲得最佳排程，因此應在工作實際運行的層級驗證位置安排。
配置完整的 Linux 執行路徑
應使用與服務管理器及執行環境相符的控制項。systemd 可使用 CPUAffinity 或 AllowedCPUs，cgroup v2 可設定 cpuset，容器則可使用 –cpuset-cpus 等選項。Kubernetes 叢集在符合條件的 Guaranteed Pod 上，可能使用 static CPU Manager policy。實際行為會因核心、執行環境及編排層而異。
對延遲敏感的服務，亦應檢視 IRQ 親和性、網卡佇列、RPS/XPS、儲存中斷及核心工作執行緒。要為記錄、監控、SSH 及控制平面工作保留足夠的 housekeeping CPU。引導參數應逐步加入，並在核心升級後重新驗證，不要直接照搬一般調校指南。
不要假設配置已生效，應量度實際位置。mpstat -P ALL、pidstat、ps -o pid,psr、taskset -cp、/proc/interrupts、numastat 及 cgroup 指標，可顯示 CPU 使用率、遷移、中斷分布及 NUMA 行為。應使用受控流量測試，並比較 p95、p99 延遲、吞吐量、內容切換及飽和情況。
在容器及虛擬機器中使用 CPU 綁定
容器限制與 CPU 綁定解決的是不同問題。配額或權重控制容器可以獲得多少 CPU 時間，但不能保證固定的實體位置。cpuset 可以提供專用 CPU，但前提是主機有足夠餘量，而且容器的執行緒、記憶體及中斷路徑也要一併考慮。
對 LXC 及 Proxmox 部署而言，實際調校應把 CPU 限制、綁定及 NUMA 感知，與主機及客戶機的量度結果結合。Dataplugs 的「在 Proxmox VE 9 優化 LXC 容器效能」可作為參考，協助你整體檢視這些控制項，而不是把單一設定當成通用的效能修正方法。
避免常見的核心隔離錯誤
第一個錯誤是幾乎隔離所有核心。作業系統仍需要 CPU 處理排程、中斷、記錄、監控及管理工作。應保留清晰定義的 housekeeping 核心集合，並記錄哪些服務可以使用。
第二個錯誤是綁定工作負載時，沒有檢查 SMT 兄弟執行緒、NUMA 局部性、記憶體頻寬或中斷位置。服務的平均 CPU 使用率可能下降，但尾端延遲卻惡化。應在正常及高峰負載下驗證整條執行路徑，並保留可回復的設定作比較。
實際部署步驟
- 記錄延遲、吞吐量、CPU 遷移及內容切換的基線
- 繪製 CPU 插槽、NUMA 節點、實體核心及 SMT 兄弟執行緒
- 在分配應用程式 CPU 前，先預留 housekeeping 核心
- 先對一個工作負載套用親和性或 cpuset，並驗證實際位置
- 需要時對齊 IRQ、記憶體位置、儲存及網絡佇列
- 在正常及高峰負載下重新測試，然後記錄配置政策
CPU 綁定及核心隔離是調校工具，並不是效能保證。當 CPU 拓撲、記憶體位置、housekeeping 工作、中斷及應用程式行為一併考慮時，它們可以令專屬伺服器工作負載更容易預測。應從量度開始，一次只改動一層，並讓配置保持易於審核及回復。
Dataplugs 提供可配置的專屬伺服器，讓客戶控制 CPU、記憶體、NVMe 儲存及網絡資源。對延遲或干擾要求嚴格的工作負載而言，單租戶裸機環境可在加入 CPU 位置政策前，提供更清晰的效能基線。
如欲了解更多，歡迎瀏覽 Dataplugs，或聯絡 sales@dataplugs.com。