- 對 Linux 核心進行調優需要結合架構配置、sysctl 和麵向延遲的 CPU 調度。
- 自訂內核和 PREEMPT_RT 補丁可以大幅降低延遲，但它們會增加複雜性和維護難度。
- 網路、記憶體、磁碟和系統服務的最佳化應該始終透過嚴格的監控和基準測試來衡量。
- 迭代式、指標驅動的方法可以將核心改進轉化為應用程式和使用者的實際利益。
當我們談論Linux的性能時，幾乎所有問題最終都指向同一個地方： 核心作為控制延遲、穩定性和資源利用的核心元件適當的微調可以決定一個系統是僅僅「勉強夠用」還是能夠在伺服器、桌面、雲端環境甚至其他裝置上流暢運作。 非常老舊的硬件.
本指南重點在於如何 優化 Linux 內核，在不影響安全性和可維護性的前提下，最大限度地降低延遲。我們將涵蓋從基本架構概念到使用 sysctl 進行調整、編譯自訂核心、使用即時修補程式、針對低延遲網路（如 EC2）進行調優，以及監控和基準測試技術，以衡量您所做的調整是否真的有所改進。
Linux 核心架構及延遲關鍵點
Linux 核心充當應用程式和硬體之間的中間層，負責管理 記憶體、流程、中斷、驅動程式和檔案系統。 他的 整體式但模組化設計由於採用了可載入模組，因此無需重新編譯整個系統即可靈活地啟用或停用功能。
要了解延遲的來源，關鍵在於了解幾個子系統： 流程規劃器（調度器）記憶體管理和中斷處理至關重要。即使使用強大的硬件，配置不當的調度器、激進的記憶體策略或過多的不受控制的中斷也會導致響應速度緩慢。
內核配置涉及以下選項： CONFIG_PREEMPT、CONFIG_PREEMPT_VOLUNTARY 或 CONFIG_SMP這些因素決定了核心在多大程度上可以中斷以處理更緊急的任務，以及如何利用多核心系統。選擇合適的搶佔模型會顯著改變桌上型電腦、低延遲伺服器或工業系統上的感知延遲。
在現代伺服器中，硬體拓撲結構也很重要： 核心、插槽、NUMA 和快取層次結構的分佈微調 CPU 親和性和 NUMA 策略（例如，將進程和記憶體固定到同一節點）有助於減少存取時間並提高快取命中率，這對於我們想要最大限度地減少抖動和不可預測的延遲至關重要。
此外，CPU調度器與子系統之間的交互 I/O（磁碟和網路）決定吞吐量和端對端延遲 應用程式可以看到這些變更。在進行任何更改之前，建議記錄當前狀態（核心配置、sysctl、GRUB、已載入模組），以便在更改導致效能下降時快速回滾。
透過 sysctl 進行調整以改善延遲和效能
接口 sysctl 允許您動態修改核心參數 透過 /proc/sys 進行配置，無需重新編譯。這是開始進行調優的理想切入點，無需先陷入編譯的繁瑣步驟。
在網路領域，諸如以下參數： net.core.rmem_max、net.core.wmem_max 或 net.ipv4.tcp_congestion_control 它們直接影響吞吐量、延遲和 TCP 連線行為。對於高流量 Web 伺服器或低延遲雲端執行個體而言，正確調整緩衝區和擁塞演算法至關重要。
對於記憶體而言，諸如此類的值 vm.swappiness、vm.dirty_ratio、vm.vfs_cache_pressure 或 vm.overcommit_memory 它們允許您控制交換空間的使用量、頁面快取的管理方式以及虛擬記憶體的行為。降低交換空間使用率（例如，降至 10）通常有助於防止系統過於頻繁地使用交換空間，從而減少磁碟 I/O 延遲峰值。
如果您使用大型資料庫或應用程序，並且這些應用程式使用大量的共享內存，那麼調整內存使用情況至關重要。 kernel.shmmax，kernel.shmall 以及以下方式開啟的最大檔案數 fs.file-max 和 fs.nr_open這些尺寸不合理的限制可能會導致瓶頸和錯誤，而這些錯誤在負載下很難診斷。
最佳方法是先實施小幅改動，用監測工具衡量其影響，然後再進行大幅調整。 它們會被儲存到 /etc/sysctl.conf 或 /etc/sysctl.d/ 中。在容器化環境中，請記住許多核心參數對於主機是全域性的：隨意更改它們可能會影響所有服務，因此將 sysctl 與 cgroups 和命名空間結合使用幾乎是強制性的。
編譯和維護自訂內核
當你需要編譯自訂核心時，它仍然是一個非常強大的工具。 降低延遲、消除不必要的開銷或支援稀有硬體雖然發行版都配備了相當通用的內核，但在某些情況下，特定的內核能發揮至關重要的作用。
傳統的流程包括從以下位置下載程式碼： kernel.org 或像 xanmod 這樣的打過補丁的內核樹 利可力克斯並使用諸如此類的工具 make menuconfig 選擇選項。將 .config 檔案與建置腳本一起儲存到您自己的 Git 倉庫中，可讓您重現建置流程並保持版本之間的一致性。
如果您使用 Debian 或其衍生發行版，編譯“Debian 風格“獲取核心、頭文件和相關庫的 .deb 軟體包。這樣，您只需安裝這些軟體包，並使用您自己的存儲庫管理版本，即可在多台機器上部署該自定義內核。”
在現實世界中，當你使用…時，手動編譯通常是有意義的。 老舊或功能非常有限的硬件一個典型的例子是 舊上網本 配備 Atom CPU 和 1 GB 記憶體的電腦，其現代通用核心充滿了不必要的驅動程式和伺服器選項，引入了你無法承受的延遲和額外的 CPU 消耗。
一種常見的策略是從目前的核心配置開始（例如，透過複製以下檔案）： /啟動配置），然後從那裡進行裁剪或調整。您可以將搶佔模型變更為“搶佔式核心（低延遲桌面）“優先處理互動式桌面回應，或添加特定的 I/O 調度程序，例如…” Bfq 以模組的形式，改善機械碟的使用體驗。
為了避免把半輩子都耗在編譯上，最好在效能更強的機器上進行編譯，必要時還可以使用… 交叉編譯 （例如，只需調整架構和對應的工具鏈，即可在 x86_64 PC 上為 Atom 編譯 32 位元核心）。然後，只需在目標機器上安裝 .deb 文件，並在 GRUB 中添加相應的條目即可。
棘手之處在於維護：建議 在加那利群島節點上測試新內核在啟動管理員中設定清晰的回滾路徑，並在轉換過程中記錄日誌和指標，以偵測效能或驅動程式相容性方面的退化。
低延遲系統的搶佔模型和 PREEMPT_RT 補丁
核心的搶佔模型決定了正在運行的任務可以中斷多少次，以便讓優先權更高的任務接管，這直接影響到… 回應延遲這包括標準配置選項和即時補丁。
通用核心提供多種選項：無搶佔（更注重伺服器吞吐量）、自願搶佔和 桌面搶佔式內核這樣可以優先保證互動式應用程式的快速回應時間。調整此設定可以顯著提升桌面系統、音訊設備，甚至是負載較高的老舊機器的效能。
當您需要進一步操作時，會出現以下內容： PREEMPT 和 PREEMPT_RT 補丁這些修改會改變核心的重要部分，以最大限度地減少不可搶佔部分。 PREEMPT_RT 適用於最壞情況延遲（而不僅僅是平均延遲）必須非常低且可預測的系統，例如工業自動化、專業音訊、電信或高頻交易。
引入 PREEMPT_RT 的決定不應基於時尚，而應基於 延遲和抖動的具體測量首先，建議充分利用調度程序設定、CPU 親和性、sysctl 以及（如果適用）動態無滴答等配置，然後再用 RT 樹使維護變得複雜。
相容性也需要考慮：一些 驅動程式和子系統尚未完全適應即時 可能需要特定版本或額外的補丁。明智的做法是製定維護計劃，明確規定何時以及如何將主核心的新版本與RT分支整合。 RT分支會定期同步，但仍會略微滯後。
CPU調度調優、無滴答運作和核心隔離
除了選擇搶佔模型之外，您還可以透過調整 CPU 調度和核心計時器行為來微調延遲，尤其是在像 RHEL 這樣的面向企業的發行版中。
例如，Red Hat Enterprise Linux 8 自帶一個 預設情況下，空閒 CPU 的核心不會進行滴答操作。這樣可以避免核心空閒時週期性中斷，進而降低能耗。可以啟用針對延遲敏感型工作負載的模式。 一組核心中的動態無滴答這樣，就只有一個 CPU（「主核心」）處理大部分基於時間的任務，其餘的 CPU 則盡可能避免週期性中斷。
這種配置是透過添加適當的參數來完成的。 GRUB中的核心命令列重新產生配置，然後調整關鍵內核執行緒（例如 RCU 執行緒或執行緒）的親和力 bdi-flush以便它們能夠駐留在為維護而預留的核心區域。
這種方法可以與參數結合使用。 異構CPU這樣可以將核心與普通用戶空間任務隔離。在低延遲場景中，通常會預留幾個核心專門用於關鍵應用程序，而係統的其餘部分（守護進程、中斷等）則由其他核心處理。
為了驗證動態無滴答模式是否正常運作，可以執行簡單的測試。 stress 或者編寫腳本，讓 CPU 保持忙碌一秒鐘，然後觀察結果。 計時器滴答計數器 在孤立的核心中，每秒中斷次數從數千次驟降至僅一次，這表示週期性定時器已經消失。
記憶體和儲存管理，重點關注延遲
核心管理記憶體和磁碟 I/O 的方式對效能有著巨大的影響。 應用程式感知到的延遲尤其是在執行許多小型且頻繁操作的資料庫和服務中。
在記憶體方面，減少 虛擬機交換性 盡量減少交換空間的使用（交換空間幾乎總是比記憶體慢得多）， vm.vfs_cache_壓 它控制系統清除 inode 和 dentry 快取的速度，以及 vm.nr_hugepages 它允許為資料庫或 JVM 等高負載保留靜態 HugePages，從而減少 TLB 開銷。
在儲存方面，選擇 根據磁碟類型選擇合適的 I/O 調度器 這至關重要。在現代固態硬碟上，通常最好使用… none o mq-deadline而在機械磁碟和多任務系統中，為公平性而設計的演算法可能更好，例如： Bfq此外，還可以使用諸如以下選項掛載檔案系統： noatime y nodiratime 避免每次存取檔案或目錄時都進行不必要的寫入。
關於檔案系統， ext4 和 XFS 這些仍然是最常見的選擇：經過良好調優的 ext4 檔案系統是穩妥之選，而 XFS 在高並發場景下往往具有更好的擴展性。對於要求極高的場景，將 RAID（資料庫使用 RAID 10，臨時儲存使用 RAID 0）與優秀的調度器結合使用，可以降低平均延遲，尤其能有效降低延遲波動。
Linux 和 EC2 中的網路和核心最佳化，以實現低延遲
在高效能網路應用中，延遲不僅取決於硬體或距離，還取決於… TCP/IP協定棧和核心本身的設定方式這一點在像 Amazon EC2 這樣具有 ENA 介面的雲端執行個體中尤其明顯。
首先，關鍵在於減少外在因素，例如…的數量 網路跳數 軟體套件的效能體現在：使用更直接的拓撲結構、靠近後端的負載平衡器或最佳化的可用區，甚至可以在接觸作業系統之前，將傳輸時間減少幾毫秒。
在核心中，網路配置涉及增加 檔案描述符（ulimit -n）調整接收和發送緩衝區的大小 net.core.rmem_max、net.core.wmem_max、net.ipv4.tcp_rmem、net.ipv4.tcp_wmem並啟動以下選項： TCP 快速開啟 減少連線建立延遲。
在 AWS ENA 介面中，中斷調節發揮重要作用：預設情況下，驅動程式將封包分組以減少 IRQ 的數量。 接收微秒和發送微秒如果您想將延遲降至最低，可以透過以下方式停用此功能： ethtool -C將 rx-usecs 和 tx-usecs 設定為零可以降低延遲，但會增加中斷開銷，因此必須根據負載找到一個平衡點。
它也可以使用 irqbalance 用於將 IRQ 分配到多個核心上或停用它，並手動將中斷和網路佇列 (RSS/RPS) 親和性設定為特定核心，這在超低延遲環境或使用 DPDK 並跳過核心堆疊的大部分時非常典型。
另一個需要考慮的參數是 CPU C 狀態深度睡眠狀態可以降低功耗，但會在核心「喚醒」時引入延遲。為了減少反應延遲，您可以限制深度睡眠狀態的持續時間，但這會造成更高的功耗，並降低其他核心睿頻加速的可用空間。每種環境都有其最佳的功耗和延遲之間的平衡點。
優化 CPU、服務和應用程式以降低延遲
除了核心本身之外，周圍環境對整體延遲也有很大影響：從 系統中的活躍服務 具體到每個應用程式的具體配置。
高效能伺服器應該只運行 真正必要的惡魔後端機器上的藍牙、列印或網路自動發現（CUPS、Avahi 等）等服務只會消耗 CPU、記憶體和 I/O 資源，而不會帶來任何實際好處。 systemctl list-unit-files --state=enabled 停用不必要的功能是最便宜、最有效的方法之一。
為了優先處理關鍵流程，您可以使用以下工具： renice、chrt 和 taskset調整進程的優先權（renice）、賦予其實時排程（chrt -f 99）或將其指派給特定核心（taskset）可以減少對其他任務的干擾，從而提高資料庫、VoIP、串流或交易服務的 CPU 可預測性。
在應用層，調優與內核調優同等重要。例如，Web 伺服器 Nginx 或 Apache 他們需要對工作進程、保持連線機制、快取和壓縮進行微調。資料庫如 PostgreSQL 或 MySQL 他們需要審查緩衝區大小、檢查點、連接池和同步寫入參數，以實現低而穩定的延遲。
JVM 也發揮作用：選擇垃圾回收器，例如 G1GC 或 ZGC 調整堆大小可以減少暫停，從外部視角來看，這些暫停錶現為延遲。在虛擬化和容器化環境中，合理的記憶體分配至關重要。 虛擬CPU、虛擬記憶體和I/O配額 它避免了無聲爭用，而這種爭用之後會在磁碟上表現為無盡的隊列或 CPU 飽和。
核心和系統監控與基準測試
如果不衡量其影響，所有這些調整都毫無意義。關鍵在於綜合運用。 透過可復現的性能測試進行持續監測。這樣，對核心或 sysctl 的每一次變更都可以用客觀資料進行評估。
要查看系統的整體狀態，您可以使用以下經典工具： htop、vmstat、iotop o sar當您需要更多詳細資訊時，就需要使用特定的核心工具，例如 perf 和 ftrace這使您可以相當準確地追蹤調度程序、中斷和內部呼叫的行為。
在生產環境中，建議部署諸如以下的指標系統。 Prometheus、collectd 或 sysstat 以及導出器 它可以顯示 CPU 計數器、I/O、磁碟和網路延遲、進程佇列等資訊。這些數據在 Grafana 或類似工具中可視化，有助於在最終用戶注意到問題之前檢測到回歸或異常情況。
對於基準測試而言，其理念是複製實際工作負載，並比較每次變更前後的結果。諸如此類的工具 系統工作台 （適用於CPU和資料庫） FIO （用於光碟） iperf3 （對於網路而言）它們允許建立可重複的場景。文件記錄至關重要。 核心版本、sysctl 配置、硬體和測試參數 這樣，隨著時間的推移，比較結果才有意義。
實際上，Linux 核心最佳化是一個迭代過程：你需要測試一系列調整，衡量結果，保留真正有效的調整，並捨棄其餘部分。透過良好的變更管理，你可以將新核心版本（例如最近幾個版本在調度器、圖形、電源或網路方面的改進）中的提升轉化為應用程式可衡量的效能收益，無論這些應用程式部署在本地伺服器、雲端還是高要求的工作站上。
核心架構知識、使用 sysctl 進行微調、受控編譯、選擇性地使用即時修補程式以及良好的指標體系相結合，能夠幫助管理員或維運團隊實現以下目標： 更快的反應速度、更低的延遲和更高的整體穩定性 無需因輕微挑釁而更換硬件，也不會損害系統安全。
