Reference from IBM research.
減少Linux耗電，第3部分: 調優結果
工作負載和調控器效果電源效率是任何關心業務成本和環境問題的人應該考慮的重要因素。 在本系列的最後一篇文章中，讓我們檢查您通過調優Linux CPUfreq子系統和內核調控器以更改處理器的運行頻率，在電源效率上所造成的差異（用實際數字和圖表表示），這種更改不會 對性能造成重大影響。
在 減少Linux耗電，第2部分：一般設置和與調控器相關的設置 中，您看到瞭如何使用和調優調控器，現在您將看到一些調控器效果。 我將使用以下兩個流行的工作負載來比較性能和電量消耗，展示一個調優後的調控器如何節約電能而不會犧牲性能。
- 一個工作負載來自SPECpower_ssj2008 基準測試，該測試評估電能和性能。
- 一個工作負載來自一個電子商務購物應用程序，該程序在一個模擬在線購物會話期間收集許多統計數據，其中包括延遲時間和每秒的請求數量。
SPECpower_ ssj2008 工作負載
以下結果來自評估電能和性能的SPECpower_ssj2008基準測試。 要查看關於這個基準測試的更多信息或查看最新官方基準測試結果，請參見SPEC Web站點（參考資料 提供了一個鏈接）。 注意，這些結果沒有針對最優性能進行調優，不應被視為針對系統的正式基準測試結果，它們只是用於研究目的的結果。
SPECpower_ssj2008 使用一個Java™ 基準測試以獲取單位為ssj_ops（ssj 操作）的性能得分，並在從100% 負載到完全閒置的負載範圍內運行這個基準測試。 得分越高，系統可以完成的計算量就越大。
SPECpower_ssj2008 還測量電能（以瓦特為單位）並在每個負載水平計算一個性能/電能比（performance-to-power）。 這個比率越高，系統的“性能/電能” 效率也就越好。
默認調控器比較
圖1比較了5個內核調控器的效果，它們都使用默認設置運行。 可調優的 sched_mc_power_savings 和 sched_smt_power_savings 被關閉，CPU頻率守護進程 cpuspeed 與userspace調控器一起運行。
|
圖1. 默認設置的得分和電能消耗
虛線顯示單位為 ssj_ops 的得分，ssj_ops 是一個SPECpower_ssj2008性能度量指標。 您可以看到，導致性能下降的主要因素是powersave調控器，這顯然是因為powersave調控器靜態處理器將頻率設置為盡可能低的水平，以便盡量節約電能。
實線顯示電能消耗。 同樣，powersave調控器消耗的電能比其他調控器少，但這是以犧牲性能為代價的。 另外，您還可以看到系統閒置時不同調控器之間的能耗差異。 performance調控器總是以最高頻率運行，因此它在閒置時消耗的電能要比其他調控器高10瓦特左右。 userspace調控器以及 cpuspeed 守護進程在節約電能而不損害性能方面似乎是最好的默認調控器。 我們可以通過在圖2中比較每次運行的“性能/電能”比率來確認這一點。
圖2. 默認設置下的“性能/電能” 比率
“性能/電能” 比率是SPECpower_ssj2008 計算的一個度量指標，通過比較獲得的得分和獲得該得分所耗費的電能來度量一個系統的節電程度，因此比率越高越好。
如您所見，當所有調控器以默認設置運行時，userspace調控器以及 cpuspeed 守護進程在多數負載水平下比其他調控器擁有更好的“性能/電能”比率，因此，userspace調控器的能效最高。
調優
如 減少Linux耗電，第2部分：一般設置和與調控器相關的設置 所述，有一些針對ondemand和conservative調控器的可選調優參數。 下面將介紹如何更改利用率閾值以影響調控器的能效。
|
Ondemand
ondemand up_threshold 默認設置為80，表示一旦CUP利用率達到80%以上，ondemand調控器將提高頻率。 下面我將向您展示，只需將 up_threshold 更改為98，您就可以使ondemand調控器變得更有能效。
圖3比較ondemand調控器以默認配置（up_threshold 為80）運行的效果和以調優後的設置（up_threshold 為98）運行的效果。 在上述運行期間，可調優的sched_mc_power_savings 和 sched_smt_power_savings 均關閉。
圖3. ondemand 的得分和電能消耗
從圖中的虛線可以看出，默認和調優ondemand調控器獲得了非常相似的得分，可見，更改 up_threshold 不會影響性能。 但是，顯示電能消耗的實線的確顯示出輕微的差異。 如您所見，將 up_threshold 提高到98比使用默認閾值略微降低了電能消耗。
下面，我們看看圖4 中的“性能/電能” 比率。
圖4. ondemand 的“性能/電能” 比率
從圖4 可以看出，對於幾乎每一個負載水平，調優後的ondemand 調控器（利用率閾值為98）比默認ondemand 調控器的能效都略高一些。
Conservative
conservative 調控器有兩個閾值可以調優：
- 首先，up_threshold 默認設置為80，表示一旦處理器利用率超過80%，該調控器將提高頻率。
- 還有一個 down_threshold，默認值為20。 這表示一旦調控器發現處理器的利用率低於20%，它將逐步降低頻率以節約電能。
圖5比較了conservative調控器以默認設置（up_threshold 為80且 down_threshold 為20）運行的結果和以調優設置（up_threshold 為98且 down_threshold 為95）運行的結果。 在上述運行中，可調優的 sched_mc_power_savings 和 sched_smt_power_savings 關閉。
圖5. conservative 的得分和電能消耗
同樣，圖5 中的虛線顯示，使用經過調優的調控器沒有性能影響。 而實線清晰地顯示，默認調控器和調優調控器之間存在電能消耗差異：調優調控器在中等水平的負載下消耗更少的電能，在50% 負載水平上減少了約40 瓦特。 這是一個較大的電能節約。 您可以通過比較圖6 中的“性能/電能” 比率確認這一點。
圖6. conservative 的“性能/電能” 比率
這些比率顯示調優的conservative 調控器在從30% 到90% 的負載水平上比默認conservative 調控器提高了能效。
調優的調控器比較
在這個小節中，我將比較調優的ondemand和conservative調控器與其他3個調控器。 圖7比較所有5個調控器，其中ondemand和conservative的閾值進行了調優。 可調優的 sched_mc_power_savings 和 sched_smt_power_savings 關閉，CPU頻率守護進程cpuspeed與userspace調控器同時運行。
圖7. 調優的調控器的得分和電能消耗
圖7再次表明，儘管powersave調控器的確比其他調控器消耗更少的電能，但它對性能有較大的負面影響，因為它只在盡可能低的頻率運行。 （我們將在下一個圖形中展示powersave與其他調控器相比之下的能效）。 其他4個調控器獲得相似的得分，不管它們是否進行了調優。 同樣，performance調控器只在盡可能高的頻率運行，您可以通過比較圖中的實線看出這在電能消耗上導致多大的差異。 與 cpuspeed 守護進程聯合運行的userspace調控器和調優的conservative調控器在電能節約方面僅次於powersave調控器。 userspace調控器在30%到50%的負載水平上比調優的conservative調控器消耗的電能略少一些，而調優的conservative調控器在50%以上的負載水平上則比userspace調控器消耗的電能更少。 我們可以通過比較它們的“性能/電能”比率（見圖8）來了解哪個調控器的能效更高。
圖8. 調優的調控器的“性能/電能” 比率
圖8顯示，調優的conservative調控器和運行 cpuspeed 的userspace調控器的能效非常相似。 最終的得分（沒有在這裡顯示）表明，調優的conservative調控器擁有最好的總體能效，但優勢並不明顯。
sched_mc_power_savings 比較
如前所述，sched_mc_power_savings 調優方法試圖合併進程以佔用盡可能低的內核資源，從而節約電能。 圖9和圖10展示運行默認conservative調控器時，sched_mc_power_savings 分別為on (1)和off (0)時的CPU利用率的對比。 以下比較展示在10%的負載水平上每個處理器的利用率，這樣系統的平均利用率為10%。
圖9. sched_mc_power_savings 關閉
圖10. sched_mc_power_savings 開啟
您可以清楚地看到兩個圖形中的差異。 圖9顯示，在 sched_mc_power_savings 關閉時，4個處理器的利用率約為15%，另外4個處理器的利用率約為5%。 圖10顯示，在 sched_mc_power_savings 開啟時，負載聚合到4個處理器上，現在它們的利用率約為20%，而其他4個處理器則閒置。 聯合使用這種調優方法和一個內核CPUfreq調控器能夠減少電能消耗，因為負載聚合能夠使一些處理器處於閒置狀態，從而以較低的頻率運行。
sched_smt_power_savings 比較
與 sched_mc_power_savings 類似，sched_smt_power_savings 調優方法試圖將超線程聚合到盡可能少的CPU上，從而節約電能。 圖11和12展示，當默認conservative調控器在一個支持超線程的系統上運行時，sched_smt_power_savings 分別為on (1)和off (0)時的CPU利用率的對比。 以下比較展示在10%的負載水平上每個處理器的利用率，這樣系統的平均利用率為10%。
圖11. sched_smt_power_savings 關閉
Figure 12. sched_smt_power_savings 開啟
同樣，當設置為開啟時，負載將聚合。 如果閒置或接近閒置的CPU 能夠使用CPUfreq 調控器來降低頻率且/或閒置C 狀態，同時結合使用這種類型的調度，那麼電能節約就有可能實現。
一個電子商務工作負載
在這個小節中，我將在另一種類型的工作負載上比較調控器的效果。 以下結果來自一個電子商務購物應用程序，該程序在一個模擬在線購物會話期間收集許多統計數據，包括延遲時間和每秒請求數。 這個應用程序使用一個Apache 前端，一個PHP 實現和一個MySQL 數據庫來創建一個可用的購物站點。 注意，這些結果沒有針對最優性能進行調優，不應被視為針對系統的正式結果。 我們將在不同的利用率負載水平上比較這個工作負載上的效果。
默認調控器比較
以下圖形比較conservative和ondemand這兩個可調優內核調控器和作為基準比較的performance調控器。 所有調控器使用默認設置運行，調優方法 sched_mc_power_savings 和 sched_smt_power_savings 在運行期間關閉。
圖13 系列展示一個總共帶有500 個客戶端的在線購物會話的統計數據。 測試系統在運行500 個客戶端時的平均利用率為8-12%。
圖13a. 性能（請求/秒）
圖13b. 延遲時間（毫秒）
Figure 13c. 平均電能（瓦特）
Figure 13d. 性能/瓦特
圖13a 展示這個購物會話的性能，單位為“請求/秒”。 您可以看到，所有3 個調控器每秒的請求數幾乎完全相同。
圖13b 顯示平均延遲時間稍微有一些區別。 conservative 調控器比performance 調控器幾乎延遲7 毫秒，但對於在線購物車這樣的應用程序來說，多數用戶不會注意到增加的幾毫秒，因此這個區別可以忽略。
圖13c 顯示平均電能消耗。 可以看出，conservative 調控器比performance 調控器大約節約了20W；也就是說，沒有處理器變頻且ondemand 調控器平均節約15W。
圖13d 通過用每秒請求數除以平均電能消耗顯示“性能/瓦特”。 三個調控器的類似性能和兩個動態調控器的電能節約意味著後者俱有更高的“性能/瓦特” 值。 conservative 調控器在8-12% 的利用率負載水平上的能效最高，緊隨其後的是ondemand 調控器。
下面，我們將在更高的負載水平上比較三個默認調控器的“性能/瓦特” 值，看看默認的conservative 調控器是否仍然比其他兩個默認調控器的能效更高。 圖14 展示了一個1,000 個客戶端的負載，這個負載導致20-25% 的平均利用率。
圖14. 針對1,000 個客戶端的默認調控器比較
從這個圖表可以看出，對於這個負載水平，conservative 調控器也是能效最高的調控器。 對於這次運行，conservative 調控器比performance 調控器節約了約25W，當它仍然可以服務幾乎完全相同的每秒請求數。 對於這個負載水平，conservative 調控器的平均請求延遲時間比其他兩個調控器慢了約5 毫秒。
最後，讓我們看看圖15 中負載水平為2,000 個客戶端時的“性能/瓦特" 值，該負載水平將測試系統的平均利用率提高到45-60%。
圖15. 針對2,000 個客戶端的默認調控器比較
對於這個負載水平，默認ondemand 調控器擁有的“性能/瓦特” 值略好一些。 ondemand 和conservative 調控器都節約了約15W，但默認conservative 調控器的性能出現降低，因為它每秒完成的請求數比其他兩個調控器少8 個，它的延遲時間比performance 調控器慢了0.15秒。 這一次ondemand 調控器是贏家，因為它實際上完成了相同數量的每秒請求數而延遲時間只比performance 調控器多50 毫秒，當然，這表示系統無需任何處理器變頻情況下實現的性能。
調優的調控器比較
現在我們將比較調優的ondemand和conservative調控器在這個工作負載下的表現。 同樣，調控器調優通過更改利用率閾值實現。 調優的conservative調控器的 up_threshold 設置為98，down_threshold 設置為95。 調優的ondemand調控器也使用 up_threshold 為98的設置運行。 我們將在圖16系列中查看在更繁重的2,000個客戶端的負載水平（平均利用率為45-60%）上這兩個調優過的調控器的效果。
較輕的負載水平不會顯示明顯的差異，因為在20%的利用率（默認的 down_threshold 設置）下，調優的調控器在所有負載水平上的表現與默認調控器相同。 調優方法 sched_mc_power_savings 和 sched_smt_power_savings 在運行期間關閉。
圖16a. 性能（請求/秒）
圖16b. 延遲時間（毫秒）
圖16c. 平均電能（瓦特）
圖16d. 性能/瓦特
圖16a 和16b 顯示，調優的conservative 調控器的性能略有降低：每秒完成的請求數減少約13 個，延遲時間比performance 調控器約多0.28 秒。 但圖16c 顯示，調優的conservative 調控器比沒有處理器變頻時大約節約55W。 即使性能略有降低，調優的conservative 調控器也是目前為止能效最高的。
結束語
在這個 3部分系列 中，我向您展示了在多數情況下，一個調優的conservative調控器（up_threshold 為98、down_threshold 為95）能夠取得最好的“性能/電能”效率。 在某些情況下，這個調控器可能會對性能有輕微負面影響。
您必須確定，以可能發生的性能降低來換取實現潛在的巨大電能節約是否值得。 如前所述，您可以使用許多針對動態內核調控器的調優方法來影響調控器的性能，這可能會反過來影響正在運行的工作負載的性能。
電能節約和性能之間總是存在一種平衡，但我希望我已經向您展示如何將性能影響降低到一個可以忽略的程度，同時使系統獲得更好的電能效率。
參考資料
學習
- 閱讀關於電能消耗的其他資料：
- 教程“How to make use of Dynamic Frequency Scaling”
- 教程“Enhanced Intel SpeedStep Technology and Demand-Based Switching on Linux”
- 文章“Making power policy just work”（關於電力調度器）
- 文章“CPU frequency scaling in Linux”
- 文檔“Linux CPUfreq Governors”（關於Linux內核中的CPU頻率和電壓擴展代碼）
- Gentoo “Power Management Guide”（警告：適用於筆記本計算機，除非有把握，否則不要應用於服務器！）
- 教程“How to use CPU frequency scaling (cpufreq)”
- wiki文章 CPU Frequency Scaling
- 教程“Scheduler tunables for multi-socket systems”
- kernel.org中關於 CPUfreq subsystem 的數據
- SPECpower_ssj2008 是評估大容量服務器類型的計算機電能和性能特徵的第一個行業標準SPEC基準測試。 最初的基準測試處理服務器端Java的性能，並規劃了其他工作負載。 在這裡查看 最新結果。
- 查閱 支持CPUfreq子系統的硬件列表。
- 在重新構建/重新啟動內核方面需要幫助嗎？ 看看Kwan Lowe的“Kernel Rebuild Guide”。
- 在 developerWorks Linux專區 尋找為Linux開發人員（包括 Linux新手入門）準備的更多參考資料，查閱我們 最受歡迎的文章和教程。
- 在developerWorks上查閱所有 Linux技巧 和 Linux教程。
- 隨時關注developerWorks 技術活動和網絡廣播。
獲得產品和技術
- 使用可直接從developerWorks下載的 IBM產品評估試用版軟件 構建您的下一個Linux開發項目。
討論
- 參與論壇討論。
- 加入 My developerWorks社區；您可以通過個人信息和定制主頁獲得自己感興趣的developerWorks文章，並與其他developerWorks用戶進行交流。
沒有留言:
張貼留言