4個關(guān)于fastDFS的大數(shù)據(jù)量下性能的問題

workyixin

大家好，我有4個關(guān)于fastDFS的大數(shù)據(jù)量下性能的問題，希望得到全部or部分的解答，謝謝！

一、fastDFS在大數(shù)據(jù)量(存儲>3億張圖片文件)時，會不會出現(xiàn)性能瓶頸(上傳和http瀏覽)？
        ---我個人猜測不會，但沒有在論壇上找到明確的回答。
                binlog文件中記錄了所有存儲文件的信息，每個binlog文件最大1G。
                不過binlog似乎只是用于組內(nèi)的文件同步復(fù)制，并不用于檢索？
           所以猜測，并發(fā)上傳時，binlog會增加記錄，但在“大數(shù)據(jù)量下”，并不會產(chǎn)生明顯的性能問題？
                     并發(fā)瀏覽時，nginx通過link(或者解析文件名之后)直接轉(zhuǎn)到相應(yīng)文件，沒有binlog或任何文件的檢索，所以也無性能問題？
        ---作者注：               
                測試說明：
                    測試環(huán)境: DFS單臺虛擬服務(wù)器8核CPU,16G內(nèi)存。  大圖平均400K，小圖平均14K。
                    利用合并存儲，通過約40小時的持續(xù)上傳1Byte文件，制造了1億數(shù)據(jù)量。

               測試結(jié)果：
                   上傳速度：           DFS已存儲數(shù)據(jù)量          0                     8000萬          8000萬
                                                               類型          普通上傳         普通上傳        合并存儲上傳
                                 耗時(10萬大圖10萬小圖)              101分鐘         101分鐘         96分鐘
   
                   讀取速度：           DFS已存儲數(shù)據(jù)量          20萬            1億             1億
                                                               類型          普通讀取         普通讀取        合并存儲讀取
                        平均耗時(50并發(fā)，各同時8張小圖)              0.092(秒)           0.092
                      平均耗時(100并發(fā)，各同時8張小圖)              0.175                0.176
                        平均耗時(50并發(fā)，各同時8張大圖)              1.207                1.215              1.219
                      平均耗時(100并發(fā)，各同時8張大圖)              2.313                2.345              2.348
               測試結(jié)論：
                  1、DFS沒有性能瓶頸的問題，上傳和瀏覽時，不用傳統(tǒng)的類似DB檢索的過程，所以速度穩(wěn)定可靠。
                  2、如果開啟合并存儲，上傳和讀取的速度，與普通存儲差不多，可以放心使用。

二、由于上個疑問，現(xiàn)在想制造>1億的海量數(shù)據(jù)，然后進行(上傳和http瀏覽的)性能測試。
    我的做法是利用"合并存儲"功能，持續(xù)上傳最小的1byte的文件。經(jīng)測試，平均3ms可以上傳1個，預(yù)計3.75天可上傳1.08億。
    可是，每次上傳到3966個左右，就會報錯java.net.BindException: Address already in use: connect，等約150秒后才能繼續(xù)上傳。
    我盡量調(diào)整大了max_connections和work_threads設(shè)置，也修改過sysctl.conf配置，可還是不起半點作用，每次上傳到3966個左右仍會報這個錯。
    這個錯誤不解決，我制造1億數(shù)據(jù)，耗費的總時間就得增加10倍。
   
    ---作者注：該問題已解決。
               原因是我之前只優(yōu)化了DFS服務(wù)器的linux相關(guān)參數(shù)，但是上傳代碼是在我的winXP本機執(zhí)行的，connect錯誤發(fā)生在我的電腦上。
               后來把上傳代碼移至另一臺同樣優(yōu)化過的linux服務(wù)器上執(zhí)行，持續(xù)上傳再也沒有中斷。

三、fastDHT會對fastDFS起什么作用？除了"可用于存儲文件別名、可以文件排重"，有沒有別的作用，對于DFS性能有沒有幫助？
   
    ---作者注：如題，DHT對于DFS，應(yīng)該主要是這兩個作用，與DFS性能沒有關(guān)系。

workyixin

四、部署方式和存儲方式
    部署方式：
        作者推薦采用多個storage服務(wù)器(多個group)，各自分別掛載幾個單盤的方式，以期提高總的磁盤IO性能。
        可是，公司硬件資源有限，不能提供那么多的storage服務(wù)器。
        所以當前，文件不是存儲在單盤上，而是只有1個storage服務(wù)器，掛載上數(shù)十T的EMC廠商的存儲設(shè)備。
        這種方式，是不是不太好？
    存儲方式：
        經(jīng)測試，縮略圖如果打算使用合并存儲，就沒法以“從文件模式”上傳(可以指定文件后綴名)了。
        所以當前，沒有開啟合并存儲的功能。
        從文件定位的性能考慮，3億個文件，是不是應(yīng)該用“合并存儲”了?
      
      ---作者注：
           經(jīng)與公司運維人員溝通，專業(yè)的EMC存儲，不同于傳統(tǒng)的RAID0~5等磁盤陣列概念，其性能很優(yōu)，基本不用擔心磁盤IO吞吐量和inode分配的問題。
           所以目前的部署方式和存儲方式，估計是可行的。

                       

ljyy1112

存在同樣的場景，關(guān)注。。。。

workyixin

相關(guān)問題和測試結(jié)論，已經(jīng)在主帖中回復(fù)說明了，歡迎大家補充更多的意見！

另外，測試中，1億數(shù)據(jù)量時，觀察fastDFS的binlog日志文件的情況如下：
    storage/data/sync目錄下，產(chǎn)生了7個binlog.00~文件，共計約7G大小。
    由于采用合并存儲，storage/data/trunk目錄下，還有1個binlog文件，大小15.68G，其中記錄了(可能是)每個trunk文件內(nèi)的詳細信息。

allnew

問一個問題：長時間Java Client卡住，請問從哪里入手排查。 我也正在建立一個億級的測試環(huán)境

FastDFS 的tracker和storage端配置 除了IP和啟用trunk外，均保持默認。V5.x和4.08測試過都有這個問題，

Server：RHEL 6.2 64位，tracker和storage部署在同一臺機器上
Client程序也部署在同一臺機器上，采用Java編寫，調(diào)用 1.24 API的upload(group_name, local_path, extname, meta_list)這個方法, meta_list為null。


方法：一個client進程、幾十個文件循環(huán)反復(fù)進行upload，上傳的文件有100K的、幾十M，都試過。
現(xiàn)象：上傳經(jīng)過大概20分鐘后，upload方法卡住。此時，storage和tracker的日志文件中均無明顯異常。
         但lsof命令可以發(fā)現(xiàn)storage進程正打開一個數(shù)據(jù)文件，該文件就是前正在上傳的文件，但是該文件的大小 低于 原始文件的大小。（為了驗證這種情況，選擇60M以上的文件超過trunk合并的文件大小上限值）

猜測：1.storage申請磁盤空間hang住
        2.storage沒有獲取到正確的上傳文件的大小

還有哪些地方可以檢查的嗎，系統(tǒng)日志、或是其它地方。

========
另有一個問題：如何配置使storage不產(chǎn)生同步用的binlog。

workyixin

allnew:
問題1：上傳過程，應(yīng)該是client讀文件，把文件流通過socket發(fā)送給storage，storage寫文件。
        所以猜測你lsof命令發(fā)現(xiàn)的storage進程可能正在寫文件，是否由于文件尚未傳輸接收完全，因此低于原始大小。
        不太清楚還有哪些地方可以檢查。如果你用本機client上傳，能調(diào)試跟蹤就好了。
問題2：目前，沒有相應(yīng)的配置可以使storage不產(chǎn)生binlog。單機部署的情況下的確用不上binlog，也許可以修改源代碼注釋掉。

myhome1998

回復(fù) 1# workyixin
好信息哦，有機會測試下。


   

allnew

回復(fù) 6# workyixin


    關(guān)于問題1，我看你的程序也是用Java寫的，編寫Client有什么特別需要注意的嗎，我就是參照Java Client API的test代碼進行編寫的。

workyixin

回復(fù) 8# allnew

    java客戶端也沒什么特殊的地方，只需注意最后調(diào)用trackerServer.close()及時關(guān)閉連接，否則服務(wù)端會容易超過max_connections，造成客戶端拋出recv package size -1 != 10或者Connection reset異常，無法再繼續(xù)上傳。
   

allnew

workyixin 發(fā)表于 2014-03-11 10:41
回復(fù) 8# allnew

    java客戶端也沒什么特殊的地方，只需注意最后調(diào)用trackerServer.close()及時關(guān)閉連 ...

謝謝，我回去再試一下