董曉明，李小勇，程 煜

0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

3 零拷貝

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

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

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

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

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

3) 當(dāng)文件緩沖區(qū)填滿或者文件關(guān)閉的時候，客戶端程序會將文件緩沖區(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)瓶頸，會嚴(yán)重影響文件系統(tǒng)的寫性能。因此我們在優(yōu)化系統(tǒng)寫性能的時候，引入零拷貝的概念，實現(xiàn)了FUSE到文件緩沖區(qū)的數(shù)據(jù)零拷貝和文件緩沖區(qū)到網(wǎng)絡(luò)模塊的數(shù)據(jù)零拷貝。

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

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

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

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

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

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

4 并行化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 性能測試

5.1 測試環(huán)境

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

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

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

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

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

5.2 測試內(nèi)容

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

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

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

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

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

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

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

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

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

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

5.3 結(jié)果分析

1) 單副本的系統(tǒng)吞吐量比三副本的高。這是因為推送三個副本時，網(wǎng)絡(luò)傳輸和磁盤IO的時間明顯增加。

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

6 小結(jié)

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

[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.