Show Table of Contents
章 3. CPU
本章節將說明 CPU 硬碟的細節以及影響 Red Hat Enterprise Linux 7 效能的設定選項。〈 節 3.1, “注意事項” 〉針對與 CPU 相關且影響效能的因素作討論。〈節 3.2, “監視與診斷效能問題”〉 教您如何使用 Red Hat Enterprise Linux 7 的工具來診斷與 CPU 有關的效能問題以及設定細節。〈 節 3.3, “配置建議”〉討論在 Red Hat Enterprise Linux 7 中有哪些工具和策略可以用來解決因 CPU 引起的效能問題。
3.1. 注意事項
請詳讀以便了解以下因素如何影響系統以及應用程式的效能:
- 各處理器之間連接的方式,以及和記憶體這種相關資源連接的方式。
- 處理器如何排程執行緒執行指令。
- 處理器如何處理 Red Hat Enterprise Linux 7 的插斷現象。
3.1.1. 系統拓樸
在現代的電腦科學中,「中央」處理器的意思很模糊,因為現在大部分的系統都有多個處理器。這些處理器之間,如何連接以及如何與其他系統資源連接,會大大影響系統效能以及微調系統時該注意的事項,而這個相互連接的過程稱為系統「拓樸」。
現代電腦科學主要應用的拓樸有兩種:
- SMP 拓樸(對稱多處理器拓樸)
- SMP 拓樸讓各處理器得以在相同時間內存取記憶體。但是,存取共用記憶體本來就會強制存取所有 CPU 內序列化的記憶體,因此現在 SMP 系統的縮放限制普遍不被接受。基於這個原因,所有現代系統的伺服器幾乎都是 NUMA 機型。
- NUMA 拓樸(非一致性記憶體存取拓樸)
- 與 SMP 拓樸相比,NUMA 拓樸是近期才發展出來的。NUMA 系統中,多個處理器集結在 CPU 插槽。每個 CPU 插槽皆有一個特定區域用來儲存記憶體,而存取該記憶體的處理器統稱為一個節點。在同一節點上的處理器可以快速地連接到該節點的記憶體插槽,但是如果要連到其他節點的記憶體插槽,速度會比較慢。因此,取得遠端記憶體時效能會受到影響。為避免影響效能,使用 NUMA 拓樸的效能相關程式應該取得的是與執行中的處理器同一個節點上的記憶體,並且盡量避免存取遠端記憶體。當您微調使用 NUMA 拓樸的系統的程式效能,要考慮此程式執行的位置,還要考慮哪一個記憶體區塊離執行點最接近。在使用 NUMA 拓樸的系統中,「
/sys」 檔案系統包含了關於處理器、記憶體和周邊裝置互連接方式的資訊。「/sys/devices/system/cpu」目錄包含系統內的處理器互相連接的方式。「/sys/devices/system/cpu」目錄則包含系統內 NUMA 節點的資訊以及這些節點之間的相對距離。
3.1.1.1. 確定系統拓樸
有一些指令可以幫助您了解您所使用的系統拓樸。「
numactl --hardware」這個指令介紹您的系統拓樸的概觀。
$ numactl --hardware available: 4 nodes (0-3) node 0 cpus: 0 4 8 12 16 20 24 28 32 36 node 0 size: 65415 MB node 0 free: 43971 MB node 1 cpus: 2 6 10 14 18 22 26 30 34 38 node 1 size: 65536 MB node 1 free: 44321 MB node 2 cpus: 1 5 9 13 17 21 25 29 33 37 node 2 size: 65536 MB node 2 free: 44304 MB node 3 cpus: 3 7 11 15 19 23 27 31 35 39 node 3 size: 65536 MB node 3 free: 44329 MB node distances: node 0 1 2 3 0: 10 21 21 21 1: 21 10 21 21 2: 21 21 10 21 3: 21 21 21 10
「
lscpu」指令是由「util-linux」套件提供。此指令收集 CPU 架構的資訊,例如 CPU 的數目、執行緒、核心、CPU 插槽以及 NUMA 節點。
$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 1 Core(s) per socket: 10 Socket(s): 4 NUMA node(s): 4 Vendor ID: GenuineIntel CPU family: 6 Model: 47 Model name: Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz Stepping: 2 CPU MHz: 2394.204 BogoMIPS: 4787.85 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 30720K NUMA node0 CPU(s): 0,4,8,12,16,20,24,28,32,36 NUMA node1 CPU(s): 2,6,10,14,18,22,26,30,34,38 NUMA node2 CPU(s): 1,5,9,13,17,21,25,29,33,37 NUMA node3 CPU(s): 3,7,11,15,19,23,27,31,35,39
「
lstopo」指令是由「hwloc」套件提供。這個指令以圖形方式呈現您的系統。「lstopo-no-graphics」指令提供詳細的文字輸出。

lstopo 指令輸出
3.1.2. 排程
Red Hat Enterprise Linux 裡最小的程序執行單元是「執行緒」。系統的排程器決定各處理器執行的執行緒,以及執行執行緒的時間。但是,由於排程器最主要的任務是要讓系統忙碌,所以它可能不會為了應用程式的效能而最佳排程執行緒。
舉例來說,假如一個裝有 NUMA 系統的應用程式在 A 節點上執行,而此時 B 節點的處理器可以被使用,排程器會把其它應用程式上的一個執行緒移到 B 節點,移到 B 節點的執行緒仍然需要取得 A 節點的記憶體。這會花比較久的時間,因為此執行緒現在於 B 節點執行,A 節點的記憶體對它而言屬於遠端的記憶體。與其等 B 節點的執行緒執行完畢,比較省時間的作法是保持原狀,等 A 節點的處理器執行完畢,然後執行原節點上的執行緒,因為它能取得本機的記憶體。
程式設計者或是管理者決定執行緒執行的位置,讓效能敏感的應用程式達到最高效能。欲了解執行緒的排程是否對效能相關程式有所幫助,請見〈節 3.3.6, “微調排程原則”〉
3.1.2.1. kernel tick
在之前的 Red Hat Enterprise Linux 版本中,為了檢查有哪些未完成的工作,Linux kernel 會定期插斷每一個 CPU。kernel 依據檢查的結果排程處理程序以及負載平衡。這個固定的插斷被稱為 kernel「 tick」。
無論核心有沒有工作要執行,tick 都會發生。意思是,閒置核心為了回應插斷,每隔一段時間就會被迫進入高功率狀態 ( 每秒高達一千次 )。這個情形讓系統無法有效率地使用最近幾代 x86 處理器當中的深層睡眠狀態。
Red Hat Enterprise Linux 6 和 7 將 kernel 預設為不打擾閒置 CPU。這讓系統處在低電源狀態,而這種設定被稱為 tickless kernel 。當系統只有少數核心在工作時,隨選插斷會取代定期插斷,CPU 可以因此省電,保持在低電源或是閒置狀態。
Red Hat Enterprise Linux 7 提供動態 tickless 選項(「
nohz_full」),減少 kernel 干擾使用者空間的工作所造成的影響。這個選項可以在有「nohz_full」參數的核心中被使用。此選項一旦在核心被啟用,全部計時的活動皆會移到非延遲敏感的核心。這對高效能運算和即時運算的工作負載是很有用的,因為在使用者空間的工作對與 kernel tick 相關的微秒程度延遲特別敏感。
欲了解如何使用 Red Hat Enterprise Linux 7 動態 tickless 行為的方法,請見〈 節 3.3.1, “設定 kernel tick 的時間”〉。
3.1.3. IRQ 處理
插斷要求(IRQ)是一個從硬體傳送到處理器的即時訊號。系統當中的每一個裝置都被指派至少一個 IRQ 數字來傳送特定插斷。當系統被插斷,接收插斷要求的處理器為了解決插斷要求,會立刻暫停執行當前應用程式的執行緒。
由於一般操作被插斷,這樣的高插斷率會嚴重影響系統效能。透過插斷親和性的設定或者分批傳送較低優先順序的插斷(「聯合」 一些插斷)來減少插斷的時間是可行的。
欲了解微調插斷要求的資訊請見 〈節 3.3.7, “設定插斷親和性”〉 或〈 節 3.3.8, “用 Tuna 來配置 CPU、執行緒,以及插斷親和性”〉。 欲了解特定網路插斷的資訊請見〈章 6, 網路功能〉。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.