背景
我有一台託管虛擬機器的伺服器和一台較舊的 NAS Synology DS1512+，用作這些虛擬機器的備份目標。伺服器使用ZFS，建立快照並將快照檔案傳輸到NAS。 NAS 使用啟用壓縮的 BTRFS，並支援快照。最終目標是伺服器實際上只使用 RSYNC 發送 DELTA，以最大限度地減少 NAS 接收到的更改資料量，並有效利用快照。
問題
不過，將 RSYNC 與 DELTA 結合使用在我的情況下不起作用，因為傳輸資料只需要太多時間。當 RSYNC 與 一起使用時--inplace --whole-file，資料傳輸大約需要 2 小時。當刪除--whole-file以使用 DELTA 時，相同的備份過程需要更長的時間，我經常在已經運行 12 個多小時後終止該進程。由於歷史原因，我需要將不同的備份放入更小的時間視窗中。
唯一有意義的瓶頸是 NAS，因為伺服器功能更強大且大部分時間都處於閒置狀態。 NAS OTOH 在備份期間對 CPU 和 I/O 的負載相當高。不過，這些數字也不算太糟糕，只是比使用時更糟--whole-file。這樣，NAS 幾乎可以簡單地寫入約 100+ MiB/s，而使用 DELTA 時，它在大多數情況下讀取速度較慢，範圍從約 50 到 100 MiB/s。我認為由於 DELTA 而無法寫入的資料量很容易勝過較慢的 NAS，但事實似乎並非如此。而且虛擬機器上變化的資料量大多都不是太高。
觀察
我在 NAS 上發現 RSYNC 似乎在某個時刻同時處理兩個檔案。這看起來像是一些預讀或類似的內容：
root@amds1512-01:~# lsof | grep [d]asi_
rsync 6883 root cwd DIR 0,33 290 259 /volume1/[...]
rsync 6883 root 0r REG 0,33 2142633984 580 /volume1/[...]/[...]-s024.vmdk
rsync 6884 root cwd DIR 0,33 290 259 /volume1/[...]
rsync 6884 root 1r REG 0,33 2143748096 579 /volume1/[...]/[...]-s023.vmdk
rsync 6884 root 3w REG 0,33 2143748096 579 /volume1/[...]/[...]-s023.vmdk
HTOP 清楚地顯示 RSYNC 的兩個實例都已讀取。只需忽略其他 RSYNC 進程，這些進程是不相關的，即使一個備份獨佔運行，問題仍然存在。
問題
那麼這兩個在備份目標上運行不同檔案的 RSYNC 的目的是什麼？有沒有辦法告訴 RSYNC 只處理一個又一個檔案？
這可能會增加總體處理時間並減少並發負載。我在手冊頁中找不到類似預讀或類似內容的內容。如果有任何區別，以下是使用的選項：
--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials
謝謝！
答案1
看一眼Rsync 的工作原理。具體來說，有一個生成器進程和一個發送器進程作為管道運行。發送者讀取文件並發送到遠端。生成器負責產生要傳送的文件列表，並且「為基礎文件建立區塊校驗和，並在文件索引號之後立即發送給發送者」。
--inplace如果您用來發送多個大文件，這聽起來絕對有可能導致文件系統崩潰並且沒有足夠的 RAM 可供核心在快取中保存兩個連續的文件。
作為測試，您可以嘗試傳輸單個文件，rsync --inpace看看效能是否明顯更好。 （類似於for i in *.vmdk; do rsync [...]; done。）這應該有助於確定兩個單獨的讀取器是否確實導致了性能問題。
如果有多位讀者是導致效能問題，那麼一種可能的途徑是提高核心快取讀取的能力，方法是為主機核心提供更多可用 RAM 或縮小各個 vmdk 檔案。
不幸的是，我沒有看到任何明顯的方法來更改 rsync 中的生成器/發送器管道行為，除非編寫自己的腳本來為每個檔案呼叫一次 rsync 。您可能想在rsync 郵件列表。