- 對 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 和 1GB 記憶體的老式上網本，在這種情況下，安裝一個包含大量不必要驅動程式和伺服器級選項的現代通用內核，會引入你無法承受的延遲和額外的 CPU 佔用。
一種常見的策略是從目前的核心配置開始（例如，從 /boot 目錄複製設定檔），然後對其進行修剪或調整。您可以將搶佔模型變更為「搶佔式核心（低延遲桌面）」以優先處理桌面的互動式回應，或新增特定的 I/O 調度器（例如BFQ）作為模組，以改善在機械硬碟上的體驗。
為了避免耗費大量編譯時間，最好在效能更強的機器上進行編譯，必要時可以使用交叉編譯（例如，只需調整架構和相應的工具鏈，即可從 x86_64 PC 為 Atom 編譯 32 位元核心）。然後，只需在目標機器上安裝 .deb 文件，並在 GRUB 中新增相應的啟動項目即可。
棘手的部分是維護：建議在 Canary Islands 節點上測試新內核，在啟動管理器中設置清晰的回滾路徑，並在過渡期間記錄日誌和指標，以檢測效能或驅動程式相容性方面的退化。
低延遲系統的搶佔模型和 PREEMPT_RT 補丁
核心的搶佔模型決定了正在運行的任務可以中斷多少次，以便讓優先權更高的任務接管，這直接影響回應延遲。這包括標準配置選項和即時補丁。
通用核心提供多種選項：無搶佔（更注重伺服器吞吐量）、自願搶佔以及面向桌面系統的可搶佔內核，後者優先考慮互動式應用程式的快速回應時間。調整此設定可以顯著提升桌面系統、音訊應用程式甚至老舊、高負載機器的效能。
當您需要更進一步時，可以使用PREEMPT 和 PREEMPT_RT 補丁，它們會修改內核的重要部分，以最大限度地減少不可搶佔的部分。 PREEMPT_RT 適用於最壞情況延遲（而不僅僅是平均延遲）必須非常低且可預測的系統，例如工業自動化、專業音訊、電信或高頻交易。
引入 PREEMPT_RT 的決定不應基於趨勢，而應基於延遲和抖動的特定測量結果。首先，建議在引入 RT 樹增加維護複雜性之前，先充分探索調度器設定、CPU 親和性、sysctl 以及（如果適用）動態無滴答等配置。
相容性也必須考慮在內：某些驅動程式和子系統尚未完全適配 RT，可能需要特定版本或額外的修補程式。明智的做法是製定維護計劃，明確規定何時以及如何將主核心的新版本與 RT 分支整合。 RT 分支雖然會定期同步，但仍有一定的延遲。
CPU調度調優、無滴答運作和核心隔離
除了選擇搶佔模型之外，您還可以透過調整 CPU 調度和核心計時器行為來微調延遲，尤其是在像 RHEL 這樣的面向企業的發行版中。
例如，Red Hat Enterprise Linux 8預設配備了一個用於空閒 CPU 的無滴答內核，透過避免核心空閒時的週期性中斷來降低功耗。對於對延遲敏感的工作負載，可以在一組核心上啟用動態無滴答模式，這樣就只有一個 CPU（「主核心」）處理大部分計時任務，而其餘 CPU 則盡可能避免週期性中斷。
這種配置是透過添加適當的參數來完成的。 GRUB中的核心命令列重新產生配置，然後調整關鍵內核執行緒（例如 RCU 執行緒或執行緒）的親和力 bdi-flush以便它們能夠駐留在為維護而預留的核心區域。
這種方法可以配合`isolcpus`參數使用，該參數允許將核心與普通用戶空間任務隔離。在低延遲場景中，通常會預留幾個核心專門用於關鍵應用程序，而係統的其餘部分（守護進程、中斷等）則由其他核心處理。
為了驗證動態無滴答模式是否正常運作，可以執行簡單的測試。 stress 或者編寫腳本，讓 CPU 保持忙碌一秒鐘，然後觀察結果。 計時器滴答計數器 在孤立的核心中，每秒中斷次數從數千次驟降至僅一次，這表示週期性定時器已經消失。
記憶體和儲存管理，重點關注延遲
核心管理記憶體和磁碟 I/O 的方式對應用程式感知到的延遲有巨大的影響，尤其是在資料庫和服務中，這些資料庫和服務會執行許多小的、頻繁的操作。
在記憶體方面，降低vm.swappiness可以最大限度地減少交換空間的使用（交換空間的使用速度幾乎總是比 RAM 慢得多），vm.vfs_cache_pressure可以控制系統釋放 inode 和 dentry 快取的速度，而vm.nr_hugepages允許您為資料庫或 JVMuge 等高銷負載保留靜態 HPages，從而減少 TLB 開銷負載。
在儲存方面，選擇 根據磁碟類型選擇合適的 I/O 調度器 這至關重要。在現代固態硬碟上，通常最好使用… none o mq-deadline而在機械磁碟和多任務系統中，為公平性而設計的演算法可能更好，例如： Bfq此外，還可以使用諸如以下選項掛載檔案系統： noatime y nodiratime 避免每次存取檔案或目錄時都進行不必要的寫入。
就檔案系統而言，ext4 和 XFS仍然是最常見的選擇：經過良好調優的 ext4 是一個穩健的選擇，而 XFS 在高並發情況下往往具有更好的擴展性。對於要求極高的場景，將 RAID（資料庫使用 RAID 10，臨時暫存儲存使用 RAID 0）與優秀的調度器結合使用，可以降低平均延遲，尤其能夠顯著降低延遲波動。
Linux 和 EC2 中的網路和核心最佳化，以實現低延遲
在高效能網路應用中，延遲不僅取決於硬體或距離，還取決於TCP/IP 協定堆疊和核心本身的配置方式。這一點在配備 ENA 介面的雲端執行個體（例如 Amazon EC2）上尤其明顯。
首先，關鍵在於減少外部因素，例如資料包的網路跳數：使用更直接的拓撲結構、靠近後端的負載平衡器或最佳化的可用區，可以在資料包到達作業系統之前，以毫秒級的速度減少傳輸時間。
在核心中，網路配置涉及增加檔案描述符（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 使用率可預測性。
在應用層，調優與內核調優同等重要。像Nginx 或 Apache這樣的 Web 伺服器需要對工作進程、Keepalive 機制、快取和壓縮進行微調。像PostgreSQL 或 MySQL這樣的資料庫則需要審查緩衝區大小、檢查點、連接池和同步寫入參數，以實現低延遲和穩定的延遲。
JVM 也發揮重要作用：選擇G1GC 或 ZGC等垃圾回收器並調整堆疊大小可以減少暫停，這些暫停從外部表現為延遲。在虛擬化和容器化環境中，合理分配vCPU、vRAM 和 I/O 配額可防止靜默爭用，而靜默爭用最終會導致磁碟佇列無限成長或 CPU 過載。
核心和系統監控與基準測試
如果不衡量其影響，所有這些調優都毫無意義。關鍵在於將持續監控與可複現的效能測試結合，以便能夠用客觀數據評估核心或系統控制項的每一次變更。
要查看系統的整體狀態，您可以使用以下經典工具： htop、vmstat、iotop o sar當您需要更多詳細資訊時，就需要使用特定的核心工具，例如 perf 和 ftrace這使您可以相當準確地追蹤調度程序、中斷和內部呼叫的行為。
在生產環境中，建議部署Prometheus、collectd 或 sysstat 等指標系統，並配備導出器來公開 CPU 計數器、I/O、磁碟和網路延遲、進程佇列等資訊。使用 Grafana 或類似工具視覺化這些數據，有助於在最終用戶注意到問題之前檢測到回歸或異常情況。
對於基準測試，其理念是複現實際工作負載，並比較每次變更前後的效能差異。諸如sysbench（用於 CPU 和資料庫）、fio（用於磁碟）或iperf3 （用於網路）之類的工具可以幫助您建立可重複的測試場景。記錄核心版本、sysctl 配置、硬體和測試參數至關重要，這樣才能確保比較結果在長期使用中仍然有效。
實際上，Linux 核心最佳化是一個迭代過程：你需要測試一系列調整，衡量結果，保留真正有效的調整，並捨棄其餘部分。透過良好的變更管理，你可以將新核心版本（例如最近幾個版本在調度器、圖形、電源或網路方面的改進）中的提升轉化為應用程式可衡量的效能收益，無論這些應用程式部署在本地伺服器、雲端還是高要求的工作站上。
核心架構知識、使用 sysctl 進行微調、受控編譯、選擇性地使用即時修補程式以及良好的指標體系相結合，使管理員或維運團隊能夠實現更快的響應速度、更低的延遲和更好的整體穩定性，而無需在受到任何輕微刺激時就更換硬體或損害系統安全。
