目錄
第一篇：虛擬化環境下 CPU 利用率的監控與探究
普通 LPAR CPU 利用率的查看 在 AIX 操作系統中，可以監控 CPU 利用率的命令有很多，最常用的 nmon、topas、vmstat、sar –u 等等。 在單 CPU 線程（SMT OFF），單線程應用的環境下，CPU 利用率的輸出結果很容易看懂，如下：User% 代表系統中用戶進程占用的 CPU 比率；Sys% 代表系統調用所占的 CPU 比率，Wait% 代表等待 I/O 響應的 CPU 比率，Idle% 代表空閑 CPU 的比率。下面我們將主要分析在微分區中，CPU 的調度原理以及監控方法，以及在多 CPU 線程和多線程應用的環境下，監控 CPU 利用率的方法。 CPU User% Sys% Wait% Idle%| 0 0.0 1.0 1.0 98.0|> 1 0.0 0.0 0.0 100.0|> 2 0.0 20.0 0.0 80.0|ssssssssss> 3 0.0 10.0 0.0 90.0|sssss> 4 0.0 4.1 1.0 94.8|ss> 5 0.0 0.0 0.0 100.0|> 6 0.0 10.0 0.0 90.0|sssss> 7 0.0 30.0 0.0 70.0|s 回頁首 微分區 CPU 利用率以及調度的探究 微分區概要文件的設置規則 在創建分區的時候，選擇創建共享 CPU 分區，如下圖： 圖 1. 創建共享 CPU 分區 圖 1. 創建共享 CPU 分區 在接下來的頁面中，需要設置虛擬 CPU 和物理 CPU 的數量： 圖 2. 設置虛擬 CPU 和共享 CPU 的數量。 圖 2. 設置虛擬 CPU 和共享 CPU 的數量。
關於上圖幾個數值，這里需要詳細說明。 我們知道，在當前的 PowerVM 版本中，一個虛擬 CPU 最多可以調度 1 個物理 CPU。在概要文件的設置中，我們既不能將虛擬處理器設置的太多，這樣會造成過多的 CPU 上下文切換；也不能將其設置的過低，那樣微分區將不能調度或者獲取足夠的物理 CPU。
物理 CPU 的“最小處理單元數”、“ 期望處理單元數”、“ 最大處理單元數”的含義與普通 LPAR 沒有區別，分別代表“激活分區所需的最少物理 CPU 資源”、“激活分區時期望獲取的物理 CPU 資源”、“分區可以獲得最多物理 CPU 資源”。就普通 LPAR 而言，一個分區激活以后，其自動獲取的 CPU 資源處於“大於等於“最小處理單元數”、小於等於“ 期望處理單元數”的閉區間內”。“最大處理單元數”的設置數值，是手工對分區做 DLPAR 操作時，LPAR 可以增加到的最多 CPU 數量。
虛擬 CPU 的“最小虛擬處理器數”、“ 期望虛擬處理器數”、“ 最大虛擬處理器數”的含義分別為：“激活分區所需的最少虛擬 CPU 數量”、“激活分區時期望獲取的虛擬 CPU 數量”、“分區可以獲得最多虛擬 CPU 數量”。從概念的描述上看，虛擬 CPU 的數值含義似乎無太大的差別，只是多了“虛擬”兩個字，實際上區別很大。實際上，虛擬 CPU 的數量我們可以設置的很大，因為這個較大數值不會給客戶帶來成本，而事實上，虛擬 CPU 實際上也不存在不夠用的情況，除非我們將其設置得過小，而共享 CPU 池中的空閑物理 CPU 很多。
微分區的意義在於降低 CPU 的空閑率，從而降低客戶的 IT 成本。因此，在這種情況下，我們通常將 對等的虛擬 CPU 的數量設置的比物理 CPU 的數量要高，否則就失去了微分區意義。
專用 CPU 分區的 CPU 共享功能
在 PowerVM 中，專用 CPU 分區在其 CPU 空閑的時候，也可以將其空閑的 CPU 處理能力分給 CPU 共享池。
這個功能的打開與關閉，由如下兩個系統參數控制，我們一般將兩個參數的數值設置相同 : smt_snooze_delay：控制 CPU 的第 1 個、第 2 個線程的釋放時間。 smt_tertiary_snooze_delay：控制 CPU 的第 3 個、第 4 個線程的釋放時間。 這兩個參數的含義是：當 Hypervisor 發現專用 CPU 分區 CPU 空閑的時候，將空閑的 CPU 分給 CPU 共享池使用的 delay 時間，如果這個數值設置為 0，則表示沒有延遲，即立刻將空閑 CPU 共享給 CPU 共享池；設置為 -1，表示關閉此功能；如果將數值設置成 0-100000000 之前的數值，則表示延遲的微秒數，數字越大，延遲越大，CPU 共享池能獲取到的專用 CPU 分區的空閑 CPU 的時間就更長。 在系統中，我們用 schedo -h 命令可以查看兩個參數的含義： #schedo -h smt_snooze_delay Help for tunable smt_snooze_delay: Purpose: Amount of time in microseconds in idle loop without useful work before snoozing (calling h_cede). Values: Default: 0 Range: -1 - 100000000 Type: Dynamic Unit: microsecs Tuning: A value of -1 indicates to disable snoozing, a value of 0 indicates to snooze immediately. The maximum value of 100000000 corresponds to 100 seconds. atsnfs[/atspersonal/weixinyu/123]# #schedo -h smt_tertiary_snooze_delay Help for tunable smt_tertiary_snooze_delay: Purpose: Amount of time in microseconds in idle loop on tertiary thread without useful work before snoozing (calling h_cede). Values: Default: 0 Range: -1 - 100000000 Type: Dynamic Unit: microsecs Tuning: A value of -1 indicates to disable snoozing, a value of 0 indicates to snooze immediately. The maximum value of 100000000 corresponds to 100 seconds.
微分區“處理器折疊”（Processor Folding）功能
在 PowerVM 的微分區環境下，PowerVM Hypervisor 負責虛擬 CPU 的調度。 我們繼續上一小節中關於設置微分區概要文件的例子，假設我們將概要文件中虛擬 CPU 的數量設置的比物理 CPU 數量多（實際上這樣才有意義）。
在微分區中，系統在 CPU 利用率低的時候，可以關閉一些虛擬 CPU，以減少 CPU 上下文切換，降低系統開銷，從而提高性能；而當 CPU 利用率很高，系統將會相應地啟用被關閉的 CPU，這個功能被成為“處理器折疊”(Processor Folding) 功能，它主要由如下參數決定： # schedo -o vpm_xvcpus vpm_xvcpus = 0 vpm_xvcpus 可調參數的缺省值是 0，表示啟用了折疊 (Processor Folding) 功能。這意味着虛擬處理器正接受管理。 # schedo -o vpm_fold_policy vpm_fold_policy = 1 可以根據分區是共享處理器分區還是專用處理器分區來啟用或禁用“處理器折疊” (Processor Folding) 這一虛擬處理器管理功能。另外，當分區處於靜態省電方式時，將對共享處理器分區或專用處理器分區自動啟用處理器折疊功能 (Processor Folding) 。 vpm_fold_policy參數有三個設置功能位： 設置為 1 時，此位表明啟用處理器折疊功能（如果分區正在使用共享處理器）。 設置為 2 時，此位表明啟用處理器折疊功能（如果分區正在使用專用處理器）。 設置為 4 時，如果分區處於靜態省電方式，那么此位將禁止自動設置處理器折疊功能。 對於微分區的環境下，vpm_xvcpus 為 0，vpm_fold_policy設置為 1 即可，我們不需要對兩個參數的默認數值進行修改。 例如，我們有一個分區，虛擬 CPU 的數量是 6，物理 CPU 的資源是 0.6： 圖 3. 利用 DLPAR 查看分區配置 圖 3. 利用 DLPAR 查看分區配置 此時，系統十分空閑： 系統十分空閑 查看到系統中虛擬 CPU 的數量： # prtconf |grep "Number Of Processors" Number Of Processors: 6 查看到由於系統開啟了 SMT-4，因此系統中邏輯 CPU 的數量為 24 # vmstat 1 5 System configuration: lcpu=24 mem=4096MB ent=0.60 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------------------- r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec 0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.02 2.6 0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 2.2 0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 2.0 0 0 295379 699293 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 1.9 0 0 295379 699293 0 0 0 0 0 0 40 152 204 0 1 99 0 0.01 2.1 此時 6 個虛擬 CPU 的 24 個邏輯 CPU 並未完全展開 : # mpstat 1 5 System configuration: lcpu=24 ent=0.6 mode=Uncapped cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc %ec lcs 0 27 0 0 308 280 123 1 4 97 395 10 78 0 12 0.01 1.4 252 1 0 0 0 19 0 0 0 0 - 0 0 4 0 96 0.00 0.4 19 2 0 0 0 19 0 0 0 0 - 0 0 5 0 95 0.00 0.4 19 3 0 0 0 19 0 0 0 0 - 0 0 5 0 95 0.00 0.4 19 4 0 0 0 10 0 0 0 0 - 0 0 6 0 94 0.00 0.0 9 12 0 0 0 4 0 0 0 0 - 0 0 3 0 97 0.00 0.0 3 13 0 0 0 37 0 0 0 0 - 0 0 58 0 42 0.00 0.0 31 16 0 0 0 6 0 0 0 0 - 0 0 8 0 92 0.00 0.0 4 20 0 0 0 12 0 0 0 0 - 0 0 14 0 86 0.00 0.0 10 U - - - - - - - - - - - - 0 99 0.59 99.0 - ALL 27 0 0 434 280 123 1 4 97 395 0 0 0 100 0.02 2.7 366 -------------------------------------------------------------------------------- cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc %ec lcs 0 14 0 0 1104 860 376 4 3 97 1609 8 79 0 13 0.01 1.3 851 1 0 0 0 65 0 0 0 0 - 0 0 6 0 94 0.00 0.4 61 2 0 0 0 61 0 0 0 0 - 0 0 2 0 98 0.00 0.3 61 3 0 0 0 47 0 0 0 0 - 0 0 3 0 97 0.00 0.3 47 4 0 0 0 9 0 0 0 0 - 0 0 75 0 25 0.00 0.0 9 13 0 0 0 116 0 0 0 0 - 0 0 56 0 44 0.00 0.0 98 U - - - - - - - - - - - - 0 98 0.59 97.6 - ALL 14 0 0 1402 860 376 4 3 97 1609 0 1 0 99 0.01 2.4 1127 -------------------------------------------------------------------------------- 如果將 vpm_fold_policy 設置為 4，即關閉該功能，那么 24 個邏輯 CPU 將全部展開： # schedo -o vpm_fold_policy=4 Setting vpm_fold_policy to 4 # mpstat 1 1 System configuration: lcpu=24 ent=0.6 mode=Uncapped cpu min maj mpc int cs ics rq mig lpa sysc us sy wa id pc %ec lcs 0 61 0 0 194 72 41 0 1 100 17 3 83 0 14 0.01 0.9 151 1 63 0 0 9 1 1 0 1 100 0 0 19 0 81 0.00 0.3 11 2 63 0 0 10 1 1 0 1 100 0 0 19 0 81 0.00 0.3 12 3 63 0 0 9 1 1 0 1 100 0 0 19 0 81 0.00 0.3 10 4 59 0 0 20 24 13 0 1 92 0 0 46 0 54 0.00 0.2 24 5 62 0 0 9 1 1 0 1 100 0 0 38 0 62 0.00 0.1 10 6 63 0 0 90 2 2 0 1 100 0 0 48 0 52 0.00 0.1 90 7 58 0 0 9 1 1 0 1 100 0 0 40 0 60 0.00 0.1 10 8 63 0 0 19 1 1 0 1 0 0 0 50 0 50 0.00 0.2 21 9 63 0 0 10 1 1 0 1 100 0 0 42 0 58 0.00 0.1 12 10 62 0 0 9 1 1 0 1 100 0 0 46 0 54 0.00 0.1 11 11 61 0 0 9 1 1 0 1 100 0 0 46 0 54 0.00 0.1 11 12 64 0 0 10 1 1 0 1 100 0 0 42 0 58 0.00 0.1 12 13 45 0 0 25 1 1 0 1 100 0 0 51 0 49 0.00 0.1 24 14 63 0 0 9 1 1 0 1 100 0 0 45 0 55 0.00 0.1 10 15 63 0 0 9 1 1 0 1 0 0 0 48 0 52 0.00 0.1 10 16 62 0 0 15 6 4 0 3 75 17 1 48 0 51 0.00 0.1 18 17 61 0 0 9 1 1 0 1 100 0 0 38 0 62 0.00 0.1 11 18 64 0 0 9 1 1 0 1 100 0 0 42 0 58 0.00 0.1 11 19 59 0 0 10 1 1 0 1 100 0 0 41 0 59 0.00 0.1 12 20 60 0 0 13 102 52 0 1 98 101 19 58 0 23 0.00 0.4 65 21 62 0 0 9 1 1 0 1 0 0 0 31 0 69 0.00 0.2 10 22 61 0 0 10 1 1 0 1 100 0 0 30 0 70 0.00 0.2 12 23 64 0 0 9 1 1 0 1 100 0 0 30 0 70 0.00 0.2 10 U - - - - - - - - - - - - 0 95 0.57 95.4 - ALL 1469 0 0 534 225 131 0 26 96 135 0 2 0 98 0.03 5.0 578 在系統中，還有一個內核參數：vpm_xvcpus。它的作用是控制當微分區 CPU 不足的時候，系統可以自動啟動的微分區的數量。如果將這個值設置為 -1，則表示關閉此功能；若設置為 0，表示啟用了折疊功能 (Processor Folding) 。這意味着虛擬處理器正接受管理，分區啟用了 CPU 折疊功能。默認數值設置為 0，表示分區可以啟用其關閉的虛擬 CPU；如果 vpm_xvcpus 數值設置大於 1，則表示系統不僅可以啟用其關閉的虛擬 CPU，還可以啟動額外的虛擬 CPU，前提是分區的虛擬 CPU 總數不大於分區概要文件最大虛擬 CPU 數量的設置。 atsnfs[/]#schedo -h vpm_xvcpus Help for tunable vpm_xvcpus: Purpose: Setting this tunable to a value greater than -1 will enable the scheduler to enable and disable virtual processors based on the partition's CPU utilization. Values: Default: 0 Range: -1 - 2147483647 Type: Dynamic Unit: processors Tuning: The value specified signifies the number of virtual processors to enable in addition to the virtual processors required to satisfy the workload. 分區需要的虛擬 CPU 的總數 = 物理 CPU 使用數 + 要啟用的更多虛擬處理器的數目。如果所需的虛擬處理器的數目小於當前已啟用的虛擬處理器的數目，則利用分區的 CPU 折疊功能 (Processor Folding) 停用部分虛擬處理器。如果所需的虛擬處理器的數目大於當前已啟用的虛擬處理器的數目，則啟用已禁用的虛擬處理器。連接到已禁用的虛擬處理器的線程仍然能夠在該處理器上運行。
uncapped 分區 CPU 調度
分區激活的時候，會讀取概要文件中物理 CPU“期望處理單元數”的數值，如果可以從 CPU 共享池中獲取到設定的 CPU 資源，則以這個數量的物理 CPU 激活；若能獲取到得物理 CPU 的資源小於概要文件中“最小處理單元數”數值的設置，則無法激活分區；或若能獲取到得物理 CPU 的資源介於“期望處理單元數”和“最小處理單元數”之間，則會以這個數值激活分區。
分區激活以后，系統將會監控 CPU 的利用率，如果每個虛擬 CPU 的利用率都低於 50%，系統將會關閉一些虛擬 CPU，以減少 CPU 的上下文切換。當然，減少后的虛擬 CPU 的數量應不小於物理 CPU 的數量。此時，微分區中物理 CPU 總的利用率超過 50%，那么系統會將關閉的虛擬 CPU 重新打開，以便分區可以獲取到額外的物理 CPU 資源。
我們知道，Power7 服務器 CPU 支持四線程，CPU 的第 2，3，4 個線程在 CPU 空閑的時候是不啟用的。因此，在已獲取的物理 CPU 的第一個線程利用率達 100% 的時候，如果此時 CPU 共享池中有空閑的物理 CPU，系統將會優先啟用被關閉的虛擬 CPU，以便獲取而外的物理 CPU；如果此時 CPU 共享池中沒有可以獲取到的物理 CPU，那么系統首先不會啟用被關閉的虛擬 CPU，而是使用已獲取的物理 CPU 的第 2 個、第 3 個、和第 4 個線程，直到整個物理 CPU 的利用率超過 80%，才會啟用新的虛擬 CPU。
如果一個微分區很繁忙，並且該分區已經獲取的物理 CPU 的數量已經達到該分區設置的期望獲取的虛擬 CPU 的數量，如果條件允許，我們還想給微分區增加物理 CPU 資源的方法是用 DLPAR 增加該分區的虛擬 CPU 的數量，然后該分區會繼續獲取物理 CPU 資源。
所以說，對於一個 uncapped 分區，它能夠自動獲取到的最多物理 CPU 資源，是由概要文件中的“期望虛擬處理器數”決定的。
capped 分區 CPU 調度
對於 capped 分區，虛擬 CPU 的調度與 uncapped 是一樣的。不一樣的是分區自動可以獲取到的最多物理 CPU 的數量是由概要文件中設置的“期望處理單元數”決定的。因為，當微分區以小於“期望處理單元數”的物理 CPU 數量激活以后，即使該分區的 CPU 利用率很高，並且 CPU 共享池中的物理 CPU 很空閑，但是由於概要文件中受限分區的設置，它都無法自動獲取額外的 CPU 資源。在這種情況下，為了環境分區的 CPU 緊張的情況，我們可以通過 DLPAR，手工給分區增加物理 CPU 資源，增加后的物理 CPU 數量不能大於分區的“最大處理單元數”。並且增加后的物理 CPU 數量如果超過了虛擬 CPU 的數量，也是不能添加成功的。
例如，我們有一個微分區，分配的物理 CPU 為 3，虛擬 CPU 為 3： 圖 4.DLPAR 增加 CPU 圖 4.DLPAR 增加 CPU 接下來，我們將物理 CPU 的數量增加到 4，會看到如下報錯： 圖 5.DLPAR 增加 CPU 圖 5.DLPAR 增加 CPU 在這種情況下，就需要同時增加虛擬 CPU 和物理 CPU 的數量： 圖 6.DLPAR 增加 CPU 圖 6.DLPAR 增加 CPU 可以添加成功。 DLPAR 能夠增加到的最大物理 CPU 的數量，是由設置的物理 CPU 的“ 最大處理單元數”決定的。
系統中查看微分區 CPU 相關配置 在微分區中，我們可以使用 lpatsta – i 命令准確地查看分區 CPU 和內存的相關配置信息。
# lparstat -i Type : Shared-SMT-4 表示分區為共享 CPU 分區，開啟了 SMT-4. Mode : Uncapped 表示本分區為 uncapped 分區 Entitled Capacity : 1.00 表示本分區目前獲取到的物理 CPU 的數量
Online Virtual CPUs : 6 表示本分區目前的虛擬 CPU 數量 Maximum Virtual CPUs : 8 表示概要文件設置的分區最大虛擬 CPU 的數量 Minimum Virtual CPUs : 1 表示概要文件設置的分區最小虛擬 CPU 的數量 Variable Capacity Weight : 255 表示分區的 weight 數值，255 為最高值 Minimum Capacity : 0.10 表示概要文件設置的分區最小物理 CPU 的數量 Maximum Capacity : 1.00 表示概要文件設置的分區最大物理 CPU 的數量 Capacity Increment : 0.01 表示物理 CPU 的數量的增量 Maximum Physical CPUs in system : 8 表示本物理服務器中物理 CPU 的數量 Active Physical CPUs in system : 8 表示本物理服務器中活動的物理 CPU 的數量 Active CPUs in Pool : 6 表示 CPU 共享池可以分配給本分區的最多物理 CPU 的數量 Shared Physical CPUs in system : 6 表示所有共享 CPU 分區使用的物理 CPU 的數量
我們也可以通過登陸 HMC 查看對應項的數值。 圖 7. 查看服務器 CPU 配置 圖 7. 查看服務器 CPU 配置 查看分區的概要文件： 圖 8. 查看分區概要文件 圖 8. 查看分區概要文件 所以，針對本案例，通過上面 lpatstat-i 的輸出，我們可以得到幾個重要的信息；當前分區獲取到的物理 CPU 是 1 個，虛擬 CPU 是 6 個，由於開啟了 SMT-4，因此系統有 24 個邏輯 CPU，可以認為系統有 24 個 CPU 線程。 # vmstat 1 System configuration: lcpu=24 mem=4096MB ent=1.00 kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------------------- r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec 0 0 302870 688838 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 1.4 0 0 302870 688837 0 0 0 0 0 0 0 0 0 0 1 99 0 0.01 1.2 0 0 302870 688836 0 0 0 0 0 0 7 57 46 0 1 99 0 0.02 2.0 （微分區）CPU 使用率的監控誤區 繼續上一小節的例子，目前系統有 24 個邏輯 CPU，我寫一個腳本，調用 ncpu 命令，依次發 24 個 cpu 壓力，為了使加壓平緩，將加壓間隔設置為 20 秒： # cat final.sh echo "Begin to Collect the Nmon data " cd /weixinyu;nmon -f -s 1 -c 1000000 echo "Let's Begin CPU press test after 5 seconds!" sleep 5 for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 do echo "Begin The $i*CPU press" ./ncpu -p 1& date sleep 20 done echo "The CPU press will be moved!" ps -e |grep ncpu |awk '{ print $1}' |xargs kill -9 echo "Nmon date will be finished after 5 seconds" echo "No CPU press now" ps -e |grep nmon |awk '{ print $1}' |xargs kill -9 echo "This test has been finished, observe the Nmon data under /weixinyu" # 然后，執行這個腳本： # sh final.sh Begin to Collect the Nmon data Let's Begin CPU press test after 5 seconds! Begin The 1*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:04:25CDT 2012 Begin The 2*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:04:45CDT 2012 Begin The 3*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:05:05CDT 2012 Begin The 4*CPU press Wed Aug 822:05:25CDT 2012 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Begin The 5*CPU press Wed Aug 822:05:45CDT 2012 ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Begin The 6*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:06:05CDT 2012 Begin The 7*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:06:25CDT 2012 Begin The 8*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:06:45CDT 2012 Begin The 9*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:07:05CDT 2012 Begin The 10*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:07:25CDT 2012 Begin The 11*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:07:45CDT 2012 Begin The 12*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:08:05CDT 2012 Begin The 13*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:08:25CDT 2012 Begin The 14*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:08:45CDT 2012 Begin The 15*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:09:05CDT 2012 Begin The 16*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:09:25CDT 2012 Begin The 17*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:09:45CDT 2012 Begin The 18*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:10:05CDT 2012 Begin The 19*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:10:25CDT 2012 Begin The 20*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:10:45CDT 2012 Begin The 21*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:11:06CDT 2012 Begin The 22*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:11:26CDT 2012 Begin The 23*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:11:46CDT 2012 Begin The 24*CPU press ./ncpu - processes=1 snooze=0% hibernate=0 secs forever Wed Aug 822:12:06CDT 2012 The CPU press will be moved! Nmon date will be finished after 5 seconds No CPU press now This test has been finished, observe the Nmon data under /weixinyu 將收集到的 nmon 信息用 nmon analyzer 進行分許，得出的結果如下： 圖 9。查看 Nmon 分析結果 圖 9。查看 Nmon 分析結果 在命令結果的輸出中，我們需要關注幾個時間點，在 22：05 的時候，系統開始第一個 ncpu 的壓力。 從 nmon 結果的另外一個子頁，查看 CPU 線程的利用率，基本上符合在 SMT-4 環境下，系統優先使用第一個線程的原則：CPU005、CPU009、CPU013、CPU017、CPU021 的幾個線程利用率是最高的線程。 圖 10. 查看邏輯 CPU 利用率 圖 10. 查看邏輯 CPU 利用率 查看分區 CPU 運行隊列的數量變化，可以看出是平緩增加的，符合腳本中平緩加壓的規則： 圖 11. 查看 CPU 運行隊列 圖 11. 查看 CPU 運行隊列 從 nmon 結果中截取幾個關鍵時間點的 CPU 利用率，這樣可以很清楚看出 CPU 整體利用率與線程利用率的關系： 表 1. CPU 整體利用率與線程利用率的關系 Time User% Sys% Wait% Idle% CPU% Virtual CPU 22:04:25 61.7 0.2 0 38 61.9 1st 22:04:45 62.2 0.2 0 37.6 62.4 22:05:05 62.3 0.1 0 37.5 62.4 22:05:25 63.8 0.1 0 36.1 63.9 22:05:45 68.5 0.1 0 31.4 68.6 2nd 22:06:05 74.3 0.1 0 25.6 74.4 22:06:25 78.1 0.1 0 21.8 78.2 22:06:45 84.5 0.1 0 15.4 84.6 22:07:05 88.2 0.1 0 11.7 88.3 3rd 22:07:25 88.1 0.1 0 11.8 88.2 22:07:45 84.7 0.1 0 15.2 84.8 22:08:05 85.4 0.1 0 14.5 85.5 22:08:25 83.7 0.1 0 16.3 83.8 4th 22:08:45 91.3 0.1 0 8.6 91.4 22:09:05 88 0.1 0 11.9 88.1 22:09:25 92.3 0.1 0 7.6 92.4 22:09:45 92.3 0.1 0 7.7 92.4 5th 22:10:05 91.9 0.5 0 7.6 92.4 22:10:25 94 0.1 0 6 94.1 22:10:45 96 0.1 0 4 96.1 22:11:05 98 0.1 0 2 98.1 6th 22:11:25 99.9 0.1 0 0 100 22:11:45 99.9 0.1 0 0 100 22:12:05 99.9 0.1 0 0 100 得出的結論是，對於一個開了 SMT-4 的 CPU，我們壓滿其第 1 個線程與將 4 個線程都壓滿，操作看到的整體 CPU 利用率沒有太大的變化。 我們還可以得出另外一個結論：壓滿單個 CPU 對於整體 CPU 利用率的增長，並不是線性關系，與 CPU 數量的比率也不匹配，如下表： 表 2 測試場景中系統整體 CPU 利用率 按照 CPU 數量比計算的理論 CPU 利用率 壓滿第 1 個 CPU，系統整體 CPU 利用率大約為：63% 1/6 即 17% 壓滿第 2 個 CPU，系統整體 CPU 利用率大約為：84% 2/6 即 33.3% 壓滿第 3 個 CPU，系統整體 CPU 利用率大約為：85% 3/6 即 50% 壓滿第 4 個 CPU，系統整體 CPU 利用率大約為：92% 4/6 即 66.7% 壓滿第 5 個 CPU，系統整體 CPU 利用率大約為：96% 5/6 即 83.3% 壓滿第 6 個 CPU，系統整體 CPU 利用率大約為：100% 因此，在多線程應用和開啟系統多線程的環境下，我們在監控 CPU 利用率的時候，在衡量系統還能增加多少業務量的時候，不能簡單地根據某一條系統命令看到的 CPU 空閑值來衡量。 微分區 CPU 使用率的監控 我們可以通過設置微分區的屬性，將其“允許性能信息收集”的選項打開： 圖 12. 設置分區屬性 圖 12. 設置分區屬性 打開這個參數以后，我們可以用 lparstat 命令監控到更多的 CPU 利用率信息。 如果我們要監控每個 CPU 線程的利用率，可以使用 mpstat 命令。 如果我們要監控整體 CPU 利用率，可以使用 topas 或者 nmon。 但是從我個人來見，在這種多線程 CPU 和多線程應用的環境下，我比較傾向於使用 mpstat 來監控每一個 CPU 的利用率。在下面的輸出結果中，Proc0、Proc4、Proc8、Proc12、Proc16、Proc20 分別代表該系統的 6 個虛擬 CPU，cpu0-cpu23 則代表 24 個邏輯 CPU（每個虛擬 CPU 有 4 個邏輯 CPU）。 # mpstat -s 1 1 System configuration: lcpu=24 ent=1.0 mode=Uncapped Proc0 Proc4 Proc8 1.08% 99.96% 99.96% cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 0.62% 0.16% 0.15% 0.15% 62.14% 12.61% 12.61% 12.61% 62.14% 12.61% 12.61% 12.61% Proc12 Proc16 Proc20 0.00% 0.00% 0.01% cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu18 cpu19 cpu20 cpu21 cpu22 cpu23 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.01% 通過命令的輸出，我們可以看到每一個虛擬 CPU 及其下面 4 個邏輯 CPU 的利用率，這樣就比僅從 nmon 來看系統的整體 CPU 利用率要更為細致。 在性能測試中，對於真實的應用，並不是 CPU 數量越高，CPU 線程數越多，應用的 TPS 就越高。在多線程應用和開啟 CPU 多線程的環境下，我們更多地需要考慮到客戶應用的線程數、系統 CPU 線程數、應用中負責調度的進程數，充分考慮到 CPU 線程數與應用線程數的配比關系。如果 CPU 線程數過多而應用線程數很少，可能會造成系統調度開銷增大，應用性能會下降；如果應用線程數很多而 CPU 線程數不足，又可能造成應用線程調度不開，影響性能。因此，我們有時候需要根據應用的表現來調整 CPU 的數量和 SMT 的設置。 總之，在多線程應用和開啟系統多線程的環境下，我們監控 CPU 利用率，需要考慮到客戶線程的數量以及 CPU 線程數，然后再結合系統的命令進行查看，才能比較准確地預估服務器還能增加多少應用負載。
虛擬CPU、物理CPU、邏輯CPU
查看到系統中虛擬 CPU 的數量：
# prtconf |grep "Number Of Processors" Number Of Processors: 6
查看到由於系統開啟了 SMT-4，因此系統中邏輯 CPU 的數量為 24
# vmstat 1 5 System configuration: lcpu=24 mem=4096MB ent=0.60
此時 6 個虛擬 CPU 的 24 個邏輯 CPU 並未完全展開（“處理器折疊”功能） :
# mpstat 1 5 System configuration: lcpu=24 ent=0.6 mode=Uncapped
第二篇 性能指標之資源指標 CPU利用率的性能分析
本章介紹如何在非虛擬化環境以及虛擬化環境下准確的讀取CPU利用率指標，同時介紹CPU利用率的細分User%、Sys%、Wait%、Idle%各自的含義，以及如何利用它們協助分析性能問題。
總利用率
CPU利用率=用戶態CPU%+系統態CPU%
1.獲取來源
（1）Dedicated模式
Nmon CPU_ALL Sheet：CPU%
命令行topas：usr%+sys%
（2）Sharing模式
若physical CPU沒有超過EC，則采集EC利用率
當Physical CPU<=EC時，EC利用率=（EC_User% + EC_Sys%）/EC值。
Nmon CPU_ALL Sheet：CPU%
或Nmon LPAR Sheet：EC_User% + EC_Sys%
若physical CPU超過EC：
此時若按照EC利用率統計，則CPU利用率很可能超過了100%，出具的測試結果、測試報告容易造成誤解。
此時若按照physical CPU利用率（使用的CPU/physical CPU）統計，分母physical CPU是動態的，因此利用率不具有參考價值。
如果一定要統計CPU利用率，可按照VP利用率統計，VP利用率= VP_User% + VP_Sys%。但需要假設CPU物理Core的個數為VP個數。舉例說明：
假設EC=2，VP=8，EC利用率為200%，VP利用率為50%。在測試報告中描述CPU利用率為50%（CPU為8核，其中EC為2C，借用為借用資源池）。
2.最佳實踐
交易類測試通常在CPU利用率在70%左右，出具系統能夠支撐的最大吞吐量的性能指標。不宜在CPU過高的情況給出性能數據，生產環境CPU 70%會產生CPU報警。並且，CPU過滿的情況下，各類性能數據會產生變形。不宜在CPU過低的情況給出性能數據，CPU過低的情況下，操作系統和系統軟件本身對CPU的消耗占比比較大，若此時統計均攤到每筆業務上的CPU消耗，不太准確。
對於交易類應用，CPU利用率與業務壓力（吞吐量）應成近似線性的比例關系。若CPU利用率不能隨着吞吐量的增加而增加（如：CPU利用率不能達到70%，最多只能達到30%），需從應用、系統軟件、虛擬化配置等方面進行調優。例如：1）應用並發線程數量是否過少，2）消息中間件的隊列管理器數量過少、傳輸通道過少、本地隊列過少，3）虛擬化參數配置中若VP與EC的比值越大，Hypervisor層面的系統調度開銷越大，操作系統獲得的CPU時間片越少，CPU利用率無法隨着吞吐量的增長而增長，響應時間也會延長。
3.CPU利用率觀察取值方法舉例
在壓力測試過程中隨時通過topas命令可以查看CPU的利用率，若沒有達到預期的利用率，說明這次測試的壓力（吞吐量）沒有達到預期，需要馬上分析原因，必要時停止測試，以避免無謂的時間浪費。
同時也可以觀察Physical CPU是否已經超過EC。若超過了，說明當前分配的EC值過低，此時可考慮聯系系統管理員分配更大的EC，以保證能夠出具可靠的性能數據（借用資源池的CPU，沒有EC保障下的CPU性能好）。
Entc指的是Physical CPU除以EC的比值。如上圖，Entc=199.7%，即此時獲得的Physical CPU是EC的約2倍。而此時Physical CPU的值為Physc=1.00，因此可以直接推測EC=0.5。
Topas中的user%和kern%與“Nmon CPU_ALL Sheet“中的user%、sys%類似，它們的和不會超過100%。因此讀數時要注意實際獲得了多少Physical CPU。
下面場景中，CPU參數設置如下
Entitled Capacity（EC）=0.8，VP=2，capped=0。
紅色的線是EC能力。藍色的線是運行時獲得的physical CPU的個數，相當於獲得CPU core的個數。
我們發現，藍色的線已經跑到了紅線上方。說明運行時獲得的physical CPU超過了標稱能力，向CPU資源池進行了借用。
此時CPU_ALL的界面中顯示的CPU總利用率如圖
取某個時間點的CPU_ALL sheet中的CPU數據，15:25:19這個時刻，CPU利用率為60.7%
取LPAR sheet中的CPU數據（隱去不必要的數據）
按理說CPU利用率=User%+Sys%。但60.7%這個數，即不等於EC_User%+EC_Sys%，也不等於VP_User%+VP_Sys%。
因為此時physical CPU>EC, 因此CPU_ALL中顯示的CPU%=使用的CPU/Physical CPU。
以上述數據為例
以EC計算：EC=0.8，EC_User%+EC_Sys% = 87.97%，LPAR相當於使用了0.8 x 0.8797 = 0.70376 個CPU Core
以VP計算：VP=2，VP_User%+VP_Sys%=35.19%，LPAR相當於使用了2 x 0.3519 = 0.7038個CPU Core
以Physical CPU計算：Physical CPU=1.161，CPU%=60.7%，LPAR相當於使用了1.161 x 0.607= 0.704727個CPU Core
三種算法得到相同的結果，說明沒有哪個數據是錯誤的，但由於Physical CPU是波動的，因此CPU_ALL中的CPU%的分母是波動的，此時CPU_ALL sheet中的CPU%不具有統計價值。
Physical CPU>EC的場景，可以采用VP利用率來充當CPU利用率。測試報告中可以描述為CPU利用率35.19%（CPU為2核，其中EC為0.8C，借用資源池1.2C）。
User%
CPU總利用率由用戶態CPU利用率和系統態CPU利用率組成。
1.獲取來源
Nmon CPU_ALL Sheet：user%
命令行topas：user%
2.最佳實踐
對於應用軟件在壓力測試狀態下通常用戶態的CPU占比比較高，而系統態占比比較低。用戶態可以保護底層硬件資源不直接被程序訪問，減少系統crash，所以一般的應用程序跑在用戶態的CPU占比大。
Sys%
1.獲取來源
Nmon CPU_ALL Sheet：sys%
命令行topas：kern%
2.最佳實踐
如果系統態占比比較大，一般有以下幾類原因：
（1）為了追求效率，減少用戶態到系統態的轉換，把用戶態的function改到系統態，例如：一些驅動程序，以顯卡驅動最為常見
（2）系統有IO問題
（3）應用設計問題
3.舉例
通常情況，壓力測試下，用戶態（藍色）和系統態（紅色）的CPU圖形如下：
系統態偏高如下
這種情況下，如何查看是什么進程、什么庫文件、什么函數占用的系統態CPU，后續章節專題介紹。
Wait%
Wait%在不同的場景下含義不同。在CPU的4個細分類型中，Wait%是指CPU等待IO的時間占總時間的百分比。如果在CPU sys態（或kernel態）中的wait%則與此處的wait%含義不同。
1.獲取來源
獲取來源與Usr%類似。
2.最佳實踐
Wait%雖然不會統計進CPU總利用率，但仍然是系統CPU性能指標中偶爾關注的指標。
之所以wait%不會統計進CPU總利用率，因為wait%和idle%比較類似，都是CPU閑置狀態，只不過一個是等IO，一個是等新的任務。
但如果wait%過大，說明CPU等IO的時間長，系統的處理效率可能比較差。但有時wait%偏高也不構成性能問題，例如，當系統任務較少時，CPU處理一個任務，處理過程中需要等IO，此時就體現在wait%上面；當繼續增加壓力，CPU接收到新的任務，CPU就不會干等下去，而是去忙着處理別的任務，此時wait%就被壓縮了。
Idle%
CPU閑置狀態即為idle%。
有人把Idle理解為CPU沒有任務時的一個占位進程把CPU占滿，這個理解是錯誤的。在這個進程里出現的CPU占用數值並不是真正的占用而是指CPU的空閑率
Idle%越大CPU的耗電越少，BTW，一台計算機的功耗不是恆定的，影響功耗的因素較多，但最主要的因素是CPU閑置還是運行，但盡管如此，Power服務器CPU閑置時僅比跑滿狀態省電10%左右，后續可以開個章節專門介紹如何測試功耗。
1.獲取來源
獲取來源與Usr%類似。
性能指標之資源指標 CPU配置參數對性能的影響
性能指標之資源指標 CPU親和性原理介紹及如何量化讀數
性能指標之資源指標 CPU親和性調整優化
性能指標之資源指標 如何精確計算每筆交易消耗的CPU
關於文中的一些概念，要參考一下基本文檔：
2、理解微分區
3、