龍芯平臺1.13版本Docker移植研究

吳平凡 劉顯德 吳少剛

1(東北石油大學(xué)計算機(jī)與信息技術(shù)學(xué)院 黑龍江 大慶 163318) 2(江蘇航天龍夢信息技術(shù)有限公司 江蘇 蘇州 215500)

0 引 言

虛擬化技術(shù)是一種被廣泛應(yīng)用的硬件資源共享技術(shù)，不僅包括了以KVM、Xen、Hyper-V、VMware ESXi為代表的傳統(tǒng)硬件級虛擬化技術(shù)，近年來以Docker為代表的新一代容器技術(shù)，在克服了傳統(tǒng)容器技術(shù)難以標(biāo)準(zhǔn)化的困難后，憑借輕量級的特性在虛擬化領(lǐng)域形成了顛覆性的影響[1]。

事實(shí)上，傳統(tǒng)的容器技術(shù)數(shù)十年前就已經(jīng)出現(xiàn)，比如常見的Chroot[2]命令在1979年就已經(jīng)出現(xiàn)，被認(rèn)為是最早的容器化技術(shù)之一，用來隔離一個進(jìn)程的文件系統(tǒng)。還有BSD jails、LXC、OpenVZ、Linux VServer等技術(shù)都可以稱為傳統(tǒng)容器技術(shù)[3-4]。

由于傳統(tǒng)容器技術(shù)未能提供應(yīng)用標(biāo)準(zhǔn)化的運(yùn)行環(huán)境，因此在許多應(yīng)用領(lǐng)域中隨著虛擬機(jī)技術(shù)的廣泛運(yùn)用而逐漸銷聲匿跡。新一代的容器技術(shù)則從一開始就以提供標(biāo)準(zhǔn)化的運(yùn)行時環(huán)境為目標(biāo)，實(shí)現(xiàn)了底層操作系統(tǒng)與物理主機(jī)的解耦。因此Docker這一類新容器技術(shù)往往被稱作應(yīng)用程序容器，旨在為單個進(jìn)程進(jìn)行打包和運(yùn)行服務(wù)。

X86平臺上關(guān)于Docker技術(shù)的相關(guān)研究[5-7]很早便已經(jīng)展開。龍芯[8-10]是我國第一個自主研發(fā)的通用微處理器，基于龍芯3A/3B 3000系列的計算機(jī)和服務(wù)器已經(jīng)在國家核心部門的關(guān)鍵信息系統(tǒng)中得到了批量應(yīng)用。隨著云計算模式的普及，對支持虛擬化技術(shù)的龍芯服務(wù)器系統(tǒng)的需求日益迫切。在龍芯平臺上的虛擬化技術(shù)研究方面，相關(guān)文獻(xiàn)進(jìn)行了關(guān)于MIPS架構(gòu)下的內(nèi)存虛擬化研究[11-12]，以及支持跨指令集二進(jìn)制代碼兼容性的虛擬機(jī)方案研究[13]。而在容器技術(shù)支持方面，龍芯平臺Fedora21系統(tǒng)支持1.6.0版本Docker方案，而Docker技術(shù)隨著Linux內(nèi)核升級有了較大的架構(gòu)級更新，本文工作源自龍芯平臺Fedora28系統(tǒng)對1.13版本Docker的需求，對國產(chǎn)龍芯服務(wù)器在云模式下的應(yīng)用推廣具有重要的工程應(yīng)用價值。

鑒于X86的Fedora28系統(tǒng)安裝源初始默認(rèn)Docker1.13.1方案，所以本文針對該版本進(jìn)行了面向龍芯平臺的移植優(yōu)化，添加了NETNS相關(guān)的MIPS架構(gòu)參數(shù)，變換了設(shè)備號存儲變量格式，去除了冗余的信號變量定義，支持新的存儲驅(qū)動模式，利用OVERLAY2存儲驅(qū)動重新構(gòu)建了龍芯Fedora28系統(tǒng)的鏡像倉庫和常用鏡像。評測結(jié)果表明，移植優(yōu)化后的1.13版本Docker方案在龍芯平臺上表現(xiàn)良好，相比老版本Docker方案系統(tǒng)調(diào)用消耗降低了10%左右，進(jìn)程通信相關(guān)性能提升了50%左右。

1 Docker技術(shù)

1.1 Docker架構(gòu)演化

從發(fā)布至今，Docker這個基于Go語言開發(fā)，利用Linux Container技術(shù)的核心管理引擎受到越來越多的關(guān)注和應(yīng)用。在2017年3月，Docker分為兩種版本：提供給個人開發(fā)者和小型團(tuán)隊使用的社區(qū)版CE，以及提供收費(fèi)服務(wù)的企業(yè)版EE。同時分離了Github上托管的源代碼倉庫，將原Docker項目改名為Moby，由Moby這個新的用于推進(jìn)軟件容器化運(yùn)動的開源項目組織與社區(qū)開發(fā)者共同維護(hù)[14]。雖然版本號的變化十分劇烈，但是Docker 17.03+版本的接口仍然沿用1.13+并完全兼容。

Docker早期的架構(gòu)是簡單的Client-Server架構(gòu)，通過TCP或UNIX套接字向在Host上運(yùn)行的Daemon守護(hù)進(jìn)程發(fā)送請求命令獲取服務(wù)。

之后在1.10版本時推出了Libcontainer模塊，將底層實(shí)現(xiàn)都抽象化到Libcontainer的接口上，使得底層容器的實(shí)現(xiàn)變?yōu)橐环N可控方案。2015年6月，OCI(Open Container Initiative)組織成立以實(shí)現(xiàn)開放容器的標(biāo)準(zhǔn)化，主要包括容器運(yùn)行時標(biāo)準(zhǔn)(Runtime Spec)和容器景象標(biāo)準(zhǔn)(Image Spec)。因此為適應(yīng)OCI開放容器標(biāo)準(zhǔn)，Docker容器的運(yùn)行不再是簡單地由容器守護(hù)進(jìn)程Daemon來啟動，而是通過Dockerd集成Containerd、Runc等多個組件來實(shí)現(xiàn)容器的啟動，Daemon進(jìn)程在不斷地重構(gòu)過程中功能漸漸拆分細(xì)化，被分配到了各個單獨(dú)的模塊中，如圖1所示。

圖1 容器運(yùn)行時各組件間關(guān)系

Dockerd以Engine API(REST)的方式對外提供服務(wù)，將所有對于容器的創(chuàng)建和運(yùn)行等操作都通過GRPC協(xié)議發(fā)送給Containerd來完成。Containerd收到容器發(fā)送的請求后，進(jìn)行初始化然后啟動Containerd-Shim進(jìn)程，并傳送相關(guān)的配置參數(shù)給它。Containerd負(fù)責(zé)宿主機(jī)上所有運(yùn)行的容器，而相應(yīng)的一個Containerd-Shim則只管理一個運(yùn)行的容器，使整個容器管理過程更為穩(wěn)定高效。

1.2 Docker容器原理

Docker的底層實(shí)現(xiàn)機(jī)制是通過Namespaces(命名空間)、Control Groups(控制組)等技術(shù)來實(shí)現(xiàn)操作系統(tǒng)級的虛擬化機(jī)制。同時Docker需要一種文件系統(tǒng)作為Docker鏡像的存儲方式。

OVERLAY2是所有Linux發(fā)行版的首選存儲驅(qū)動程序。但以前的Ubuntu內(nèi)核不支持OVERLAY2，因此使用AUFS作為存儲驅(qū)動，而龍芯平臺以前的Fedora21系統(tǒng)上是使用DEVICEMAPPER作為存儲驅(qū)動的，性能差且穩(wěn)定性不好，因此Fedora28上支持了OVERLAY2存儲驅(qū)動。

OVERLAYFS其實(shí)是一種與AUFS類似的聯(lián)合文件系統(tǒng)UFS[15](Union Filesystem)，它將單個Linux主機(jī)上的兩個目錄(lowerdir和upperdir)合并成一個目錄(merged)。這些目錄稱之為層(layer)，而這個統(tǒng)一過程則被稱為聯(lián)合掛載(Union Mount)。其中，OVERLAYFS的底層目錄稱為Lowerdir，可以將其看作是只讀的鏡像層，用戶無法直接進(jìn)行操作。而高層目錄稱為Upperdir，可以看作是可讀寫的容器層，當(dāng)需要修改一個文件時，需要將文件從只讀的底層目錄拷貝到可寫的頂層目錄中進(jìn)行修改，同時將修改結(jié)果保存在頂層目錄中。而合并統(tǒng)一視圖則稱為Merged，如圖2所示。

圖2 Docker構(gòu)造映射到OVERLAYFS結(jié)構(gòu)

當(dāng)文件系統(tǒng)掛載后，用戶就可以在Merge目錄下看到來自不同底層目錄中的內(nèi)容，也無須感知這些文件來自具體的哪一個目錄，并保證上層目錄屏蔽下層目錄的同名文件。

2 Docker方案移植與優(yōu)化

由于MIPS體系結(jié)構(gòu)與X86間的差異性，為了完成1.13版本Docker的移植過程，首先需要調(diào)整Docker的底層模塊結(jié)構(gòu)以解決架構(gòu)差異性問題，主要移植過程和優(yōu)化內(nèi)容包括：

(1) 對Docker的一些底層模塊添加MIPS架構(gòu)入口。

(2) 針對Docker部分結(jié)構(gòu)代碼，添加MIPS下的特有參數(shù)以實(shí)現(xiàn)Docker方案對MIPS的支持。

(3) 根據(jù)Fedora28系統(tǒng)新的4.19.5版本內(nèi)核變化，重構(gòu)Docker關(guān)于信號機(jī)制部分的結(jié)構(gòu)。

(4) 采用OVERLAY2存儲驅(qū)動用以鏡像存儲。

然后設(shè)計評測方案對優(yōu)化效果進(jìn)行評測，硬件環(huán)境的龍芯計算機(jī)參數(shù)配置如表1所示。

表1 龍芯計算機(jī)參數(shù)表

2.1 Docker移植過程

不同架構(gòu)平臺，移植過程中會出現(xiàn)很多差異性問題，所以首先需要解決Docker方案的平臺差異性問題，Docker底層的模塊函數(shù)針對不同的架構(gòu)需要不同參數(shù)以便識別。

2.1.1添加SETNS調(diào)用的識別

Docker方案中引用SETNS調(diào)用以允許進(jìn)程更改命名空間，但是調(diào)用參數(shù)SYS_SETNS并沒有MIPS架構(gòu)的相關(guān)標(biāo)識，因此針對SETNS調(diào)用部分的代碼需要添加MIPS架構(gòu)識別入口。

Docker利用命名空間機(jī)制(Namespace)將內(nèi)核的全局資源封裝，使各容器在各自命名空間中對同一種資源的應(yīng)用不會互相干擾，其中的Netns被用于實(shí)現(xiàn)網(wǎng)絡(luò)、計算等資源的隔離。

在Linux內(nèi)核3.0版本之后引入了一個新的系統(tǒng)調(diào)用SETNS以更好地處理命名空間的相關(guān)操作。Linux為其句柄中的許多資源支持不同的命名空間，例如Docker方案向虛擬化進(jìn)程展示了一個不同于真實(shí)PID的虛擬PID，還有文件系統(tǒng)目錄結(jié)構(gòu)、網(wǎng)絡(luò)資源、IPC等也可以這樣做。設(shè)置不同命名空間配置的唯一方法是在CLONE系統(tǒng)調(diào)用中使用不同的標(biāo)識，但該系統(tǒng)調(diào)用無法執(zhí)行允許一個進(jìn)程訪問另一個進(jìn)程的命名空間之類的操作，而SETNS調(diào)用解決了這個問題。因此移植過程中需要在netns_linux.go文件中添加MIPS架構(gòu)識別入口：

var SYS_SETNS=map[string]uintptr{

"386": 346,

"amd64": 308,

……

"mips": 5303，

}[runtime.GOARCH]

2.1.2添加BoltDB的MIPS參數(shù)

Bolt是一個基于Go語言編寫的純粹Key/Value模型的項目。Bolt項目的目標(biāo)是為那些不需要完整數(shù)據(jù)庫服務(wù)器的項目提供便捷、快速、可靠的數(shù)據(jù)庫。由于BoltDB的設(shè)計是源自LMDB，因此主要具有可以直接使用API進(jìn)行數(shù)據(jù)的存取的特點(diǎn)，沒有像SQL一樣的查詢語句，而且沒有線程壓縮、垃圾回收和wal，而是直接將數(shù)據(jù)保存在內(nèi)存映射的文件里。并且BoltDB支持完全可序列化的ACID事務(wù)，具有比LevelDB更強(qiáng)的特性，同時通過COW技術(shù)實(shí)現(xiàn)了無鎖的讀寫并發(fā)，但不能實(shí)現(xiàn)無鎖的寫寫并發(fā)，因此BoltDB更適合于讀多寫少的應(yīng)用場景。

在Docker的底層結(jié)構(gòu)里，BoltDB被應(yīng)用于Containerd等組件的ID信息存取，由于BoltDB在Github上不再維護(hù)，因此目前Docker項目已經(jīng)將BoltDB模塊合并到了Libnetwork當(dāng)中，但是由于BoltDB在Docker的底層實(shí)現(xiàn)結(jié)構(gòu)里與許多組件耦合度很強(qiáng)故無法刪除。Docker方案里BoltDB的函數(shù)文件需要為不同的架構(gòu)平臺單獨(dú)定義兩個變量maxMapSize和maxAllocSize，分別表示Bolt支持的最大MMAP大小和創(chuàng)建數(shù)組指針時使用的大小兩個參數(shù)，1.6版本Docker方案添加了bolt_mips64le.go后設(shè)置的是：

const maxMapSize=0x3FFFFFFF

const maxAllocSize=0x7FFFFFFF

經(jīng)過實(shí)際應(yīng)用狀況的反饋并結(jié)合新的Feodra28系統(tǒng)我們需要設(shè)置一個合理的參數(shù)：

const maxMapSize=0x8000000000

const maxAllocSize=0x7FFFFFFF

2.1.3設(shè)備號存儲變量格式轉(zhuǎn)換

由于X86和龍芯Fedora28系統(tǒng)中使用了不同的設(shè)備號存儲變量格式，需要針對涉及相應(yīng)變量引用部分的模塊代碼進(jìn)行修改和重構(gòu)。

Linux下的數(shù)據(jù)成員st_dev的值記錄了文件主次設(shè)備號的信息，而一些字符特殊設(shè)備和塊特殊設(shè)備還含有st_rdev的值，st_rdev包含了實(shí)際設(shè)備的設(shè)備號。主設(shè)備號可以區(qū)分擁有相同驅(qū)動程序的同一類設(shè)備，而次設(shè)備號則用于具體指向某一個設(shè)備以區(qū)分同一類型的不同設(shè)備。文件的主次設(shè)備號雖然是兩個信息，但全部包含于st_dev的值里，而st_dev的基本數(shù)據(jù)類型是dev_t，內(nèi)核用dev_t類型來保存設(shè)備編號。在不同的架構(gòu)下其實(shí)際占用的位數(shù)可能不盡相同，如X86下的dev_t是64位，默認(rèn)編碼是MMMM Mmmm mmmM MMmm，8位表示主設(shè)備號，8位表示次設(shè)備號。而龍芯的Fedora28系統(tǒng)中使用了32位的dev_t，編碼為mmmM MMmm，3位表示主設(shè)備號，5位表示次設(shè)備號。

由于Docker方案默認(rèn)使用64位無符號整型格式的變量rdev讀取設(shè)備號信息，所以為解決MIPS架構(gòu)下的差異性，需要對rdev變量的格式進(jìn)行轉(zhuǎn)換，在stat_linux.go文件中修改rdev：

func fromStatT(s*syscall.Stat_t)(*StatT,error){

return &StatT{size:s.Size,

……

rdev:uint64(s.Rdev)，

……

}}

2.2 Docker信號機(jī)制優(yōu)化

每一個信號都有一個以SIG開始的獨(dú)特名字，但MIPS架構(gòu)下的Fedora28系統(tǒng)與X86架構(gòu)下存在大量的差異，即使是信號名字相同的信號在不同操作系統(tǒng)中的編號ID也不一致，而且許多信號在新的Fedora28系統(tǒng)里已不存在。因此在移植過程中結(jié)合新系統(tǒng)的特性優(yōu)化Docker方案對信號機(jī)制的設(shè)計，去除在MIPS下冗余的信號。

首先是協(xié)處理器堆棧錯誤信號SIGSTKFLT，這個信號在新的Fedora28系統(tǒng)被去除。協(xié)處理器是一種協(xié)助中央處理器完成其無法執(zhí)行或執(zhí)行效率低下的處理工作而應(yīng)用的處理器，在MIPS體系結(jié)構(gòu)里能夠最多支持4個協(xié)處理器。在X86系統(tǒng)中有14個16位寄存器，這14個寄存器主要劃分為四類：通用寄存器、指令指針寄存器、標(biāo)志寄存器和段寄存器。而在MIPS體系結(jié)構(gòu)[16]里，寄存器要比X86多，達(dá)到了35個，其中有32個通用寄存器，兩個用于存儲整數(shù)乘除和累加操作的特殊功能寄存器和一個由特定指令直接操作的特殊功能程序計數(shù)器PC(program counter)，以及一個FPU寄存器。同時，在MIPS體系結(jié)構(gòu)中協(xié)處理器CP0有32個寄存器，主要用于更好地控制CPU，實(shí)現(xiàn)MMU、乘除法或者異常處理等功能。

這個信號變量是一個在早期的Linux系統(tǒng)中存在的信號，用于數(shù)字協(xié)處理器的堆棧錯誤，在內(nèi)核中并不會產(chǎn)生，但是為了系統(tǒng)的兼容性考慮在X86的系統(tǒng)中仍然被保留了下來。而在龍芯平臺的Fedora28系統(tǒng)中，由于架構(gòu)的差異并出于標(biāo)準(zhǔn)化和穩(wěn)定性的考量便去除了那些沒有價值的冗余信號。如今在MIPS中取代SIGSTKFLT信號作用的是SIGEMT信號。同時，由于平臺的差異性，在MIPS平臺下SIGUNUSED信號也變?yōu)榱薙IGSYS來表示系統(tǒng)的無效調(diào)用，Docker方案中使用SignalMap數(shù)組對應(yīng)Linux信號的映射：

SignalMap=map[string]syscall.Signal

所以在移植過程中，根據(jù)不同平臺信號機(jī)制的不同，我們需要修改signal_linux.go文件中的SignalMap數(shù)組，刪除SIGSTKFLT和SIGUNUSED信號的映射"STKFLT"和"UNUSED"，同時設(shè)置64位MIPS系統(tǒng)下的SIGRTMAX參數(shù)為127。

2.3 Docker存儲驅(qū)動優(yōu)化

Docker鏡像是由一系列的層(Layer)組成的，同時支持多種Graphdriver，如AUFS、DEVICEMAPPER、OVERLAY、OVERLAY2，而1.6版本的Docker方案由于Fedora21系統(tǒng)內(nèi)核原因，無法支持當(dāng)時主流的AUFS系統(tǒng)，因此采用了DEVICEMAPPER用作鏡像的存儲模式，而Fedora28系統(tǒng)內(nèi)核滿足支持目前主流的OVERLAY2存儲驅(qū)動的要求。

在經(jīng)過詳細(xì)的性能比較之后，確定OVERLAY和OVERLAY2兩種驅(qū)動的性能表現(xiàn)都比傳統(tǒng)的AUFS和DEVICEMAPPER強(qiáng)很多，因此Docker在移植方案中選擇OVERLAY2作為鏡像存儲的首選。

盡管OVERLAYFS十分優(yōu)秀但當(dāng)前仍不夠完美。由于OVERLAY是使用硬鏈接在層之間共享文件的，每一層都構(gòu)建了一個完整的鏡像而增加了磁盤的Inode負(fù)擔(dān)，并且會由于系統(tǒng)對硬鏈接的限制在容器數(shù)量多至一定程度時出現(xiàn)問題，而增加文件系統(tǒng)可用Inode數(shù)量的唯一方法就是重新格式化。所以，OVERLAY2在鏡像層之間共享數(shù)據(jù)的方法改成了通過每層的lower文件，每一層都是完全獨(dú)立通過多層Lowerdir進(jìn)行掛載。這種方法會消耗更少的磁盤Inode，但I(xiàn)node的限制并未發(fā)生根本性改善，但是大量使用IF語句能夠?qū)VERLAY2有一定程度優(yōu)化。同時由于OVERLAYFS的兼容性限制，OVERLAYFS僅能實(shí)現(xiàn)POSIX標(biāo)準(zhǔn)的子集，所以，如COPY操作等將違反POSIX標(biāo)準(zhǔn)，目前的解決方法是遷移到Upperdir層進(jìn)行操作。還有關(guān)于系統(tǒng)調(diào)用Rename的問題，因為OVERLAYFS不完全支持此調(diào)用的緣故，暫時無法使用。

3 Docker評測方案設(shè)計

移植過后的1.13版本Docker方案需要一套便捷全面的評測方法來驗證新存儲驅(qū)動和信號機(jī)制的優(yōu)化效果。故設(shè)計了兩個測試方案，設(shè)計方案一對比具體優(yōu)化效果，設(shè)計方案二評測多容器數(shù)量下的穩(wěn)定性。測試方案一，結(jié)合Unixbench工具在龍芯平臺上制作相關(guān)測試鏡像，然后分別對優(yōu)化前后的Docker方案進(jìn)行性能測試以對比優(yōu)化的效果；測試方案二，利用方案一中的測試鏡像，測試容器數(shù)量對系統(tǒng)性能的影響。

3.1 Docker移植優(yōu)化效果評測

首先對Docker方案的移植優(yōu)化效果進(jìn)行評測，因此設(shè)計測試方案一如下。

先分別在搭載Fedora21系統(tǒng)的龍芯單路主機(jī)上制作1.6版本Docker的測試鏡像和搭載Fedora28系統(tǒng)的龍芯單路主機(jī)上制作優(yōu)化后的Docker方案的測試鏡像，鏡像中嵌入Unixbench測試工具，并設(shè)置好相關(guān)參數(shù)以便測試啟動。然后分別在搭載Fedora21系統(tǒng)和Fedora28系統(tǒng)的龍芯單路主機(jī)上利用測試工具進(jìn)行基準(zhǔn)性能測試，確認(rèn)系統(tǒng)環(huán)境的狀態(tài)，各記為F21′和F28′；之后分別在Fedora21系統(tǒng)和Fedora28系統(tǒng)中啟動測試鏡像進(jìn)行性能評測，測試結(jié)果分?jǐn)?shù)分別記為F21和F28。為了減少誤差影響，兩個Docker方案的測試至少重復(fù)執(zhí)行三次，性能數(shù)據(jù)結(jié)果取平均值為最終值，即每個測試項最終的測試數(shù)據(jù)結(jié)果Datai計算如下：

(1)

式中：Datai表示第i項性能測試數(shù)據(jù)的分?jǐn)?shù)；xij表示第i項性能測試項第j次的數(shù)據(jù)結(jié)果。

最終測試數(shù)據(jù)如表2所示。

表2 Docker方案優(yōu)化前后的性能測試數(shù)據(jù)表

續(xù)表2

然后為了驗證優(yōu)化后的Docker方案對系統(tǒng)性能的影響，需要在不同容器的數(shù)量下進(jìn)行測試。測試方案二如下。

記(Containers Numbers)容器編號為N時表示同時運(yùn)行的N個測試容器進(jìn)行測試，對每次測試至少重復(fù)執(zhí)行三次以減少誤差帶來的影響，每項測試結(jié)果取所有數(shù)據(jù)結(jié)果的平均值為最終值，即每次最終的測試分?jǐn)?shù)DataN計算如下：

(2)

式中：uij表示在N個容器同時運(yùn)行情況下第j個容器第i次的測試數(shù)據(jù)。

最終測試數(shù)據(jù)如表3所示。

表3 不同容器數(shù)量下的性能測試數(shù)據(jù)表

3.2 性能測試數(shù)據(jù)分析

首先結(jié)合圖3(a)，能清晰地看見優(yōu)化后的Docker方案整體性能分?jǐn)?shù)F28是960.3，而優(yōu)化前的Docker方案性能分?jǐn)?shù)F21是920.3，綜合性能提高了5%左右。而且各個測試項數(shù)據(jù)來看，容器內(nèi)的系統(tǒng)性能與宿主機(jī)操作系統(tǒng)不相上下，較傳統(tǒng)的虛擬化技術(shù)而言有明顯的優(yōu)勢。

(a) 測試方案總分

(b) 進(jìn)程通信相關(guān)測試分?jǐn)?shù)1

(c) 進(jìn)程通信相關(guān)測試分?jǐn)?shù)2圖3 測試方案總分和進(jìn)程通信相關(guān)測試分?jǐn)?shù)

值得注意的是Pipe-based Context Switching(基于管道的上下文交互)測試，這個測試項測試了兩個進(jìn)程每秒鐘通過一個管道交換一個不斷增長的整數(shù)的次數(shù)。從圖3(b)可以看到1.6版本Docker方案中容器內(nèi)測試分?jǐn)?shù)是374.4，而主機(jī)下的基準(zhǔn)測試值是479.2，容器內(nèi)測試程序運(yùn)行效率約是主機(jī)環(huán)境下的78.13%，而優(yōu)化后的Docker方案中，容器內(nèi)測試分?jǐn)?shù)為703.4，而主機(jī)環(huán)境下測試項分?jǐn)?shù)是778.2，容器內(nèi)測試程序運(yùn)行效率約是主機(jī)環(huán)境下的90.39%，證明了優(yōu)化后的Docker方案在進(jìn)程間通信中的性能損失更少，同時可以看出優(yōu)化后的Docker方案較之前的1.6版本性能提升較為明顯，在進(jìn)程間通信測試項上性能比1.6版本提升了53.0%。

再根據(jù)System Call Overhead測試項分?jǐn)?shù)變化，如圖3(c)所示。這一項測試通過反復(fù)調(diào)用getpid函數(shù)測試了進(jìn)入和離開系統(tǒng)內(nèi)核的代價，即一次系統(tǒng)調(diào)用的代價，測試分?jǐn)?shù)越高說明系統(tǒng)調(diào)用消耗越小?？梢钥闯鰜韮?yōu)化后的Docker方案較1.6版本Docker在系統(tǒng)調(diào)用測試項上性能更為優(yōu)越。1.6版本Docker方案系統(tǒng)調(diào)用代價測試項的分?jǐn)?shù)F21是1 073.2，而優(yōu)化后的Docker方案測試項分?jǐn)?shù)是1 201.5，優(yōu)化后的Docker方案系統(tǒng)調(diào)用消耗測試項是1.6版本的89.32%，在系統(tǒng)調(diào)用的效率上提升了10%左右。

Dhrystone和Whetstone兩項測試是測試處理器運(yùn)算能力的基準(zhǔn)測試程序，可以看到優(yōu)化后的Docker方案依然保證了容器內(nèi)優(yōu)秀的計算性能，CPU計算性能并沒有因為容器虛擬化方案而產(chǎn)生損耗。而且容器中的測試分?jǐn)?shù)抖動更小，各項測試結(jié)果都比主機(jī)環(huán)境下更為穩(wěn)定，由此表明容器的系統(tǒng)運(yùn)行環(huán)境對于測試程序來說穩(wěn)定性更高。

從表3可以發(fā)現(xiàn)，在同時運(yùn)行N個容器的系統(tǒng)環(huán)境下，CPU計算性能測試項分?jǐn)?shù)是線性下降而非曲線下降的，在同時運(yùn)行四個測試容器時測試項分?jǐn)?shù)是753.5，是單容器時測試分?jǐn)?shù)的25.4%，由于單路主機(jī)是四核機(jī)器，所以這是符合預(yù)期的，說明優(yōu)化后的Docker方案穩(wěn)定可靠，不會出現(xiàn)由于資源搶占產(chǎn)生的額外性能損失。結(jié)合Whetstone測試分?jǐn)?shù)的抖動頻率，更能驗證移植優(yōu)化后的Docker方案不會對CPU計算性能產(chǎn)生太大影響。

4 結(jié) 語

本文完成了龍芯Fedora28系統(tǒng)上1.13版本Docker方案的移植，解決了一些平臺差異性問題，并優(yōu)化了Docker方案映射的系統(tǒng)信號機(jī)制，對于鏡像文件應(yīng)用了新的OVERLAY2存儲驅(qū)動，并設(shè)計了評測方案分析移植優(yōu)化的效果。經(jīng)過評測發(fā)現(xiàn)優(yōu)化后的Docker方案在進(jìn)程間通信的相關(guān)測試項中性能比1.6版本提升了53%，并且容器內(nèi)測試程序的性能損耗更小，同時發(fā)現(xiàn)優(yōu)化后的Docker方案系統(tǒng)調(diào)用消耗更小，降低了10%左右，而且優(yōu)化后的Docker更加穩(wěn)定。但是容器技術(shù)深深依賴內(nèi)核特性的特點(diǎn)并未根本性改善，可以預(yù)測在高數(shù)量級下容器集群系統(tǒng)性能會產(chǎn)生很大損失，僅依賴內(nèi)核特性進(jìn)行資源管理是遠(yuǎn)遠(yuǎn)不夠的，所以下一步的研究將集中在MIPS架構(gòu)下的容器集群模式構(gòu)建和相關(guān)負(fù)載均衡策略與調(diào)度算法的設(shè)計上，并結(jié)合龍芯平臺的特殊性進(jìn)一步研究MIPS架構(gòu)下Docker方案的各個模塊的優(yōu)化策略。