Linux大文件傳輸

我們經常需要在機器之間傳輸文件。比如備份，復制數據等等。這個是很常見，也是很簡單的。用scp或者rsync就能很好的完成任務。但是如果 文件很大，需要占用一些傳輸時間的時候，怎樣又快又好地完成任務就很重要了。在我的測試用例中，一個最佳的方案比最差的方案，性能提高了10倍。

復制文件

如果我們是復制一個未壓縮的文件。這裡走如下步驟：

1. 壓縮數據
2. 發送到另外一台機器上
3. 數據解壓縮
4. 校驗正確性

這樣做會很有效率，數據壓縮後可以更有效的利用帶寬

使用ZIP+SCP

我們可以通過ZIP+SCP的組合實現這個功能。

gzip -c /home/yankay/data | ssh yankay01 "gunzip -c - > /home/yankay/data"

這條命令是將/home/yankay/data經過GZIP壓縮，通過ssh傳輸到yankay01的機器上。

data文件的大小是1.1GB,經過Zip壓縮後是183MB，執行上面的命令需要45.6s。平均吞吐量為24.7MB/s 我們會發現Scp也有壓縮功能，所以上面的語句可以寫成

scp -C -c blowfish /home/yankay/data yankay01:/home/yankay/data

這樣運行效果是相同的，不通之處在於我使用了blowfish算法作為Scp的密匙算法，使用這個算法可以比默認的情況快很多。單單對與scp,使用了blowfish 吞吐量是62MB/s,不使用只有46MB/s。

可是我執行上面一條命令的時候，發現還是需要45s。平均吞吐量還為24MB/s。沒有絲毫的提升，可見瓶頸不在網絡上。 那瓶頸在哪裡呢？

性能分析

我們先定義幾個變量

• 壓縮工具的壓縮比是 CompressRadio
• 壓縮工具的壓縮吞吐是CompressSpeed MB/s
• 網絡傳輸的吞吐是 NetSpeed MB/s

由於使用了管道，管道的性能取決於管道中最慢的部分的性能，所以整體的性能是：

speed=min(NetSpeed/CompressRadio,CompressSpeed)

當壓縮吞吐較網絡傳輸慢的時候，壓縮是瓶頸；但網絡較慢的時候，網絡傳輸/吞吐 是瓶頸。

根據現有的測試數據(純文本)，可以得到表格：

壓縮比 吞吐量 千兆網卡(100MB/s)吞吐量 千兆網卡吞吐量,基於ssh(62MB/s) 百兆網卡(10MB/s)吞吐量 ZLIB 35.80% 9.6 9.6 9.6 9.6 LZO 54.40% 101.7 101.7 101.7 18.38235294 LIBLZF 54.60% 134.3 134.3 113.5531136 18.31501832 QUICKLZ 54.90% 183.4 182.1493625 112.9326047 18.21493625 FASTLZ 56.20% 134.4 134.4 110.3202847 17.79359431 SNAPPY 59.80% 189 167.2240803 103.6789298 16.72240803 NONE 100% 300 100 62 10

可以看出來。在千兆網卡下，使用QuickLZ作為壓縮算法，可以達到最高的性能。如果使用SSH作為數據傳輸通道，則遠遠沒有達到網卡可以達到的最佳性能。在百兆網卡的情況下，各個算法相近。對比下來QuickLZ是有優勢的。

對於不同的數據和不同的機器，可以得出不同的最佳壓縮算法。但有一點是肯定的，盡量把瓶頸壓在網絡上。對於較慢的網絡環境，高壓縮比的算法會比較有優勢；相反對於較快的網絡環境，低壓縮比的算法會更好。

結論

根據上面的分析結果，我們不能是用SSH作為網絡傳輸通道，可以使用NC這個基本網絡工具，提高性能。同時使用qpress作為壓縮算法。

scp /usr/bin/qpress yankay01:/usr/bin/qpress
ssh yankay01 "nc -l 12345 |  qpress -dio > /home/yankay/data" &
qpress -o /home/yankay/data |nc yankay01 12345

第一行是將gpress安裝到遠程機器上，第二行在遠程機器上使用nc監聽一個端口，第三行壓縮並傳送數據。

執行上面的命令需要2.8s。平均吞吐量為402MB/s,比使用Gzip+Scp快了16倍！！

根據上文的公式，和自己的數據，可以繪出上面的表格，就可以選擇出最適合的壓縮算法和傳輸方式。達到滿意的效果。如果是一個長期運行的腳本的話，這麼做是值得的。