吳平凡,劉顯德,吳少剛

1(東北石油大學(xué) 計(jì)算機(jī)與信息技術(shù)學(xué)院,大慶 163318)

2(江蘇航天龍夢(mèng)信息技術(shù)有限公司,蘇州 215500)

云計(jì)算中最關(guān)鍵的技術(shù)就是虛擬化技術(shù),用以實(shí)現(xiàn)不同獨(dú)立應(yīng)用間的資源共享.傳統(tǒng)的虛擬機(jī)技術(shù)由于過(guò)度的抽象化在實(shí)際生產(chǎn)環(huán)境中部署繁瑣,資源消耗過(guò)多,啟動(dòng)速度慢.自2013年以來(lái),隨著以Docker為代表的新一代容器技術(shù)的快速發(fā)展,已成為各大云計(jì)算廠(chǎng)商和云計(jì)算開(kāi)發(fā)者的首選.對(duì)比虛擬機(jī)技術(shù),Docker 具有應(yīng)用部署靈活,資源消耗少,啟動(dòng)速度快等優(yōu)點(diǎn),憑借輕量級(jí)的特性在虛擬化領(lǐng)域形成了顛覆性的影響[1].近年來(lái),國(guó)內(nèi)大量互聯(lián)網(wǎng)公司也紛紛進(jìn)行以新一代容器技術(shù)為核心進(jìn)行技術(shù)轉(zhuǎn)型,阿里在2017年11月正式開(kāi)源了其自研容器Pouch Container.而在2018年5月的全球軟件與運(yùn)維技術(shù)峰會(huì)上,知乎計(jì)算平臺(tái)宣布利用Docker 已實(shí)現(xiàn)全部業(yè)務(wù)和服務(wù)的容器化運(yùn)行.國(guó)內(nèi)外的Docker 相關(guān)研究[2,3]更是層出迭見(jiàn),這些現(xiàn)象表明新一代容器技術(shù)火熱的發(fā)展趨勢(shì).

在龍芯平臺(tái)虛擬化技術(shù)研究方面,早在2013年蔡萬(wàn)偉等人[4,5]就已經(jīng)做了大量關(guān)于MIPS 架構(gòu)下的內(nèi)存虛擬化研究.2016年王篁[6]為系統(tǒng)級(jí)的二進(jìn)制代碼兼容性?xún)?yōu)化提供了解決方案.2019年4月龍芯公司宣布龍芯KVM 虛擬機(jī)產(chǎn)品正式發(fā)布.而關(guān)于容器技術(shù)方面,龍芯平臺(tái)上Docker 方案還是停留在比較老舊的Fedora21 系統(tǒng)的Docker 老版本上,而新版Docker 需要進(jìn)一步在龍芯平臺(tái)上得以支持.

鑒于X86 的Fedora28 系統(tǒng)默認(rèn)安裝源為1.13.1 版本的Docker 方案,所以本文針對(duì)該版本進(jìn)行了移植并集成到龍芯平臺(tái)的Fedora28 系統(tǒng)中,并測(cè)試分析了新版Docker 方案在龍芯平臺(tái)下的性能表現(xiàn),憑借容器內(nèi)測(cè)試程序穩(wěn)定性更高的優(yōu)勢(shì),比較了容器內(nèi)同主頻下龍芯3A3000 與AMD Ryzen 5 (2400 GB)的性能表現(xiàn).

1 Docker 技術(shù)概述

作為一個(gè)熱門(mén)技術(shù),Docker 正處在快速發(fā)展的階段,新版本和新特性不斷涌現(xiàn)[7].1.13 版本作為Docker分離社區(qū)版和企業(yè)版前的最后一個(gè)版本,Docker 方案的整體架構(gòu)已經(jīng)逐漸穩(wěn)定下來(lái),如圖1 所示.

圖1 容器運(yùn)行時(shí)架構(gòu)圖

如今的Docker[8]方案,對(duì)于容器整個(gè)生命周期的管理操作都由Containerd 模塊[9]完成,Dockerd 將創(chuàng)建容器和運(yùn)行容器等操作直接發(fā)送給與Containerd 來(lái)完成,Containerd 收到請(qǐng)求后將啟動(dòng)一個(gè)Containerd-Shim 進(jìn)程來(lái)管理一個(gè)運(yùn)行的容器,通過(guò)Runc 模塊與容器進(jìn)行交互.Containerd 和Runc 結(jié)合起來(lái)成為了容器服務(wù)標(biāo)準(zhǔn)化的兩個(gè)重要部分.同時(shí)用戶(hù)可以直接在Containerd和Runc 上建立包括MicrosoftAzure、VMWare 在內(nèi)的多種上層應(yīng)用,并不僅僅局限于Docker 容器平臺(tái).其中的Runc 模塊是從Docker 的Libcontainer 中演化過(guò)來(lái)的,相當(dāng)于Libcontainer 模塊結(jié)合上一個(gè)小型的客戶(hù)端用以實(shí)現(xiàn)容器的啟動(dòng)停止和資源隔離等功能.作為應(yīng)用程序級(jí)的虛擬化技術(shù),如今的Docker 中通過(guò)Runc 模塊,即使繞過(guò)Daemon 守護(hù)進(jìn)程依然能夠直接運(yùn)行容器,某種程度上來(lái)說(shuō)已經(jīng)不依賴(lài)于Docker 本身了[10].

2 Docker 方案評(píng)測(cè)

龍芯平臺(tái)上的Fedora28 系統(tǒng)已經(jīng)發(fā)布,故本次測(cè)試將在移植Docker 1.13+版本到28 系統(tǒng)上后,使用測(cè)試工具對(duì)Docker 方案進(jìn)行測(cè)試,其中涉及的機(jī)器配置如表1.

2.1 Docker 移植

在進(jìn)行具體的測(cè)評(píng)工作之前需要對(duì)相應(yīng)的Docker方案進(jìn)行MIPS 平臺(tái)的編譯工作.由于官方提供的安裝方法是在容器內(nèi)自動(dòng)安裝,過(guò)程需要從Docker 官方鏡像倉(cāng)庫(kù)中拉取需要的Image 鏡像,涉及鏡像數(shù)量較多,且大量鏡像需要在MIPS 平臺(tái)上重新制作,故本次實(shí)驗(yàn)選擇手動(dòng)編譯的方式進(jìn)行移植,根據(jù)龍芯平臺(tái)Fedora28 系統(tǒng)的差異性對(duì)Docker 源碼進(jìn)行調(diào)整,添加MIPS 架構(gòu)入口標(biāo)識(shí),優(yōu)化不同架構(gòu)平臺(tái)的參數(shù)設(shè)置.

Docker 方案編譯工作完成后,測(cè)試準(zhǔn)備工作仍未完成,由于平臺(tái)架構(gòu)的差異性,測(cè)試工作中涉及的所有鏡像需要重新設(shè)計(jì).尤其是新版本Fedora28 系統(tǒng)的基礎(chǔ)鏡像,為預(yù)防可能出現(xiàn)的鏡像冗余問(wèn)題,需要重新制作一個(gè)單獨(dú)的精簡(jiǎn)系統(tǒng),并保證新系統(tǒng)安裝源的維護(hù).制作的Fedora28-base 鏡像已經(jīng)推送到Docker 官方倉(cāng)庫(kù)上,并同步更新下載源.

2.2 測(cè)試鏡像設(shè)計(jì)

為了對(duì)搭建好的Docker 平臺(tái)進(jìn)行綜合性能評(píng)估,分析龍芯CPU 上的Docker 性能表現(xiàn),在綜合考量大量性能測(cè)試工具后,基于實(shí)驗(yàn)可重復(fù)性和簡(jiǎn)潔性的考慮,選擇結(jié)合Unixbench 工具制作測(cè)試鏡像.因?yàn)閁nixbench 工具是一款非常經(jīng)典的系統(tǒng)基本性能測(cè)試工具,相對(duì)其他一些測(cè)試工具而言,它的測(cè)試項(xiàng)更為全面,而且能自動(dòng)化執(zhí)行一系列的測(cè)試命令,這更加契合測(cè)試鏡像的制作初衷,提高了測(cè)試效率.Unixbench 包括系統(tǒng)調(diào)用、IO 讀寫(xiě)、進(jìn)程、2D、3D、管道、運(yùn)算、C 庫(kù)等在內(nèi)的多種性能測(cè)試,測(cè)試結(jié)果不僅僅取決于CPU、內(nèi)存、硬盤(pán),還關(guān)乎硬件、開(kāi)發(fā)庫(kù)和編譯器等,能較為全面地綜合評(píng)價(jià)系統(tǒng)各方面性能.而且Unixbench 能將測(cè)試后的數(shù)據(jù)計(jì)算成相應(yīng)的分?jǐn)?shù)以供用戶(hù)參考,使測(cè)試結(jié)果更加直觀(guān)簡(jiǎn)潔.

重要的是,Unixbench 支持多CPU 系統(tǒng)的測(cè)試,默認(rèn)的測(cè)試行為是兩次,第一次進(jìn)行單進(jìn)程測(cè)試(Running 1 Parallel Copy of Tests),第二次則是進(jìn)行當(dāng)前系統(tǒng)CPU 個(gè)數(shù)的測(cè)試(Running N Parallel Copy of Tests).這樣的測(cè)試是為了測(cè)試系統(tǒng)多任務(wù)下并行處理的性能,以更為客觀(guān)地表現(xiàn)出實(shí)際數(shù)據(jù)結(jié)果.主要測(cè)試項(xiàng)如下:

(1)Dhrystone 測(cè)試:該測(cè)試用于衡量和比較計(jì)算機(jī)CPU 的性能,主要側(cè)重于整數(shù)計(jì)算,沒(méi)有浮點(diǎn)計(jì)算,受到編譯器和鏈接器選項(xiàng),軟硬件設(shè)計(jì)等影響較大.

(2)Whetstone 測(cè)試:這項(xiàng)主要用于測(cè)試浮點(diǎn)數(shù)的運(yùn)算和效率,包含大量C 語(yǔ)言函數(shù)、浮點(diǎn)數(shù)的運(yùn)算操作和若干科學(xué)計(jì)算的經(jīng)典性能模塊等.

(3)Execl Throughput 測(cè)試:Execl 吞吐量測(cè)試,用于測(cè)試Execl 函數(shù)每秒調(diào)用次數(shù),Execl 函數(shù)是Exec 函數(shù)家族的一部分,該函數(shù)族提供了在一個(gè)進(jìn)程中啟動(dòng)另外一個(gè)執(zhí)行程序的方法.

(4)Pipe Throughput 測(cè)試:用于測(cè)試進(jìn)程間的通信,即一秒鐘一個(gè)進(jìn)程寫(xiě)512 bite 到一個(gè)管道中并讀回來(lái)的次數(shù).

(5)Pipe-based Context Switching 測(cè)試:基于管道的上下文交互測(cè)試,這是兩個(gè)進(jìn)程通過(guò)管道進(jìn)行通信的次數(shù).

(6)Process Creation 測(cè)試:用于測(cè)試每秒創(chuàng)建進(jìn)程并立刻收回的次數(shù).

(7)Shell Scripts 測(cè)試:用于測(cè)試一定時(shí)間內(nèi)進(jìn)程可啟停Shell 腳本的次數(shù).

(8)System Call Overhead 測(cè)試:用于測(cè)試系統(tǒng)調(diào)用的性能,即重復(fù)執(zhí)行g(shù)etpid()函數(shù)調(diào)用時(shí)進(jìn)入和離開(kāi)內(nèi)核的時(shí)間.

2.3 不同容器數(shù)量的測(cè)試結(jié)果

測(cè)試分別在單核系統(tǒng)環(huán)境和四核系統(tǒng)環(huán)境下進(jìn)行以便分析容器下虛擬化性能損耗.首先對(duì)龍芯單路主機(jī)進(jìn)行Unixbench 測(cè)試作為基準(zhǔn)值記為Container Number = 0,然后在不同數(shù)量的Docker 容器內(nèi)同時(shí)運(yùn)行測(cè)試鏡像進(jìn)行性能測(cè)試.

這次實(shí)驗(yàn)中,設(shè)容器編號(hào)(Container Number)為0 時(shí)在宿主機(jī)上運(yùn)行測(cè)試,容器編號(hào)為N 時(shí)在同時(shí)運(yùn)行的N 個(gè)容器中運(yùn)行測(cè)試,對(duì)于每次測(cè)試重復(fù)執(zhí)行3 次以降低誤差的影響,每一項(xiàng)測(cè)試結(jié)果取所有的數(shù)據(jù)結(jié)果的平均值為最終值,即每次最終的測(cè)試數(shù)據(jù)DataN計(jì)算如下:

式中，uij表示在N 個(gè)容器同時(shí)運(yùn)行情況下,第j 個(gè)容器第i 次的測(cè)試數(shù)據(jù).

實(shí)際測(cè)試數(shù)據(jù)表如表2.

由于Unixbench 工具出于測(cè)試系統(tǒng)單任務(wù)性能與多任務(wù)下并行處理性能的目的,測(cè)試行為中有兩項(xiàng)測(cè)試,即單進(jìn)程測(cè)試(Running 1 Parallel Copy of Tests)和當(dāng)前系統(tǒng)CPU 個(gè)數(shù)的多進(jìn)程測(cè)試(Running N Parallel Copy of Tests,[CPU(N)]).單進(jìn)程測(cè)試中所有的處理器只處理一個(gè)測(cè)試進(jìn)程,而多進(jìn)程測(cè)試中所有的處理器同時(shí)運(yùn)行處理器數(shù)量個(gè)的測(cè)試進(jìn)程.由于單核系統(tǒng)環(huán)境環(huán)境下無(wú)需進(jìn)行并行處理的測(cè)試,故只有一個(gè)結(jié)果,這個(gè)測(cè)試結(jié)果既可以看作是單核系統(tǒng)下的單測(cè)試任務(wù)結(jié)果,也可以看作是多測(cè)試任務(wù)的結(jié)果.以下的數(shù)據(jù)分析中以多測(cè)試任務(wù)結(jié)果為主.

2.4 測(cè)試結(jié)果分析

Dhrystone 測(cè)試是測(cè)試處理器運(yùn)算能力的基準(zhǔn)程序之一,是各個(gè)測(cè)試項(xiàng)中最能反映CPU 能力的測(cè)試項(xiàng),所以著重分析這一項(xiàng)測(cè)試的結(jié)果,來(lái)研究虛擬化在龍芯上的影響.

表2 不同容器數(shù)量下的性能測(cè)試結(jié)果

從表2 中,以測(cè)試處理器運(yùn)算能力的基準(zhǔn)程序Dhrystone 測(cè)試的結(jié)果可以看出,四核環(huán)境下的測(cè)試中,隨著同時(shí)運(yùn)行測(cè)試程序的容器數(shù)量增加,機(jī)器的字符串處理性能幾近線(xiàn)性下降.如圖2.而在單核測(cè)試中,多容器下的性能以接近y=1/x 函數(shù)的形式呈曲線(xiàn)下降,如圖3,與基準(zhǔn)值(單容器測(cè)試數(shù)據(jù))相比,雙容器下Dhrystone 測(cè)試性能約為54.67%,三容器下Dhrystone測(cè)試性能約為44.16%,四容器下Dhrystone 測(cè)試性能約為33.04%.而其他的大部分測(cè)試項(xiàng),無(wú)論在四核還是單核條件下都有相似的結(jié)果,性能并不是呈線(xiàn)性下降的,比如Execl 函數(shù)測(cè)試和管道吞吐量測(cè)試等,因?yàn)橘Y源控制機(jī)制發(fā)揮了很大影響,它對(duì)CPU、內(nèi)存、磁盤(pán)等計(jì)算資源的使用進(jìn)行了調(diào)控.

而從表2 的第3 部分可以看到,在四核環(huán)境下的單進(jìn)程測(cè)試(Running 1 Parallel Copy of Tests)中,Dhrystone 測(cè)試的結(jié)果并沒(méi)有變化,這是由于四核環(huán)境下的系統(tǒng)運(yùn)算能力并未完全發(fā)揮出來(lái),即使是在4 個(gè)容器內(nèi)同時(shí)運(yùn)行測(cè)試任務(wù),也只是最大限度地體現(xiàn)了四核下的運(yùn)算能力,Dhrystone 測(cè)試的單進(jìn)程測(cè)試平均結(jié)果為473.0,稍高于單核測(cè)試中的雙容器測(cè)試結(jié)果14.7%,多進(jìn)程測(cè)試平均結(jié)果為492.2,高于基準(zhǔn)值16.6%.

而Whetstone 測(cè)試結(jié)果來(lái)看,數(shù)據(jù)結(jié)果十分穩(wěn)定,即使在八容器的測(cè)試實(shí)驗(yàn)中,Whetstone 測(cè)試在單進(jìn)程測(cè)試中的平均結(jié)果也是200.2,多進(jìn)程下結(jié)果是794.5,誤差幾乎可以忽略不計(jì),再結(jié)合Dhrystone 測(cè)試的結(jié)果,可以確定容器虛擬化給CPU 的計(jì)算能力帶來(lái)?yè)p耗非常小.

圖2 Dhrystone 測(cè)試CPU(4)for 4 tests

圖3 Dhrystone 測(cè)試CPU(1)for 1 test

就龍芯單路主機(jī)上的測(cè)試結(jié)果和單容器測(cè)試的基準(zhǔn)值比較,本文發(fā)現(xiàn),在四核環(huán)境下,主機(jī)上的Dhrystone測(cè)試結(jié)果是基準(zhǔn)值的96.17%,單核環(huán)境下是基準(zhǔn)值的96.0%,而其他的一些測(cè)試項(xiàng)并未有這樣的結(jié)果,因此推測(cè),這是由于容器內(nèi)的鏡像系統(tǒng)是輕量化的精簡(jiǎn)系統(tǒng),在測(cè)試程序執(zhí)行過(guò)程中CPU 對(duì)于其他可能存在的負(fù)載程序的支持更為輕松,所以測(cè)試結(jié)果顯示的相關(guān)計(jì)算能力會(huì)較為優(yōu)越,這一結(jié)果也更加體現(xiàn)了Docker鏡像的制作對(duì)于實(shí)際應(yīng)用中可能產(chǎn)生重要影響,一個(gè)優(yōu)越的輕量化鏡像能更好地提升容器集群的性能和實(shí)際運(yùn)行的流暢度.

3 龍芯平臺(tái)與X86 平臺(tái)下的測(cè)試比較

3.1 與銳龍5 處理器的對(duì)比測(cè)試

作為比較對(duì)象,X86 平臺(tái)下選擇的是搭載AMD 銳龍5 處理器的機(jī)器,硬件參數(shù)表如表3.

容器內(nèi)的測(cè)試更不容易受到誤差因素干擾,可靠性和穩(wěn)定性更強(qiáng),因此在實(shí)際實(shí)驗(yàn)中,分別在龍芯的單路服務(wù)器、雙路服務(wù)器和四路服務(wù)器上的測(cè)試容器內(nèi)進(jìn)行Unixbench 測(cè)試,并在搭載AMD Ryzen 5 2400 GB芯片的X86 機(jī)器上運(yùn)行同樣的測(cè)試容器,由于Unixbench工具的測(cè)試特性分為兩項(xiàng)測(cè)試結(jié)果,相關(guān)測(cè)試結(jié)果如表4 和表5 所示.

表3 X86 平臺(tái)硬件參數(shù)表

表4 Unixbench 測(cè)試結(jié)果(Running 1 Parallel Copy of Tests)

表5 Unixbench 測(cè)試結(jié)果(Running N Parallel Copy of Tests [CPU(N)])

由于Ryzen 5(2400 GB)處理器上的CPU 主頻是動(dòng)態(tài)的,因此為保證測(cè)試數(shù)據(jù)的客觀(guān)性和對(duì)比實(shí)驗(yàn)的可行性,在BIOS 選項(xiàng)中設(shè)置了搭載Ryzen 5 處理器的主機(jī)主頻,然后通過(guò)不斷讀取/proc/cpuinfo 文件信息,確認(rèn)主機(jī)的主頻均值在1.45 GHz 左右,與龍芯雙路服務(wù)器主頻相近.

龍芯雙路、四路服務(wù)器下CPU 主頻為1.45 GHz,單路主機(jī)為1.5 GHz,實(shí)際測(cè)試數(shù)據(jù)表如表4 和表5.

3.2 測(cè)試結(jié)果分析

在單進(jìn)程測(cè)試下(Running 1 Parallel Copy of Tests),由于只有一個(gè)測(cè)試進(jìn)程,所以無(wú)論處理器的核心數(shù)量是多少,都只有一個(gè)測(cè)試進(jìn)程在執(zhí)行,相當(dāng)于在一個(gè)核心上進(jìn)行性能測(cè)試,故首先可以從最能體現(xiàn)芯片性能的兩項(xiàng)測(cè)試Dhrystone 測(cè)試和Whetstone 測(cè)試開(kāi)始分析,如圖4 所示.

首先從單個(gè)芯片的性能數(shù)據(jù)開(kāi)始比較,主要以MIPS_CPU(8)和X86_CPU(8)下的結(jié)果進(jìn)行比較.根據(jù)表4 和圖4,可以看到在Dhrystone 測(cè)試方面,雙路服務(wù)器中單核心龍芯性能分?jǐn)?shù)為687.9,X86 下的測(cè)試分?jǐn)?shù)為1795.6,龍芯在容器內(nèi)進(jìn)行Dhrystone 測(cè)試的執(zhí)行效率大約是Ryzen 5 (2400 GB)的38.3%,而在與科學(xué)計(jì)算性能相關(guān)的Double-Precision Whetstone 測(cè)試中,龍芯的運(yùn)算效率大約是Ryzen 5 (2400 GB)的37.4%左右,由兩個(gè)測(cè)試項(xiàng)數(shù)據(jù)結(jié)合確定了龍芯雙路服務(wù)器在運(yùn)行單個(gè)測(cè)試進(jìn)程時(shí)CPU 計(jì)算性能約為搭載Ryzen 5主機(jī)的40% 左右.但這僅僅是單個(gè)測(cè)試進(jìn)程的結(jié)果,而基于Unixbench 測(cè)試工具的設(shè)計(jì)理念,多進(jìn)程測(cè)試的結(jié)果更為貼近實(shí)際的應(yīng)用場(chǎng)景表現(xiàn)出來(lái)的性能,因此需要著重分析多進(jìn)程測(cè)試的數(shù)據(jù)結(jié)果.根據(jù)表5,可以得到多進(jìn)程測(cè)試下的Dhrystone 測(cè)試和Whetstone測(cè)試數(shù)據(jù)結(jié)果,如圖5.

圖4 Dhrystone 測(cè)試和Whetstone 測(cè)試數(shù)據(jù)(1 parallel test)

圖5 Dhrystone 測(cè)試和Whetstone 測(cè)試數(shù)據(jù)(N parallel tests)

從圖5 中很清晰地看到,在龍芯雙路服務(wù)器中,Dhrystone 測(cè)試的整數(shù)計(jì)算性能約為搭載Ryzen 5 主機(jī)的63.6%,Whetstone 測(cè)試的浮點(diǎn)數(shù)計(jì)算性能約為44.8%,后續(xù)在進(jìn)行驗(yàn)證性測(cè)試時(shí)發(fā)現(xiàn),數(shù)據(jù)結(jié)果基本穩(wěn)定在測(cè)試數(shù)據(jù)的附近區(qū)間內(nèi),誤差大約在3%左右浮動(dòng),說(shuō)明數(shù)據(jù)是可靠的.因此可以確定,處理器核心數(shù)量越多,基于Dhrystone 測(cè)試和Whetstone 測(cè)試得到的性能分?jǐn)?shù)越高,機(jī)器整數(shù)運(yùn)算性能和浮點(diǎn)數(shù)運(yùn)算能力越強(qiáng),而相等的處理器核心數(shù)量下,龍芯3A3000 芯片的相關(guān)計(jì)算性能約為Ryzen 5(2400 GB)芯片的40～60%.其中多進(jìn)程測(cè)試下,與Ryzen 5 主機(jī)相比,龍芯雙路服務(wù)器的性能表現(xiàn)從38.3%提高到了63.6%,這是由于龍芯雙路服務(wù)器是八塊CPU 芯片,而Ryzen 5主機(jī)只是四塊CPU 八核心的處理器結(jié)構(gòu).其他項(xiàng)的測(cè)試可見(jiàn)圖6 和圖7.

圖6 Pipe 相關(guān)測(cè)試數(shù)據(jù)(N parallel tests)

圖7 進(jìn)程相關(guān)測(cè)試數(shù)據(jù)(N parallel tests)

管道吞吐(Pipe Throughput)和交互測(cè)試(Pipebased Context Switching)兩項(xiàng)測(cè)試中,龍芯雙路服務(wù)器上的性能分?jǐn)?shù)分別是2931.3 和980.9,大約為Ryzen 5(2400 GB)下的76.3%和70.1%.這兩項(xiàng)測(cè)試表明在相近主頻下,龍芯雙路服務(wù)器在進(jìn)程通信效率上大約為Ryzen 5(2400 GB)主機(jī)的70%～76%.其他與系統(tǒng)性能相關(guān)測(cè)試的還有Process Creation 測(cè)試,用于測(cè)試每秒創(chuàng)建進(jìn)程并回收的次數(shù),龍芯雙路服務(wù)器性能約為Ryzen 5 (2400 GB)的30%左右;Shell Scripts 測(cè)試用于測(cè)試一定時(shí)間內(nèi)進(jìn)程可啟停Shell 腳本的次數(shù),龍芯雙路服務(wù)器性能約為Ryzen 5 (2400 GB)的48%左右.因此綜合來(lái)看,同樣的Fedora28 系統(tǒng)的容器運(yùn)行環(huán)境下,龍芯雙路服務(wù)器的系統(tǒng)綜合性能大約為Ryzen 5 (2400 GB)的50%左右.

3.3 Docker 方案綜合分析

首先,Docker 方案在移植到龍芯Fedora28 系統(tǒng)上之后,運(yùn)行狀態(tài)良好,穩(wěn)定性可靠性大幅提升,同時(shí)經(jīng)過(guò)大量驗(yàn)證性實(shí)驗(yàn)之后可以肯定,容器內(nèi)的性能分?jǐn)?shù)稍高于主機(jī)環(huán)境約5%左右,在排除誤差帶來(lái)的影響之后,體現(xiàn)了容器本身的輕量級(jí)技術(shù)的特性,同時(shí)也印證了鏡像構(gòu)建的重要性,可以預(yù)測(cè)一個(gè)優(yōu)越的輕量化鏡像能更好地提升容器集群的性能和實(shí)際運(yùn)行的流暢度,所以在后續(xù)構(gòu)建和維護(hù)龍芯平臺(tái)的Docker 鏡像倉(cāng)庫(kù)中同樣需要秉持認(rèn)真負(fù)責(zé)的態(tài)度.

其次,本文發(fā)現(xiàn)多容器狀態(tài)的測(cè)試數(shù)據(jù)并不穩(wěn)定,而且產(chǎn)生了一些性能損失,這是因?yàn)槿萜鲗?duì)于資源管理功能的實(shí)現(xiàn)仍然深深依賴(lài)與Linux 系統(tǒng)內(nèi)核的自身特性,由于Docker 方案本身就是基于傳統(tǒng)LXC 技術(shù)實(shí)現(xiàn)的應(yīng)用程序容器技術(shù)[10],旨在提供標(biāo)準(zhǔn)運(yùn)行環(huán)境,實(shí)現(xiàn)底層操作系統(tǒng)與物理主機(jī)的解耦.因此,在容器數(shù)量增加到一定程度后,可以預(yù)見(jiàn)到容器間資源的不合理行為會(huì)變得十分頻繁從而影響整個(gè)的容器集群.從本次測(cè)試的多容器數(shù)量的性能趨勢(shì)中可窺一斑,所以在之后的實(shí)驗(yàn)研究中,將把研究重點(diǎn)放到容器的動(dòng)態(tài)調(diào)度算法和集群負(fù)載均衡策略?xún)?yōu)化上去,通過(guò)容器調(diào)度策略等設(shè)計(jì)優(yōu)化容器的實(shí)際應(yīng)用環(huán)境.

同時(shí),根據(jù)借助容器環(huán)境在Ryzen 5 (2400 G)處理器上實(shí)現(xiàn)的對(duì)比實(shí)驗(yàn),本文發(fā)現(xiàn),目前主流的龍芯芯片3A3000 與Ryzen 5 (2400 GB)芯片相比CPU 計(jì)算性能約在60%左右,這是龍芯雙路服務(wù)器與八核的Ryzen 5 (2400 GB)機(jī)器在進(jìn)行多進(jìn)程測(cè)試時(shí)比較得到的結(jié)果.如果就單進(jìn)程測(cè)試而言,龍芯3A3000 的性能大約是Ryzen 5 (2400 GB)的一半,如果綜合考慮所有系統(tǒng)性能測(cè)試項(xiàng),龍芯雙路服務(wù)器的綜合評(píng)分大約有搭載Ryzen 5 (2400 GB)主機(jī)的50%左右.

4 結(jié)束語(yǔ)

經(jīng)過(guò)分析本文得到以下結(jié)論:一是龍芯平臺(tái)上的新版Docker 方案適應(yīng)性良好,穩(wěn)定性可靠性大大提高,并且發(fā)現(xiàn)輕量化的鏡像會(huì)略微提升容器內(nèi)隔離進(jìn)程的運(yùn)行效率,這體現(xiàn)了容器本身的輕量級(jí)技術(shù)的特性,同時(shí)也印證了鏡像構(gòu)建工作的重要性;二是通過(guò)性能數(shù)據(jù)的漸變趨勢(shì),可以預(yù)測(cè)高容器數(shù)量級(jí)下整個(gè)集群系統(tǒng)性能會(huì)產(chǎn)生很大損失,僅僅依賴(lài)Linux 內(nèi)核特性進(jìn)行資源管理是遠(yuǎn)遠(yuǎn)不夠的,所以下一步研究將集中在容器集群模式下的負(fù)載均衡策略和動(dòng)態(tài)調(diào)度算法設(shè)計(jì)上去;三是在容器中,經(jīng)過(guò)與Ryzen 5 (2400 GB)芯片的對(duì)比實(shí)驗(yàn)發(fā)現(xiàn),根據(jù)Dhrystone 測(cè)試和Whetstone 測(cè)試結(jié)果,龍芯3A3000 芯片在CPU 計(jì)算性能方面大約是Ryzen 5 (2400 GB)芯片性能的40%～60%左右,多進(jìn)程測(cè)試中Dhrystone 測(cè)試性能約為Ryzen 5 (2400 GB)的63.6%.綜合考慮所有系統(tǒng)性能測(cè)試項(xiàng),龍芯雙路服務(wù)器的綜合性能評(píng)分大約為搭載Ryzen 5 (2400 GB)主機(jī)的50% 左右.但是微架構(gòu)優(yōu)化后的下一代龍芯3A4000 芯片即將推出,性能方面將會(huì)有更大的提升,國(guó)產(chǎn)化CPU 事業(yè)會(huì)發(fā)展的越來(lái)越好.