Ftp
為什麼多個小文件的網路文件傳輸如此緩慢?
通過各種形式的文件傳輸傳輸大量(數 GB)數據時,例如:FTP、SFTP、NFS 和 Samba。他們都遇到了相同的問題,即多個小文件有時會阻礙速度降至 MB 或 KB——甚至超過 10Gbps 的連結。
但是,如果我要在傳輸之前對整個文件夾進行 zip、tar 或 rar 壓縮,那麼網路連結就會完全飽和。
- 是什麼導致了這種效果?
- 可以採取哪些措施來提高通過網路傳輸許多小型單個文件的大型傳輸的性能?
- 在可用的文件傳輸協議中,哪種最適合?
我對網路進行了全面管理,因此所有配置和選項都可用,例如在網路介面上設置 MTU 和緩衝區大小,以及在文件伺服器配置中關閉非同步和加密,這是一些一次性的想法。
文件系統元數據。系統管理員低估了使文件成為可能所需的成本。直到他們嘗試處理許多小文件。
假設您有 100 萬個 4 KB 的小文件,具有 8 個驅動器主軸的速度相當快的儲存,以及一個 10 Gb 的連結,該陣列有時會因順序讀取而飽和。進一步假設每個主軸 100 IOPS,每個文件需要一個 IO(這過於簡單,但說明了這一點)。
$ units "1e6 / (8 * 100 per sec)" "sec" * 1250 / 0.0008
21分鐘!相反,假設數百萬個文件位於一個存檔文件中,並且順序傳輸會使 10 Gb 鏈路飽和。80% 的有用吞吐量,由於被包裹在乙太網中的 IP 中。
$ units "(1e6 * 4 * 1024 * 8 bits) / (1e10 bits per second * .8)" "sec" * 4.096 / 0.24414062
4秒是相當快的。
如果底層儲存是小文件,那麼任何文件傳輸協議都會有很多問題。當陣列的 IOPS 成為瓶頸時,位於其之上的文件伺服器的協議並沒有真正的幫助。
最快的方法是複制一個大存檔或磁碟映像。主要是順序 IO,最少的文件系統元數據。
也許使用文件服務協議,您不必複製所有內容。掛載遠端共享並訪問您需要的文件。但是,訪問具有大量文件的目錄或將它們全部複製仍然很慢。(請注意,NFS 伺服器意外關閉可能會導致客戶端永遠卡在 IO 中。)