本文主要介紹在 PowerVM 虛擬化環境下，微分割槽 CPU 利用率的監控方法，並且深入討論在虛擬化環境下，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 分割槽

在接下來的頁面中，需要設定虛擬 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 檢視分割槽配置

此時，系統十分空閒：

檢視到系統中虛擬 CPU 的數量： # prtconf |grep "Number Of Processors" Number Of Processors: 6 檢視到由於系統開啟了 SMT-4，因此係統中邏輯 CPU 的數量為 24

此時 6 個虛擬 CPU 的 24 個邏輯 CPU 並未完全展開 :

如果將 vpm_fold_policy 設定為 4，即關閉該功能，那麼 24 個邏輯 CPU 將全部展開：

在 系統中，還有一個核心引數：vpm_xvcpus。它的作用是控制當微分割槽 CPU 不足的時候，系統可以自動啟動的微分割槽的數量。如果將這個值設定為 -1，則表示關閉此功能；若設定為 0，表示啟用了摺疊功能 (Processor Folding) 。這意味著虛擬處理器正接受管理，分割槽啟用了 CPU 摺疊功能。預設數值設定為 0，表示分割槽可以啟用其關閉的虛擬 CPU；如果 vpm_xvcpus 數值設定大於 1，則表示系統不僅可以啟用其關閉的虛擬 CPU，還可以啟動額外的虛擬 CPU，前提是分割槽的虛擬 CPU 總數不大於分割槽概要檔案最大虛擬 CPU 數量的設定。

分 區需要的虛擬 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

接下來，我們將物理 CPU 的數量增加到 4，會看到如下報錯：

圖 5.DLPAR 增加 CPU

在這種情況下，就需要同時增加虛擬 CPU 和物理 CPU 的數量：

圖 6.DLPAR 增加 CPU

可以新增成功。

DLPAR 能夠增加到的最大物理 CPU 的數量，是由設定的物理 CPU 的“ 最大處理單元數”決定的。

系統中檢視微分割槽 CPU 相關配置

在微分割槽中，我們可以使用 lpatsta – i 命令準確地檢視分割槽 CPU 和記憶體的相關配置資訊。

點選檢視程式碼清單

我們也可以通過登陸 HMC 檢視對應項的數值。

圖 7. 檢視伺服器 CPU 配置

檢視分割槽的概要檔案：

圖 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 分析結果

在命令結果的輸出中，我們需要關注幾個時間點，在 22：05 的時候，系統開始第一個 ncpu 的壓力。

從 nmon 結果的另外一個子頁，檢視 CPU 執行緒的利用率，基本上符合在 SMT-4 環境下，系統優先使用第一個執行緒的原則：CPU005、CPU009、CPU013、CPU017、CPU021 的幾個執行緒利用率是最高的執行緒。

圖 10. 檢視邏輯 CPU 利用率

檢視分割槽 CPU 執行佇列的數量變化，可以看出是平緩增加的，符合指令碼中平緩加壓的規則：

圖 11. 檢視 CPU 執行佇列

從 nmon 結果中擷取幾個關鍵時間點的 CPU 利用率，這樣可以很清楚看出 CPU 整體利用率與執行緒利用率的關係：

表 1. CPU 整體利用率與執行緒利用率的關係

得出的結論是，對於一個開了 SMT-4 的 CPU，我們壓滿其第 1 個執行緒與將 4 個執行緒都壓滿，操作看到的整體 CPU 利用率沒有太大的變化。

我們還可以得出另外一個結論：壓滿單個 CPU 對於整體 CPU 利用率的增長，並不是線性關係，與 CPU 數量的比率也不匹配，如下表：

表 2

因此，在多執行緒應用和開啟系統多執行緒的環境下，我們在監控 CPU 利用率的時候，在衡量系統還能增加多少業務量的時候，不能簡單地根據某一條系統命令看到的 CPU 空閒值來衡量。

微分割槽 CPU 使用率的監控

我們可以通過設定微分割槽的屬性，將其“允許效能資訊收集”的選項開啟：

圖 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 1System 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 執行緒數，然後再結合系統的命令進行檢視，才能比較準確地預估伺服器還能增加多少應用負載。