董曉明，李小勇，程 煜

0 引言

如今，人類已經(jīng)邁入云時(shí)代，信息總量正以幾何級(jí)數(shù)的方式迅速增長(zhǎng)，基于對(duì)象存儲(chǔ)技術(shù)的大規(guī)模分布式存儲(chǔ)系統(tǒng)由于其在容量和可擴(kuò)展性等方面的優(yōu)勢(shì)，逐漸替代了以NFS為代表的傳統(tǒng)存儲(chǔ)方案，越來越受到企業(yè)界、學(xué)術(shù)界的青睞。在近十年內(nèi)，大量新型的分布式文件系統(tǒng)被研制開發(fā)出來，比如 GFS[1]，HDFS[2]，KFS[3]，GlusterFS[4]等等，它們?cè)诖鎯?chǔ)領(lǐng)域都有著廣泛的應(yīng)用，不過讓人遺憾的是，這些分布式文件系統(tǒng)雖然有著很大的容量，很好的可擴(kuò)展性，但是它們的讀寫性能卻遠(yuǎn)遠(yuǎn)沒有達(dá)到網(wǎng)絡(luò)上限。而且，隨著計(jì)算技術(shù)的迅猛發(fā)展，應(yīng)用程序?qū)τ脩粑募拇嫒∧芰σ灿兄絹碓絿?yán)格的要求。因此，提高分布式文件系統(tǒng)的讀寫性能不僅有學(xué)術(shù)意義，還有其實(shí)踐意義。

常用的分布式文件系統(tǒng)的優(yōu)化寫性能的方法主要是寫合并。寫合并是將應(yīng)用程序要寫的數(shù)據(jù)先緩存到文件系統(tǒng)客戶端的緩沖區(qū)中，等到緩沖區(qū)的數(shù)據(jù)堆積到一定數(shù)量后再將數(shù)據(jù)發(fā)送到服務(wù)器端。這種方法確實(shí)有助于提高文件系統(tǒng)的寫性能，我們的BlueOcean分布式文件系統(tǒng)也采用了這種方法，但是這種方法對(duì)寫性能的提升有限，遠(yuǎn)遠(yuǎn)沒有達(dá)到應(yīng)用程序?qū)懶阅艿囊螅晕覀儽仨殢钠渌姆矫鎭韺?duì)BlueOcean分布式文件系統(tǒng)的寫性能進(jìn)行優(yōu)化。本文以我們?cè)O(shè)計(jì)實(shí)現(xiàn)的BlueOcean大規(guī)模分布式文件系統(tǒng)為基礎(chǔ)，對(duì)其寫性能進(jìn)行了三個(gè)方面的優(yōu)化。

文章的剩余部分組織如下：第 2節(jié)介紹了 BlueOcean分布式文件系統(tǒng)的整體架構(gòu)；第3節(jié)介紹了FUSE部分的寫性能優(yōu)化；第4節(jié)介紹了零拷貝；第5節(jié)介紹了應(yīng)用程序?qū)懣蛻舳宋募彌_區(qū)與客戶端寫數(shù)據(jù)服務(wù)器的并行化；第 6節(jié)列出了寫性能優(yōu)化前后的實(shí)驗(yàn)數(shù)據(jù)；第7節(jié)對(duì)本文工作進(jìn)行了簡(jiǎn)要的總結(jié)。

1 BlueOcean系統(tǒng)架構(gòu)

BlueOcean是我們實(shí)驗(yàn)室設(shè)計(jì)開發(fā)的基于對(duì)象存儲(chǔ)的大規(guī)模分布式存儲(chǔ)系統(tǒng)，其架構(gòu)類似于GFS、HDFS和KFS，它由一個(gè)元數(shù)據(jù)結(jié)點(diǎn)，一個(gè)備份結(jié)點(diǎn)（可選），多個(gè)數(shù)據(jù)結(jié)點(diǎn)和若干個(gè)客戶端組成。其中元數(shù)據(jù)結(jié)點(diǎn)主要用于管理文件元數(shù)據(jù)信息，并負(fù)責(zé)負(fù)載均衡和租約管理等；備份結(jié)點(diǎn)用于在元數(shù)據(jù)結(jié)點(diǎn)停止服務(wù)（比如掉電，或網(wǎng)絡(luò)不通等）后，接管元數(shù)據(jù)結(jié)點(diǎn)的功能，保證元數(shù)據(jù)結(jié)點(diǎn)功能的可靠性；數(shù)據(jù)結(jié)點(diǎn)負(fù)責(zé)保存數(shù)據(jù)，并以線程池的方式高并發(fā)的處理來自客戶端的IO請(qǐng)求；我們使用FUSE在用戶態(tài)開發(fā)客戶端文件系統(tǒng)，客戶端采用了單線程異步的框架，與元數(shù)據(jù)結(jié)點(diǎn)進(jìn)行元數(shù)據(jù)交互，與數(shù)據(jù)結(jié)點(diǎn)進(jìn)行數(shù)據(jù)交互。

在我們開發(fā)的 BlueOcean分布式文件系統(tǒng)中，用戶存儲(chǔ)的文件被分割成多個(gè)固定大小的 chunk存儲(chǔ)在數(shù)據(jù)結(jié)點(diǎn)上，用戶可以根據(jù)具體應(yīng)用為每個(gè)chunk設(shè)置一份或者多份副本，以提高系統(tǒng)的可靠性，保證系統(tǒng)的可用性。

BlueOcean存儲(chǔ)系統(tǒng)的架構(gòu)圖，如圖1所示：

圖1 系統(tǒng)的架構(gòu)圖

2 FUSE部分的寫性能優(yōu)化

使用FUSE在用戶態(tài)開發(fā)客戶端文件系統(tǒng)是現(xiàn)有的分布式存儲(chǔ)系統(tǒng)客戶端的常用的實(shí)現(xiàn)方案，例如 GlusterFS。該方法實(shí)現(xiàn)起來比較簡(jiǎn)單，而且FUSE還提供了POSIX語(yǔ)義的接口，通用性強(qiáng)，更由于其在用戶態(tài)運(yùn)行，這就保證了客戶端程序的安全性和穩(wěn)定性。BlueOcean分布式文件系統(tǒng)的客戶端也是使用FUSE開發(fā)的，但是，使用FUSE帶來的負(fù)面影響就是會(huì)比較嚴(yán)重的影響文件系統(tǒng)的寫性能。

在對(duì)FUSE部分的寫性能進(jìn)行優(yōu)化之前，我們首先來介紹兩個(gè)比較重要的概念，模式切換和上下文切換。眾所周知，大多數(shù)的進(jìn)程都至少支持兩種執(zhí)行模式：內(nèi)核模式和用戶模式，模式切換就是進(jìn)程由一種模式切換到另外一種模式，通常情況下，模式切換的代價(jià)是比較小的。上下文切換就是將CPU的控制權(quán)由一個(gè)進(jìn)程轉(zhuǎn)移到另外一個(gè)進(jìn)程，不僅需要保存住當(dāng)前進(jìn)程的運(yùn)行狀態(tài)，并且還要恢復(fù)將要執(zhí)行的進(jìn)程的狀態(tài)。一次上下文切換的代價(jià)是來自很多方面的，CPU寄存器需要被保存和重新載入，TLB表項(xiàng)需要被重新載入，CPU上的流水線也需要被刷掉。雖然影響上下文切換的因素有很多，比如CPU性能，負(fù)載情況以及進(jìn)程的內(nèi)存訪問模式等等，但是顯而易見，與模式切換相比，上下文切換的代價(jià)是相當(dāng)巨大的。

在應(yīng)用程序使用本地文件系統(tǒng)（例如EXT3或者EXT4）的時(shí)候，每個(gè)文件系統(tǒng)的操作都會(huì)產(chǎn)生兩次內(nèi)核態(tài)/用戶態(tài)的模式切換（應(yīng)用程序進(jìn)程會(huì)先從非特權(quán)的用戶態(tài)切換到特權(quán)的內(nèi)核態(tài)，然后再?gòu)奶貦?quán)的內(nèi)核態(tài)切換到非特權(quán)的用戶態(tài)），并不會(huì)產(chǎn)生上下文切換。而在使用FUSE的時(shí)候，每一個(gè)FUSE請(qǐng)求不僅會(huì)有上面的兩次模式切換，還引入了兩次上下文切換（從用戶態(tài)的應(yīng)用程序進(jìn)程切換到用戶態(tài)的libfuse進(jìn)程，再?gòu)挠脩魬B(tài)的 libfuse進(jìn)程切換到用戶態(tài)的應(yīng)用程序進(jìn)程），所以執(zhí)行一次FUSE寫請(qǐng)求是要耗費(fèi)很大代價(jià)的。

BlueOcean客戶端在執(zhí)行文件系統(tǒng)寫操作的時(shí)候，是將寫操作先組織成4K大小的FUSE寫請(qǐng)求[5]，然后再傳遞給libfuse進(jìn)程進(jìn)行處理的。這就產(chǎn)生了一個(gè)問題，如果應(yīng)用程序?qū)懖僮鞯臄?shù)據(jù)塊的大小超過了4K，那么FUSE是如何處理的呢？目前看來，F(xiàn)USE在處理數(shù)據(jù)塊大小超過4K的寫操作時(shí)，是將寫操作分割成多個(gè)4K大小的FUSE寫請(qǐng)求，然后將這些FUSE寫請(qǐng)求串行的傳遞給libfuse進(jìn)程進(jìn)行處理。很明顯，這種處理方式有著其顯著的缺點(diǎn)，就是它可能會(huì)將原本一次 FUSE寫請(qǐng)求就可以執(zhí)行完的操作分割成了多個(gè)FUSE寫請(qǐng)求，產(chǎn)生了額外的上下文切換，嚴(yán)重影響文件系統(tǒng)的寫性能。

通過研究我們發(fā)現(xiàn)，大多數(shù)的應(yīng)用，包括linux的cp,tar等命令，它們使用的數(shù)據(jù)塊的大小都是大于4K而小于128K的，如果繼續(xù)保持4K大小的FUSE請(qǐng)求是沒有任何意義的，而且還會(huì)產(chǎn)生性能上的問題。所以我們將FUSE寫請(qǐng)求的大小由原來的 4K增加到128K，這樣做將上下文切換的次數(shù)降低到了原來的 1/32，避免了原來大量的無(wú)謂的上下文切換，使得BlueOcean文件系統(tǒng)的寫性能有著顯著的提高。

3 零拷貝

在大多數(shù)的分布式文件系統(tǒng)中，為了提高寫性能，大都會(huì)將要寫的數(shù)據(jù)先存放到客戶端的緩沖區(qū)中，等到數(shù)據(jù)積攢到了一定的數(shù)量后，再集中將數(shù)據(jù)發(fā)送出去。這樣做可以有效地降低客戶端與數(shù)據(jù)服務(wù)器的交互次數(shù)，提升系統(tǒng)的寫性能。BlueOcean分布式文件系統(tǒng)在客戶端也采用了這種優(yōu)化方式，但是在實(shí)現(xiàn)這種優(yōu)化的時(shí)候卻多引入了兩次內(nèi)存拷貝。

在 BlueOcean分布式文件系統(tǒng)中，客戶端寫操作數(shù)據(jù)的大致走向，如圖2所示：

圖2 客戶端數(shù)據(jù)的走向

1) 應(yīng)用程序要寫的數(shù)據(jù)會(huì)被分割成128K大小的塊拷貝到FUSE的緩沖區(qū)進(jìn)行處理。

2) FUSE在接收到應(yīng)用程序發(fā)送來的數(shù)據(jù)后，會(huì)再將這些數(shù)據(jù)拷貝到 BlueOcean文件系統(tǒng)客戶端的文件緩沖區(qū)中。

3) 當(dāng)文件緩沖區(qū)填滿或者文件關(guān)閉的時(shí)候，客戶端程序會(huì)將文件緩沖區(qū)內(nèi)的數(shù)據(jù)再拷貝給客戶端的網(wǎng)絡(luò)模塊，并由網(wǎng)絡(luò)模塊將這些數(shù)據(jù)通過網(wǎng)絡(luò)接口發(fā)送出去。

眾所周知，內(nèi)存拷貝屬于 CPU密集型操作，在 CPU性能不高，系統(tǒng)高負(fù)載等情況下，很容易成為系統(tǒng)瓶頸，會(huì)嚴(yán)重影響文件系統(tǒng)的寫性能。因此我們?cè)趦?yōu)化系統(tǒng)寫性能的時(shí)候，引入零拷貝的概念，實(shí)現(xiàn)了FUSE到文件緩沖區(qū)的數(shù)據(jù)零拷貝和文件緩沖區(qū)到網(wǎng)絡(luò)模塊的數(shù)據(jù)零拷貝。

為了實(shí)現(xiàn)零拷貝，我們對(duì)char類型的數(shù)據(jù)塊進(jìn)行了封裝。使得數(shù)據(jù)在由FUSE傳遞到文件緩沖區(qū)和由文件緩沖區(qū)傳遞到網(wǎng)絡(luò)模塊的傳遞過程中，并不執(zhí)行數(shù)據(jù)的實(shí)際拷貝，而只是執(zhí)行 char*指針的傳遞。如果文件緩沖區(qū)的大小設(shè)置為4M，那么兩次數(shù)據(jù)拷貝會(huì)引入8M的數(shù)據(jù)拷貝量；而char*類型的指針只占 4到 8個(gè)字節(jié)，兩次指針拷貝只會(huì)引入 8到16字節(jié)的數(shù)據(jù)拷貝量。很顯然，指針拷貝的寫性能會(huì)遠(yuǎn)遠(yuǎn)高于數(shù)據(jù)拷貝的寫性能。

實(shí)現(xiàn)了零拷貝的后，客戶端的寫操作數(shù)據(jù)的大致走向，如圖3所示：

圖3 實(shí)現(xiàn)零拷貝后，客戶端數(shù)據(jù)的走向

1) 應(yīng)用程序要寫的數(shù)據(jù)會(huì)被分割成128K大小的塊拷貝到FUSE的緩沖區(qū)進(jìn)行處理。

2) FUSE在接收到用戶應(yīng)用程序發(fā)送來的數(shù)據(jù)后，再將這些數(shù)據(jù)以零拷貝的方式傳遞到 BlueOcean客戶端的文件緩沖區(qū)中。

3) 當(dāng)文件緩沖區(qū)填滿或者文件關(guān)閉的時(shí)候，客戶端程序會(huì)將文件緩沖區(qū)內(nèi)的數(shù)據(jù)再以零拷貝的方式傳遞給客戶端的網(wǎng)絡(luò)模塊，并由網(wǎng)絡(luò)模塊將這些數(shù)據(jù)通過網(wǎng)絡(luò)接口發(fā)送出去。

4 并行化

我們對(duì)BlueOcean文件系統(tǒng)的順序?qū)懥鞒踢M(jìn)行了分析，發(fā)現(xiàn)順序?qū)懙恼麄€(gè)過程可以大致分為如下三個(gè)時(shí)間消耗階段。

第一階段是客戶端將應(yīng)用程序發(fā)送來的數(shù)據(jù)寫到客戶端的文件緩沖區(qū)里，我們稱這個(gè)階段為寫緩沖區(qū)階段。BlueOcean文件系統(tǒng)將客戶端的文件緩沖區(qū)設(shè)置為 8M 大小，而在第3節(jié)中提到過，我們已經(jīng)將FUSE的寫請(qǐng)求大小設(shè)置為128K，所以FUSE是需要至少發(fā)送64次FUSE寫請(qǐng)求才能將客戶端的文件緩沖區(qū)填滿。這個(gè)階段由于要進(jìn)行大量的數(shù)據(jù)拷貝，模式切換以及上下文切換，因此整個(gè)過程是相當(dāng)耗時(shí)的。

第二階段是客戶端將文件緩沖區(qū)內(nèi)的數(shù)據(jù)通過TCP/IP協(xié)議以寫請(qǐng)求的方式發(fā)送給 BlueOcean分布式文件系統(tǒng)的數(shù)據(jù)服務(wù)器，我們稱這個(gè)階段為網(wǎng)絡(luò)傳輸階段。在BlueOcean分布式文件系統(tǒng)中，向數(shù)據(jù)服務(wù)器發(fā)送寫請(qǐng)求只是將要發(fā)送的數(shù)據(jù)推送到數(shù)據(jù)服務(wù)器，客戶端并不需要等待接收來自數(shù)據(jù)服務(wù)器的對(duì)于寫請(qǐng)求的應(yīng)答，所以發(fā)送寫請(qǐng)求的時(shí)間實(shí)際上就是網(wǎng)絡(luò)推送寫請(qǐng)求的時(shí)間。由于數(shù)據(jù)服務(wù)器在接收到來自客戶端的寫請(qǐng)求后，會(huì)立刻進(jìn)行磁盤調(diào)度，將接收到的數(shù)據(jù)寫磁盤，所以客戶端發(fā)送的寫請(qǐng)求的數(shù)據(jù)量越小，開始進(jìn)行磁盤調(diào)度的時(shí)間就越早。因此，BlueOcean客戶端會(huì)限制發(fā)送給數(shù)據(jù)服務(wù)器的寫請(qǐng)求的大小（可以為 128K或者256K），那么客戶端文件緩沖區(qū)內(nèi)的數(shù)據(jù)會(huì)被分割成多個(gè)寫請(qǐng)求發(fā)送給數(shù)據(jù)服務(wù)器。這樣做實(shí)際上是以流水線的方式實(shí)現(xiàn)了網(wǎng)絡(luò)傳輸與磁盤IO的并行化。客戶端文件緩沖區(qū)內(nèi)8M的數(shù)據(jù)會(huì)被分成64個(gè)或者32個(gè)寫請(qǐng)求，順序發(fā)送給數(shù)據(jù)服務(wù)器。

第三階段是客戶端向數(shù)據(jù)服務(wù)器發(fā)送同步寫請(qǐng)求后，等待接收數(shù)據(jù)服務(wù)器返回寫同步請(qǐng)求應(yīng)答的階段，我們稱這個(gè)階段為同步寫階段。在第二階段的寫請(qǐng)求全部發(fā)送完以后，客戶端會(huì)立即向數(shù)據(jù)服務(wù)器發(fā)送一個(gè)包含所有寫請(qǐng)求的校驗(yàn)和的同步寫請(qǐng)求，只有數(shù)據(jù)服務(wù)器將接收到的所有寫請(qǐng)求的數(shù)據(jù)全部寫到磁盤以后，才會(huì)向客戶端返回一個(gè)同步寫請(qǐng)求的應(yīng)答，這意味著客戶端文件緩沖區(qū)內(nèi)的數(shù)據(jù)已經(jīng)寫成功了，可以接收來自應(yīng)用程序的寫數(shù)據(jù)了。這個(gè)過程主要依賴數(shù)據(jù)服務(wù)器端磁盤IO的性能，磁盤IO越高，這個(gè)階段所花費(fèi)的時(shí)間就越短。

上述3個(gè)階段的數(shù)據(jù)交互流程大致，如圖4所示：

圖4 寫數(shù)據(jù)交互流程

分析上圖不難發(fā)現(xiàn)，寫緩沖區(qū)階段和網(wǎng)絡(luò)傳輸階段以及同步寫階段是串行執(zhí)行的，這就說明整個(gè)順序?qū)懥鞒淌怯行阅芴嵘目臻g的，通過將整個(gè)串行流程改成并行流程可以實(shí)現(xiàn)延遲隱藏，達(dá)到提高文件系統(tǒng)寫性能的目的。實(shí)際上，通過上圖還可以發(fā)現(xiàn)，網(wǎng)絡(luò)傳輸階段與寫同步階段合并在一起就是網(wǎng)絡(luò)傳輸與磁盤IO實(shí)現(xiàn)兩階段流水線以后的整個(gè)流水線階段，所以我們將網(wǎng)絡(luò)傳輸階段與同步寫階段統(tǒng)稱為寫服務(wù)器階段。

一種簡(jiǎn)單的并行化的實(shí)現(xiàn)方案是將寫緩沖區(qū)階段與寫服務(wù)器階段做一個(gè)兩階段的流水線處理，實(shí)現(xiàn)寫緩沖區(qū)與寫服務(wù)器的并行化。眾所周知，實(shí)現(xiàn)階段間的流水化，就必須獨(dú)立這些階段。所以為了獨(dú)立寫緩沖區(qū)階段與寫服務(wù)器階段，客戶端必須為每一個(gè)文件多申請(qǐng)一個(gè)文件緩沖區(qū)，這樣當(dāng)一個(gè)緩沖區(qū)用于向數(shù)據(jù)服務(wù)器發(fā)送數(shù)據(jù)的時(shí)候，另一個(gè)緩沖區(qū)可以接收來自應(yīng)用程序的數(shù)據(jù)。

實(shí)現(xiàn)了寫緩沖區(qū)與寫數(shù)據(jù)服務(wù)器并行化的寫數(shù)據(jù)交互流程，如圖5所示：

圖5 兩階段流水的寫數(shù)據(jù)交互流程

很顯然，這種實(shí)現(xiàn)方案會(huì)消耗大量的內(nèi)存，使得客戶端的文件打開數(shù)量的上限減少為原來的一半。如果客戶端的內(nèi)存大小為2G，文件緩沖區(qū)的大小為8M，那么優(yōu)化之前，客戶端文件打開數(shù)量的上限為256個(gè)；而以這種方案優(yōu)化之后，客戶端的文件打開數(shù)量就變成了128個(gè)，這是很不合理的。所以我們否定了這種方案，并且提出了一種既可以提高順序?qū)懙男阅埽植划a(chǎn)生額外的內(nèi)存消耗的方案。

我們知道，BlueOcean分布式文件系統(tǒng)已經(jīng)將網(wǎng)絡(luò)傳輸與磁盤 IO進(jìn)行了流水線處理，實(shí)現(xiàn)了網(wǎng)絡(luò)傳輸與磁盤 IO的并行化，而我們提出的這種優(yōu)化方案就是將寫緩沖區(qū)階段也納入到網(wǎng)絡(luò)傳輸與磁盤IO的流水線中，實(shí)現(xiàn)寫文件緩沖區(qū)，網(wǎng)絡(luò)傳輸與磁盤IO這三個(gè)階段的并行處理。

在我們的優(yōu)化方案中，一個(gè)文件仍然只有一個(gè)文件緩沖區(qū)，大小仍然為8M，但是客戶端程序并不是要等到文件緩沖區(qū)寫滿以后才向數(shù)據(jù)服務(wù)器發(fā)送寫請(qǐng)求，而是只要文件緩沖區(qū)內(nèi)尚未發(fā)送的數(shù)據(jù)量達(dá)到 128K，我們就會(huì)先把這128K的數(shù)據(jù)以寫請(qǐng)求的方式發(fā)送給數(shù)據(jù)服務(wù)器。

我們?yōu)榭蛻舳说奈募彌_區(qū)關(guān)聯(lián)了一個(gè)計(jì)數(shù)器，該計(jì)數(shù)器記錄了緩沖區(qū)當(dāng)前已發(fā)送的數(shù)據(jù)的數(shù)量（我們用 Q表示）。在每次應(yīng)用程序?qū)懲昃彌_區(qū)以后，客戶端程序都會(huì)更新緩沖區(qū)的數(shù)據(jù)總量（我們用T表示），并且計(jì)算出緩沖內(nèi)尚未發(fā)送的數(shù)據(jù)量（Q-T），設(shè)（Q-T）/（128K）= N，如果N大于0，就說明客戶端緩沖區(qū)內(nèi)尚未發(fā)送的數(shù)據(jù)量已經(jīng)達(dá)到128K，就會(huì)向數(shù)據(jù)服務(wù)器發(fā)送N個(gè)寫請(qǐng)求，并且更新Q= Q+N*128K；如果N等于0,則說明客戶端緩沖區(qū)內(nèi)尚未發(fā)送出去的數(shù)據(jù)還沒有128K，就直接返回，并不向數(shù)據(jù)服務(wù)器發(fā)送寫請(qǐng)求。只有當(dāng)緩沖區(qū)當(dāng)前已發(fā)送的數(shù)據(jù)總量（Q）等于 8M（即 Q=T=8M），或者文件被關(guān)閉了，才會(huì)向數(shù)據(jù)服務(wù)器發(fā)送一個(gè)寫同步請(qǐng)求，同步那些已經(jīng)發(fā)送給數(shù)據(jù)服務(wù)器的寫請(qǐng)求。該方案的大致交互流程，如圖6所示：

圖6 三階段流水的寫數(shù)據(jù)交互流程

比較圖6和圖4不難發(fā)現(xiàn)，我們的優(yōu)化方案將原來只實(shí)現(xiàn)了網(wǎng)絡(luò)傳輸與磁盤IO的兩階段流水線優(yōu)化成了應(yīng)用程序?qū)懣蛻舳宋募彌_區(qū)、網(wǎng)絡(luò)傳輸以及磁盤IO的三階段流水線，大大降低了客戶端向數(shù)據(jù)服務(wù)器寫8M數(shù)據(jù)所需要的總的時(shí)間延遲，實(shí)現(xiàn)了寫緩沖區(qū)、網(wǎng)絡(luò)傳輸與磁盤IO三個(gè)階段的完全并行化，顯著地提高了分布式文件系統(tǒng)的寫性能。

5 性能測(cè)試

5.1 測(cè)試環(huán)境

本次性能測(cè)試，使用了 5臺(tái)高性能服務(wù)器，一臺(tái)作為元數(shù)據(jù)結(jié)點(diǎn)，一臺(tái)作為客戶端，另外三臺(tái)作為數(shù)據(jù)結(jié)點(diǎn)。所有的服務(wù)器都通過一臺(tái)千兆交換機(jī)相連。所有的服務(wù)器都采用了雙網(wǎng)卡綁定技術(shù)，每個(gè)服務(wù)器的兩個(gè)網(wǎng)卡被設(shè)置成load-balance模式。

元數(shù)據(jù)結(jié)點(diǎn)的配置信息，如表1所示：

表1 元數(shù)據(jù)結(jié)點(diǎn)配置信息

數(shù)據(jù)結(jié)點(diǎn)和客戶端的配置信息，如表2所示：

表2 數(shù)據(jù)結(jié)點(diǎn)和客戶端的配置信息

5.2 測(cè)試內(nèi)容

測(cè)試1：使用iozone測(cè)試工具，在chunk副本數(shù)為3的前提下，對(duì)優(yōu)化前后的文件系統(tǒng)的寫性能做測(cè)試對(duì)比。

測(cè)試集：文件大小為8G，chunk副本數(shù)為3，iozone塊大小為16K，32K，64K，128K，256K，512K，1024K。

測(cè)試結(jié)果，如圖7所示：

圖7 三副本下，優(yōu)化前后的系統(tǒng)吞吐量

測(cè)試2：使用iozone測(cè)試工具，在chunk副本數(shù)為1的前提下，對(duì)優(yōu)化前后的文件系統(tǒng)的寫性能做測(cè)試對(duì)比。

測(cè)試集：文件大小為8G，chunk副本數(shù)為1，iozone塊大小為16K，32K，64K，128K，256K，512K，1024K。

測(cè)試結(jié)果，如圖8所示：

圖8 單副本下，優(yōu)化前后的系統(tǒng)吞吐量

測(cè)試3：使用linux的top命令，對(duì)優(yōu)化前后的客戶端程序的內(nèi)存使用量做測(cè)試對(duì)比，內(nèi)存使用量，如圖9所示：

圖9 優(yōu)化前后客戶端程序的內(nèi)存使用量

5.3 結(jié)果分析

1) 單副本的系統(tǒng)吞吐量比三副本的高。這是因?yàn)橥扑腿齻€(gè)副本時(shí)，網(wǎng)絡(luò)傳輸和磁盤IO的時(shí)間明顯增加。

2) 雖然，僅采用零拷貝對(duì)系統(tǒng)吞吐量的提升并不是特別大，但是它降低了在執(zhí)行寫操作時(shí)客戶端的內(nèi)存使用量，降低了系統(tǒng)高負(fù)載時(shí)對(duì)寫性能的影響。

6 小結(jié)

本文對(duì) BlueOcean分布式文件系統(tǒng)的寫交互流程進(jìn)行了詳細(xì)的分析，指出了影響B(tài)lueOcean文件系統(tǒng)寫性能的關(guān)鍵因素，并從3個(gè)方面對(duì)寫性能進(jìn)行了優(yōu)化。最后通過對(duì)優(yōu)化前后的寫性能的對(duì)比測(cè)試，證明了優(yōu)化后的文件系統(tǒng)的寫性能確實(shí)大大提高了。

[1]Sanjay Ghemawat, Howard Gobioff and Shun-Tak Leung.The Google File System[C]. Proceedings of the 19thACM Symposium on Operating Systems Principles. Lake George, NY , October, 2003.

[2]Konstantin Shvachko, Hairong Kuang and sanjay Radia.The Hadoop Distributed File System[C]. Proceedings of 26thIEEE International Sysposium on Mass Storage System and Technologies (MSST’10). pages 1-10,2010.

[3]Kosmos. http://kosmosfs.sourceforge.net.

[4]Gluster. http://www.gluster.org.

[5]Aditya Rajgarhia, Ashish Gehani.Performance and extension of user space file systems[C]. Proceedings of the 2010 ACM Symposium on Applied Computing. New York, 2010, 206-213.