原因分析：CPU拓?fù)洳町悓?dǎo)致Unixbench分?jǐn)?shù)異常

本文通過實(shí)驗論證：Unixbench的Pipe-based Context Switching用例受操作系統(tǒng)調(diào)度算法的影響波動很大，甚至出現(xiàn)了虛擬機(jī)跑分超過物理機(jī)的情況。在云計算時代，當(dāng)前的Unixbench已不能真實(shí)地反映被測系統(tǒng)的真實(shí)性能，需要針對多核服務(wù)器和云計算環(huán)境進(jìn)行完善。

簡單的說，視操作系統(tǒng)多核負(fù)載均衡策略的差異，該用例可能表現(xiàn)出兩種截然不同的效果：

1?在惰性的調(diào)度策略環(huán)境下，測試得分較高，但是會導(dǎo)致系統(tǒng)中任務(wù)調(diào)度延遲，最終可能引起業(yè)務(wù)性能抖動。例如，在視頻播放、音頻處理的業(yè)務(wù)環(huán)境中，引起視頻卡頓、音頻視頻不同步等問題。

2?在積極的調(diào)度策略環(huán)境下，測試得分偏低，但是系統(tǒng)中任務(wù)運(yùn)行實(shí)時性更高，業(yè)務(wù)運(yùn)行更流暢。

后文將詳細(xì)說明Pipe-basedContext Switching用例的設(shè)計原理，測試其在不同系統(tǒng)中的運(yùn)行結(jié)果，并提出測試用例改進(jìn)建議。

1測試背景

近期，團(tuán)隊在進(jìn)行服務(wù)器選型的時候，需要對兩款服務(wù)器進(jìn)行性能評估，其中一款服務(wù)器采用64核Xeon CPU，另一臺則采用16核Atom CPU。詳細(xì)配置信息如下：

根據(jù)硬件廠商的評測，Xeon服務(wù)器的綜合性能是Atom服務(wù)器的3倍。

我們采用了久負(fù)盛名的Unixbench性能測試套件，為我們最終的選擇提供參考。

Xeon的性能碾壓Atom是毋庸置疑的，畢竟Atom 更專注于功耗而不是性能，Atom服務(wù)器甚至沒有3級緩存，并且StoreBuffer、Message Queue的深度更低，流水線級數(shù)更少。

出于業(yè)務(wù)需求，在整個測試過程中我們更關(guān)注單核的性能。為了排除軟件的影響，兩臺服務(wù)器均安裝Centos 7操作系統(tǒng)。

測試命令很簡單，在控制臺中執(zhí)行如下命令：

./Run -c 1 -v

執(zhí)行時間比較久，我們可以到一邊去喝點(diǎn)燒酒。一杯燒酒下肚，神清氣爽:-)可以看看結(jié)果是否符合咱們的預(yù)期：

總分整體符合預(yù)期：Xeon服務(wù)器單核性能是Atom服務(wù)器的2.36倍(1390/588.4)

但是，這里出現(xiàn)了一個異常，細(xì)心的讀者應(yīng)該已經(jīng)發(fā)現(xiàn)：Pipe-based Context Switching測試用例的結(jié)果比較反常！從上表可以看出，無論是總分還是單項分?jǐn)?shù)，Xeon服務(wù)器均遠(yuǎn)遠(yuǎn)超過Atom服務(wù)器。其中也包括Pipe Throughput這項用例。然而“Pipe-based Context Switching”這項指標(biāo)顯得有點(diǎn)與眾不同：在這項指標(biāo)中，Xeon服務(wù)器的優(yōu)勢并不明顯，僅領(lǐng)先25%左右。

為了排除測試誤差，我們反復(fù)進(jìn)行了幾次測試，均發(fā)現(xiàn)同樣的規(guī)律。“Pipe-based Context Switching”項的分?jǐn)?shù)差異并不明顯，沒有體現(xiàn)出Xeon服務(wù)器的性能優(yōu)勢。

這一問題引起了我們的興趣，Unixbench這樣的權(quán)威測試軟件的結(jié)果居然和廠商宣稱的出入這么大。為了找出原因，我們使用其他測試環(huán)境，進(jìn)行了一系列的對比測試。首先，我們找了更多物理機(jī)進(jìn)行對比分析。

1.1物理機(jī)對比測試

為此，我們使用另一組服務(wù)器進(jìn)行對比測試，其型號分別為：HP ProLiantDL360p Gen8?DELL PowerEdge R720xd。配置如下：

分別在兩臺服務(wù)器的控制臺中輸入如下命令，單獨(dú)對“Pipe-based Context Switching”用例進(jìn)行測試：

./Run index2 -c1

得到該測試項的分?jǐn)?shù)為：

測試結(jié)果與上面相似，硬件參數(shù)明顯占優(yōu)的DELLL跑分僅領(lǐng)先HP不到20%:-(

1.2物理機(jī)VS虛擬機(jī)

測試似乎陷入了迷途，然而我們一定需要將加西亞的信送到目的地，并且堅信“柳暗花明又一村”的那一刻終究會到來。

為此，我們使用三組云虛擬機(jī)來進(jìn)行測試。這三組虛擬機(jī)配置如下：

這三款虛擬機(jī)與此前的物理機(jī)參數(shù)相差不大，如果不出意外的話，分?jǐn)?shù)應(yīng)當(dāng)介于300~400之間。

然而測試結(jié)果出人意料，以至于筆者的鏡片摔了一地：

特別令人吃驚的是：第二組虛擬機(jī)的測試分?jǐn)?shù)，竟然是物理主機(jī)的1.5倍，并且是第一組虛擬機(jī)和第三組虛擬機(jī)的5.4倍。

1.3單核和多核對比測試

為此，我們認(rèn)真分析不同系統(tǒng)中的CPU占用率。發(fā)現(xiàn)一個特點(diǎn)：在Pipe-based Context Switching用例運(yùn)行期間，在得分高的環(huán)境中，兩個context線程基本上運(yùn)行在同一CPU上。而在得分低的環(huán)境中中，兩個context線程則更多的運(yùn)行在不同的CPU上。這說明：測試結(jié)果差異可能與Guest OS中的調(diào)度算法及CPU負(fù)載均衡策略有關(guān)。

我們不得不啟用了排除法，先看單核和多核之間的差異。

為了驗證猜想是否正確，我們臨時修改了Guest OS中內(nèi)核調(diào)度算法。修改原理是：在喚醒線程時，不管其他CPU核是否空閑，優(yōu)先將被喚醒任務(wù)調(diào)度到當(dāng)前CPU中運(yùn)行。這樣的調(diào)度算法，其缺點(diǎn)是：被喚醒任務(wù)將不能立即運(yùn)行，必須等待當(dāng)前線程釋放CPU后才能獲得CPU，這將導(dǎo)致被喚醒線程的實(shí)時性較弱。

經(jīng)過測試，在打上了Linux內(nèi)核調(diào)度補(bǔ)丁的系統(tǒng)中，Pipe-based Context Switching在虛擬機(jī)和物理機(jī)上，得分大大提升。實(shí)際測試的結(jié)果如下：

很顯然，我們不能將上述補(bǔ)丁直接應(yīng)用到生產(chǎn)環(huán)境中，因為該補(bǔ)丁會影響任務(wù)運(yùn)行的實(shí)時性。因此我們將Linux內(nèi)核調(diào)度補(bǔ)丁回退，并修改“Pipe-based ContextSwitching”測試用例的代碼，強(qiáng)制將context線程綁定到CPU 0中運(yùn)行，這樣可以避免Guest OS中的調(diào)度算法及CPU負(fù)載均衡算法的影響。測試結(jié)果如下：

我們再次修改“Pipe-based Context Switching”測試用例的代碼，強(qiáng)制將context線程分別綁定到CPU 0和CPU 1中運(yùn)行，這樣也可以避免Guest OS中的調(diào)度算法及CPU負(fù)載均衡算法的影響。測試結(jié)果如下：

可以看到，應(yīng)用了新的“Pipe-basedContext Switching”補(bǔ)丁之后，所有測試結(jié)果都恢復(fù)了正常，離真相越來越近了。

2原因分析： CPU拓?fù)洳町悓?dǎo)致Unixbench分?jǐn)?shù)異常

通過前面針對“Pipe-based Context Switching”單實(shí)例用例的測試，帶給我們?nèi)缦乱蓡枺?/p>

為什么在該用例中，虛擬機(jī)B得分接近600，遠(yuǎn)高于虛擬機(jī)A、虛擬機(jī)C，甚至高于虛擬機(jī)A所在的物理機(jī)？

為了分析清楚該問題，我們分析了Pipe-based Context Switching用例, 這個用例的邏輯是：測試用例創(chuàng)建一對線程A/B，并創(chuàng)建一對管道A/B。線程A寫管道，線程B讀A管道；并且線程B寫B(tài)管道，線程A程讀B管道。兩個線程均同步執(zhí)行。

經(jīng)過仔細(xì)分析，虛擬機(jī)A和虛擬機(jī)B在該用例上的性能差異的根本原因是：在虛擬機(jī)環(huán)境下，底層Host OS向Guest OS透傳的cpu拓?fù)洳煌?，?dǎo)致虛擬機(jī)系統(tǒng)中的調(diào)度行為不一致, 最終引起很大的性能差異。其中虛擬機(jī)A是按照Host主機(jī)的實(shí)際情況，將真實(shí)的CPU拓?fù)鋫鬟f給Guest OS。而虛擬機(jī)B的主機(jī)則沒有將真實(shí)的物理主機(jī)CPU拓?fù)鋫鬟f給Guest OS。這會導(dǎo)致虛擬機(jī)內(nèi)所見到的CPU拓?fù)浜凸蚕韮?nèi)存布局有所不同。

在真實(shí)的物理服務(wù)器上，每個物理核會有各自的FLC和MLC，同一個Core上的CPU共享LLC。這樣的CPU拓?fù)湓试S同一Core上的CPU之間更積極的進(jìn)行線程遷移，而不損失緩存熱度，并且能夠提升線程運(yùn)行的實(shí)時性。這個特性，更利于視頻播放這類實(shí)時應(yīng)用場景。

下圖是虛擬機(jī)A和虛擬機(jī)B中看到的CPU視圖：

拓?fù)浣Y(jié)構(gòu)的差異地方在LLC的共享方式，虛擬機(jī)A使用的拓?fù)浣Y(jié)構(gòu)與物理機(jī)一致，同一個Core內(nèi)CPU共享LLC。而虛擬機(jī)B的配置是同一個Core內(nèi)CPU不共享LLC。不共享LLC的場景下，Linux將每個CPU在LLC層次的調(diào)度域設(shè)置為空。這樣，虛擬機(jī)B的Guest OS會認(rèn)為同一物理CPU內(nèi)的兩個超線程是兩個獨(dú)立的CPU，處于不同的域之間（這與實(shí)際的物理機(jī)配置不一致），因此其負(fù)載均衡策略會更保守一些。喚醒一個進(jìn)程時，內(nèi)核會為其選擇一個運(yùn)行的目標(biāo)CPU，linux的調(diào)度策略會考慮親和性（提高cache命中率）和負(fù)載均衡。在Linux 3.10這個版本下，內(nèi)核會優(yōu)先考慮親和性，親和性的目標(biāo)是優(yōu)先選取同一個調(diào)度域內(nèi)的CPU。虛擬機(jī)A共享LLC，所有的CPU都在同一個調(diào)度域內(nèi)，內(nèi)核為其選擇的是同一調(diào)度域內(nèi)的空閑CPU。而虛擬機(jī)B因為LLC層次的調(diào)度域為空，在進(jìn)入親和性選擇時，無法找到同一個調(diào)度域內(nèi)的其它空閑CPU，這樣就直接返回了正在進(jìn)行喚醒操作的當(dāng)前CPU。

最終，在虛擬機(jī)B中，除了偶爾進(jìn)行的CPU域間負(fù)載均衡以外，兩個測試線程基本上會一直在同一個CPU上運(yùn)行。而虛擬機(jī)A的兩個進(jìn)程會并發(fā)的運(yùn)行在兩個不同的CPU上。

這一特征下的運(yùn)行時間軸如下：

虛擬機(jī)B場景引入的開銷是喚醒和等待運(yùn)行開銷，虛擬機(jī)A場景引入的開銷是喚醒和切換運(yùn)行開銷。

在正常的工作負(fù)載下面，進(jìn)程運(yùn)行的時間會遠(yuǎn)大于進(jìn)程切換的開銷，而Pipe-based Context Switching用例模擬的是一個極限場景，一個線程在喚醒對端到進(jìn)入睡眠之間只執(zhí)行很簡單的操作，實(shí)際等待運(yùn)行的開銷遠(yuǎn)小于切換運(yùn)行的開銷。

此外，在虛擬化場景下，兩種方式喚醒操作中也存在差異，在虛擬機(jī)A這個場景下，喚醒的開銷也遠(yuǎn)大于虛擬機(jī)B場景中的喚醒開銷。最終出現(xiàn)虛擬機(jī)B上該用例的得分遠(yuǎn)高于虛擬機(jī)A、虛擬機(jī)C，甚至高于物理機(jī)上的得分。

為了進(jìn)一步驗證我們的分析是否正確。我們在HOST OS中，分別向虛擬機(jī)A的GuestOS和虛擬機(jī)B的Guest OS按照不同方式傳遞CPU拓?fù)?。測試發(fā)現(xiàn)：在同樣的CPU拓?fù)浣Y(jié)構(gòu)下，二者的測試分?jǐn)?shù)是一致的。換句話說，導(dǎo)致該項測試分?jǐn)?shù)差異的原因，在于不同的HOST OS向Guest OS傳遞的CPU拓?fù)浯嬖诓町?，進(jìn)而導(dǎo)致Guest OS中任務(wù)調(diào)度行為的差異。

3 結(jié)論：Unixbench需要針對多核服務(wù)器和云環(huán)境進(jìn)行優(yōu)化

unixbench的Pipe-based Context Switching用例受操作系統(tǒng)調(diào)度算法的影響比較大。視操作系統(tǒng)多核負(fù)載均衡策略的差異，可能表現(xiàn)出兩種截然不同的效果：

1?在多核負(fù)載均衡策略不積極的系統(tǒng)中，測試線程更多的運(yùn)行在同一個CPU中，線程之間的切換開銷更低。因此測試得分更高，但是會導(dǎo)致系統(tǒng)中任務(wù)調(diào)度延遲。在實(shí)時性要求比較高的系統(tǒng)中，這會引起業(yè)務(wù)抖動。例如，在視頻播放、音頻處理的業(yè)務(wù)環(huán)境中，這可能引起視頻卡頓、音頻視頻不同步等問題。

2?在多核負(fù)載均衡策略更積極的系統(tǒng)中，測試線程更多的運(yùn)行在不同的CPU中，線程之間的切換開銷更高。因此測試分值更低，但是系統(tǒng)中任務(wù)調(diào)度延遲更低，業(yè)務(wù)的性能不容易產(chǎn)生波動。

換句話說：當(dāng)前的Unixbench已不能真實(shí)地反映被測系統(tǒng)的真實(shí)性能，需要針對多核服務(wù)器和云計算環(huán)境進(jìn)行完善。

4 修改建議

我們建議調(diào)整unixbench測試用例，將測試用例的線程綁定到Guest OS的CPU上。這樣就可以避免受到Guest OS調(diào)度策略和CPU負(fù)載均衡策略的影響。具體來說，有兩種方法：

1?將context1和context2兩個線程綁定在同一個CPU核上面。這樣可以反應(yīng)出被測試系統(tǒng)在單核上的執(zhí)行性能。

2?將context1和context2兩個線程分別綁定到不同CPU核上面。這樣可以反應(yīng)出被測試系統(tǒng)在單核的執(zhí)行性能，以及多核之間的核間通信性能。

(完)