tar+lz4/pigz+ssh更快的資料轉送

1. 結論

使用tar+lz4+ssh的方式能夠獲得最大的傳輸效能：

代碼如下	複製代碼
time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128  -o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu" 3.91GiB 0:00:16 [ 249MiB/s] real 0m16.067s user 0m15.553s sys 0m16.821s249MB/s，

妥妥的。是最原始scp(40MB/s)的6倍，原來400GB傳輸需要約3小時，現在只需要27分鐘了。

注1：lz4在解壓方面的優異表現，使得他在本案例中非常重要。如果無需解壓的傳輸，則可以考慮使用pigz/pbiz2

注2：使用pv觀察，網路流量約80MB，所以使用nc替換ssh並不會有明顯的效能提升

注3：lz4壓縮使用-B4(64KB塊大小)，解壓使用-B7(4MB塊大小)，是本案例的測試最優值
2. 關於lz4
lz4是一個讓"人見人愛、花見花開"的壓縮演算法，能夠在多核上很好的擴充，壓縮速度和壓縮比並沒有太大優勢(pigz)，但是他的解壓速度非常驚人，本案例測試lz4的解壓是gunzip的3倍(更多的對比測試)。因為壓縮時高效的多核利用，再加上驚豔的解壓，lz4已經在非常多重要場合使用了：Linux3.11核心實現了LZ4，並可以使用其壓縮和解壓kernel image HBase:Add an LZ4 compression option to HFile等等(參考)。

對於需要頻繁壓縮、即時快速解壓的情境來說，lz4非常適合。

3. 效能環境說明

這裡使用同上一篇文章相同的兩台主機環境：ping獲得RTT是17ms；使用iperf測試頻寬是115MB(參考附錄)；

整個過程有幾個階段：磁碟讀取-->打包(tar)-->壓縮-->傳輸-->解壓縮-->拆包-->落盤 對應了的速度測試：

3.1 磁碟讀取和落盤
磁碟讀取(有page cache)，能到3GB/s；磁碟寫入約428MB：

代碼如下	複製代碼
# dd if=./sendlog.tar of=/dev/null bs=4096 count=1048576 1024002+1 records in 1024002+1 records out 4194314240 bytes (4.2 GB) copied, 1.33946 s, 3.1 GB/s # dd if=/dev/zero of=./x.zero.file bs=4096 count=1048576 1048576+0 records in 1048576+0 records out 4294967296 bytes (4.3 GB) copied, 10.0306 s, 428 MB/s3.2

打包、拆包
打包和拆包速度都大於350MB/s：

代碼如下	複製代碼
# time tar -cf sendlog.tar ./sendlog/ real 0m10.996s # time tar -xf sendlog.tar real 0m11.564s3.3

壓縮、解壓縮
關於各個壓縮公用程式的效能(壓縮、解壓、壓縮率)已經有很多人做了比較，本文不做詳細討論，這裡選擇gzip/pigz lz4 bzip做本測試的比較：

代碼如下	複製代碼
| input speed | output speed | rate   | speed of decoder pigz -p 16 | 327.0MB/s   | 57.2MB/s     | 17.5%  | 95  MB/s lz4        | 288.0MB/s   | 79.2MB/s     | 27.5%  | 264 MB/s bzip2      |   4.9MB/s   | 0.65MB/s     | 13.1%  | 25.6MB /s壓縮公用程式的比較測試參考：Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO

可以看到，lz4在壓縮率上略微遜色(對比pigz)，但是在解壓速度上有這驚人的優勢。

3.4 傳輸

前文介紹了scp，約90MB最快的傳輸速度。

3.5 整體流程

代碼如下	複製代碼
磁碟讀取---->打包---->壓縮------>傳輸---->解壓縮-->拆包---->落盤              |->tar   |->gzip    |->ssh   |->gzip  |->tar                       |->bzip2   |->http  |->bzip                       |-> ...    |->nc    |->...                       |->lz4              |->lz4 >400MB/s    >350MB/s  79MB/s     90MB/s   72MB/s    >350MB/s >400MB/s

這裡可以看到，解壓是最大的瓶頸，使用在解壓方面最有優勢的壓縮公用程式，能讓傳輸獲得最大速度。而lz4正是在解壓效率方面有著巨大的優勢。

按照上面lz4的測試，傳輸速度理論值為264MB/s(此時傳輸速度為264*27.3%=72MB)，這也是本次測試的理論上限速度。

4. 實驗測試
使用lz4壓縮傳輸：

代碼如下	複製代碼
# time tar -c sendlog/|lz4|ssh -c arcfour128  -o"MACs umac-64@openssh.com" 10.xxx.xx.36 "lz4 -d |tar -xC /u01/backup_supu" real 0m25.646s real 0m25.911s real 0m29.019s

測試三次，分別耗時26s、29s、25.6s，傳輸的平均速度為：152MB/s，網路頻寬佔用約41.9MB/s。

使用pigz的壓縮傳輸：

代碼如下	複製代碼
# time tar -c sendlog/|pigz -p 16|ssh -c arcfour128  -o"MACs umac-64@openssh.com" 10.xxx.xx.36 "gzip -d|tar -xC /u01/backup_supu" rreal 0m37.030s real 0m25.911s real 0m29.019s

測試三次，分別耗時37s、37.2s、35.6s，傳輸的平均速度為：110.7MB/s，網路頻寬佔用約19.4MB/s。

對比發現，在壓縮方面pigz與lz4並沒有太大區別，但是lz4解壓速度非常快，所以在這種需要立刻解壓的情境下，lz4輕鬆勝出(bzip2這種就不需要測試了)。

4.1 分析
按照第二節中的理論分析，傳輸速度應該能到260MB，但是上面只有152MB/s，這說明，還有調優的空間。繼續分析，看看瓶頸在哪兒：

使用pv工具觀察到，tar+lz4有約70MB/s的輸出：

 time tar -c sendlog/|lz4|pv > /dev/null
1.02GiB 0:00:14 [70.8MiB/s] [                                 <=>]比直接lz4輸出，要慢了10%左右(lz約79MB/s)。

再加上一次網路ssh：

time tar -c sendlog/|lz4|pv|ssh -c arcfour128 -o "MACs umac-64@openssh.com" 10.xxx.xxx.36 "cat - >/dev/null"
1.02GiB 0:00:23 [43.9MiB/s] [                                 <=>]

比直接lz4輸出，要慢了45%左右(lz約79MB/s)；遠端再加上解壓和拆包，壓縮後的傳輸速度就是41.9MB/s。為什麼會下降，還不明了，作者也還沒有想到有什麼方法能夠直接加速這樣的管道傳輸，如果看客有什麼建議，不妨分享，看看還能不能最佳化，繼續提升速度。

至此，傳輸速度就能夠到150MB/s。比最原始scp(40MB/s)要快了約4倍，原來400GB需要約3小時，現在只需要45分鐘了。

5. lz4參數測試

前面實驗發現，整個流程中lz4壓縮比預期的要慢45%左右，而這裡區別僅僅是一個使用管道(pipe)、一個直接讀取。這裡嘗試通過修改lz4塊大小對比，是否有效能提升：

測試命令：

代碼如下	複製代碼
for i in `seq 4 7`; do time tar -c ./sendlog/|lz4 -B$i |pv > /dev/null ;done 1.07GiB 0:00:11 [94.4MiB/s] [                          <=>] real 0m11.640s user 0m10.375s sys 0m4.308s

可以看到塊大小為64KB的時候，lz的壓縮速度有顯著提升(31%)。於是，我們在lz4新增參數-B4，看看是否能夠提升效能：

Bang!確實，傳輸效能提升到了約249MB/s:

代碼如下	複製代碼
time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128  -o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu" 3.91GiB 0:00:16 [ 249MiB/s] real 0m16.067s user 0m15.553s sys 0m16.821s5.

 

為什麼不用nc
就不用它!!!

* nc不比ssh快；如果壓縮後傳輸，nc比ssh沒有優勢

* nc在指令碼中不好調用，需要在兩端執行命令

* nc需要一個額外的網路連接埠

* nc不加密

6. 還能不能更快
本案例中，lz4解壓縮的速度是264MB/s，這裡能夠達到249MB/s，應該還有一點點可以榨取，不過我已經沒有招了。

附錄
iperf的頻寬測試：

代碼如下

複製代碼

iperf -c 10.xxx.xx.18 -p 3999 -t 30 ------------------------------------------------------------ Client connecting to 10.xxx.xx.18, TCP port 3999 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [  3] local 10.xx.xx.36 port 43838 connected with 10.xx.xx.18 port 3999 [ ID] Interval       Transfer     Bandwidth [  3]  0.0-30.0 sec  3.15 GBytes   903 Mbits/sec iperf -s -p 3999 -m ------------------------------------------------------------ Server listening on TCP port 3999 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [  4] local 10.xx.xx.18 port 3999 connected with 10.xx.xx.36 port 43838 [ ID] Interval       Transfer     Bandwidth [  4]  0.0-30.0 sec  3.15 GBytes   902 Mbits/sec [  4] MSS size 1448 bytes (MTU 1500 bytes, ethernet)