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

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

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

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

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

1測(cè)試背景

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

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

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

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

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

測(cè)試命令很簡(jiǎn)單，在控制臺(tái)中執(zhí)行如下命令：

./Run -c 1 -v

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

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

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

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

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

1.1物理機(jī)對(duì)比測(cè)試

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

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

./Run index2 -c1

得到該測(cè)試項(xiàng)的分?jǐn)?shù)為：

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

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

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

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

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

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

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

1.3單核和多核對(duì)比測(cè)試

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

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

為了驗(yàn)證猜想是否正確，我們臨時(shí)修改了Guest OS中內(nèi)核調(diào)度算法。修改原理是：在喚醒線程時(shí)，不管其他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í)時(shí)性較弱。

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

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

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

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

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

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

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

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

經(jīng)過仔細(xì)分析，虛擬機(jī)A和虛擬機(jī)B在該用例上的性能差異的根本原因是：在虛擬機(jī)環(huán)境下，底層Host OS向Guest OS透?jìng)鞯腸pu拓?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。這會(huì)導(dǎo)致虛擬機(jī)內(nèi)所見到的CPU拓?fù)浜凸蚕韮?nèi)存布局有所不同。

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

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

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

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

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

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

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

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

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

3 結(jié)論：Unixbench需要針對(duì)多核服務(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)中，測(cè)試線程更多的運(yùn)行在同一個(gè)CPU中，線程之間的切換開銷更低。因此測(cè)試得分更高，但是會(huì)導(dǎo)致系統(tǒng)中任務(wù)調(diào)度延遲。在實(shí)時(shí)性要求比較高的系統(tǒng)中，這會(huì)引起業(yè)務(wù)抖動(dòng)。例如，在視頻播放、音頻處理的業(yè)務(wù)環(huán)境中，這可能引起視頻卡頓、音頻視頻不同步等問題。

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

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

4 修改建議

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

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

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

(完)