IBM公司已進行的基準測試可以解釋在真實世界虛擬化環(huán)境中是如何執(zhí)行事務(wù)處理的。

當去年年底事務(wù)處理委員會(TPC)拋出TPC-VMS服務(wù)器虛擬化基準測試規(guī)范時，就有人抱怨該規(guī)范并不符合最終用戶的實際需求：他們把運行了事務(wù)處理工作負載的虛擬化服務(wù)器與裸機進行比較，并基于此給出了其開銷。

但是，IBM公司有時候是很大度的，因此它在Red Hat的KVM虛擬機管理程序上進行了一個TPC-C測試，而不是TPC-VMS。

在基于雙插槽Xeon E5服務(wù)器上安裝KVM，IBM并沒有采取任何TPC-VMS動作，這是刻意選擇并用于混淆物理和虛擬服務(wù)器之間比較的，從而確定虛擬化費用。這種比較是很重要的，特別是對于諸如事務(wù)處理這樣I/O密集型的工作負載。

在二十世紀九十年代初,TPC-C在線交易處理基準測試出現(xiàn)時，內(nèi)存的價格是非常昂貴的，而TPC-C數(shù)據(jù)庫必須存儲在磁盤驅(qū)動器上。CPU都是適度供電的，其價格也是非常昂貴的，而服務(wù)器中I/O子系統(tǒng)的負載都是相當高的。但是，如今的雙插槽服務(wù)器都配有多個TB級主內(nèi)存，并具有大量的I/O容量，因此，TPC-C數(shù)據(jù)庫的很大一部分基本上都是在內(nèi)存中運行。

到底是多大的一部分，無法說出具體的數(shù)字。它不是一個SAP HANA內(nèi)存駐留數(shù)據(jù)庫設(shè)置，但有了現(xiàn)代數(shù)據(jù)庫和操作系統(tǒng)中固有的緩存信息，一個運行TPC-C測試的現(xiàn)代服務(wù)器要比二十年前本質(zhì)上的磁盤驅(qū)動數(shù)據(jù)庫更接近于HANA實例。當然，這里的磁盤驅(qū)動器是用于I/O的，但那也是因為測試要求磁盤容量能按最終用戶的要求而擴展。

諸如TPC-C這樣的測試推動了多核芯片配備大內(nèi)存容量和高帶寬的發(fā)展趨勢，這樣也就促使這樣的高端配置成為了業(yè)界標配，也讓我們認為是理所當然的。很多人都認為基準測試是無用的，也許他們忘記了它對系統(tǒng)架構(gòu)和軟件設(shè)計的影響。但是，如果仔細觀察的話就會發(fā)現(xiàn)，事實上也需要基準測試來推動實際創(chuàng)新。

當然， 最好的做法還是做好自己的測試。如果所有的數(shù)據(jù)用于數(shù)以百萬計的服務(wù)器，那么這樣一個大數(shù)據(jù)項目是值得這樣做的，這將是真正有趣的事情，可能也是有用的。

在藍色巨人測試運行KVM的TPC-C設(shè)置中，專家們使用了一個配有兩個八核Xeon E5-2690處理器、主頻達到2.9GHz的System x3650 M4服務(wù)器。對于這臺機器，IBM增加了768GB的主內(nèi)存和四個Qlogic 8Gb/秒光纖通道適配器，連接九個DS3524磁盤陣列和一個DS3512磁盤陣列，其中共有44個硬盤驅(qū)動器和72 個SSD，共計總?cè)萘?0.3TB。

這臺特殊的服務(wù)器運行了Red Hat企業(yè)版Linux 6.4、IBM公司的DB2 9.7關(guān)系型數(shù)據(jù)庫以及Red Hat的KVM虛擬機管理程序，它能夠支持1，040，400個用戶，并以每分鐘1，320，082次處理吞吐量的速度處理新命令。(即使另外有其他四個必須運行、只使用半數(shù)不到CPU資源的工作負載，TPC-C測試的新命令部分還是計算在正式結(jié)果中。)

IBM去年夏天Flex x240節(jié)點上運行測試，這與在System x3650 M4上測試KVM幾乎完全相同。

這個Flex x240服務(wù)器配有兩個主頻為2.9GHz的Xeon E5-2690型處理器、相同的768GB主內(nèi)存、兩個8Gb/秒光纖通道卡，連接一組DS35XX磁盤陣列。IBM有三個DS3512磁盤，配有24個磁盤和112個固態(tài)硬盤，它支持1，196，160個用戶，并以每分鐘1，503，544次處理的速度執(zhí)行新命令，它運行Red Hat 企業(yè)版Linux 6.2和DB2 9.7。

與上述的System x3650 M4虛擬化相比，這臺Flex x240節(jié)點的固態(tài)硬盤略重，磁盤驅(qū)動器略輕。我們假定，兩臺服務(wù)器上的磁盤不是性能瓶頸，并不是性能差別的實質(zhì)性原因(當然，你應(yīng)當擁有足夠的磁盤和主內(nèi)存來驅(qū)動CPU)，并假定與系統(tǒng)相連的這個磁盤和固態(tài)硬盤的總?cè)萘窟_到了TPC-C測試所要求驅(qū)動更多用戶時的容量限制，那么你可能會誤認為Flex x240服務(wù)器比System x3650 M4支持更多用戶數(shù)量，是由于它運行裸機的原因。當然，你還必須假定，RHEL 6.2和6.4之間所造成的性能差異是相當小的。

如果相信這一切假定和假設(shè)，那么KVM在單位時間命令處理次數(shù)上的開銷是12%，而如果你看看用戶，這個數(shù)字大約是13%左右。

如果像IBM公司只是測試裸機，并在完全相同的服務(wù)器(使用VMware的ESXi、Red Hat的KVM以及微軟公司的Hyper-V管理程序)上運行相同的工作負載，這一切就值得好好玩味一番了。但同樣，這也太容易了，這很容易讓公司得出錯誤的比較結(jié)果，從而做出錯誤的采購決策。

TPC-VMS測試說明了目前TPC測試的三個副本：較舊的TPC-C OLTP基準測試(模擬倉庫操作)、TPC-E在線股票經(jīng)紀基準測試、TPC-H數(shù)據(jù)倉庫測試，以及它在服務(wù)器的單一管理程序?qū)嵗系腡PC-DS決策支持/大數(shù)據(jù)測試。

順便說一句，還沒有人運行過TPC-VMS測試，IT供應(yīng)商可能會開始重復(fù)IBM公司剛剛完成的事情，并試圖讓人們看到虛擬化開銷。他們很可能會有所發(fā)現(xiàn)，或者坦白說他們不會得到什么回報。

配置和管理上的靈活性是值得付出一堆CPU周期資源的，如果不是這樣的話，Xen、Hyper-V以及KVM都不會出現(xiàn)。