Postgresql
Barman：rsync wal 檔案在某些文件上停滯不前
我正在通過 rsync 從 postgres 伺服器存檔 wal 文件，大多數情況下存檔工作正常且速度很快，連接的速度測試在這裡：（這是通過網際網路進行的）
[ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 9.30 MBytes 78.0 Mbits/sec 0 395 KBytes [ 4] 1.00-2.00 sec 66.3 MBytes 556 Mbits/sec 14 1.05 MBytes [ 4] 2.00-3.00 sec 75.0 MBytes 629 Mbits/sec 0 1.16 MBytes [ 4] 3.00-4.00 sec 81.2 MBytes 682 Mbits/sec 0 1.24 MBytes [ 4] 4.00-5.00 sec 86.2 MBytes 724 Mbits/sec 0 1.30 MBytes [ 4] 5.00-6.00 sec 88.8 MBytes 744 Mbits/sec 0 1.34 MBytes [ 4] 6.00-7.00 sec 91.2 MBytes 765 Mbits/sec 0 1.37 MBytes [ 4] 7.00-8.00 sec 92.5 MBytes 776 Mbits/sec 0 1.38 MBytes [ 4] 8.00-9.00 sec 93.8 MBytes 786 Mbits/sec 0 1.39 MBytes [ 4] 9.00-10.00 sec 63.8 MBytes 535 Mbits/sec 22 535 KBytes因此，可用的頻寬綽綽有餘。
但是在某些 WAL 文件上，它只是爬得很慢，需要 30 - 50 秒才能傳輸 16 MB 文件，我不知道在哪裡調試/查找問題。
rsync 命令如下所示：
rsync -p --chmod=Fg+r,Fo+r --timeout 10 -e /usr/bin/ssh -i /var/lib/pgsql/.ssh/id_rsa -a pg_wal/000000080000A5500000005D barman@barman_host/data/database/pg/incoming/000000080000A5500000005D我在接收端通過 strace 查看了 rsync，似乎只有來自發送端的數據包到達的速度不夠快。我嘗試通過 ssh 擷取文件並將其輸出到我的控制台上，這在 rsync 傳輸之前完成。我試圖將它轉移到 /dev/null，那是即時的。
所以我假設源驅動器足夠快。
我通過一個 rsync 命令傳輸了大量 WAL 文件（60GB），速度也很快，平均 65 MB/s，所以這告訴我一切正常，但有些文件仍然很慢。
我還能看什麼？我如何確定問題是發送端、網速還是接收端，是否有一些特殊的日誌可以在 rsync 上啟動？我可以通過 strace 檢查系統呼叫的時間嗎？
ls -l 000000080000A578000000E8 -rw-------. 1 postgres postgres 16777216 Jul 19 07:32 000000080000A578000000E8 bash-4.2$ du -sh 000000080000A578000000E8 11M 000000080000A578000000E8 bash-4.2$ du -sh 000000080000A578000000E8 --apparent-size 16M 000000080000A578000000E8WAL 驅動器是具有壓縮功能的 ZFS，因此有所不同。
同樣為了完成，所有 zfs 屬性：
storage/database type filesystem - storage/database creation Thu Apr 19 12:22 2018 - storage/database used 1.33T - storage/database available 369G - storage/database referenced 1.33T - storage/database compressratio 2.13x - storage/database mounted yes - storage/database quota none default storage/database reservation none default storage/database recordsize 16K inherited from storage storage/database mountpoint /data/ local storage/database sharenfs off default storage/database checksum on default storage/database compression lz4 inherited from storage storage/database atime off inherited from storage storage/database devices on default storage/database exec on default storage/database setuid on default storage/database readonly off default storage/database zoned off default storage/database snapdir hidden default storage/database aclinherit restricted default storage/database createtxg 1159021 - storage/database canmount on default storage/database xattr sa inherited from storage storage/database copies 1 default storage/database version 5 - storage/database utf8only off - storage/database normalization none - storage/database casesensitivity sensitive - storage/database vscan off default storage/database nbmand off default storage/database sharesmb off default storage/database refquota none default storage/database refreservation none default storage/database guid 8214081110063784152 - storage/database primarycache all default storage/database secondarycache all default storage/database usedbysnapshots 0B - storage/database usedbydataset 1.33T - storage/database usedbychildren 0B - storage/database usedbyrefreservation 0B - storage/database logbias throughput inherited from storage storage/database dedup off default storage/database mlslabel none default storage/database sync disabled local storage/database dnodesize legacy default storage/database refcompressratio 2.13x - storage/database written 1.33T - storage/database logicalused 2.82T - storage/database logicalreferenced 2.82T - storage/database volmode default default storage/database filesystem_limit none default storage/database snapshot_limit none default storage/database filesystem_count none default storage/database snapshot_count none default storage/database snapdev hidden default storage/database acltype off default storage/database context none default storage/database fscontext none default storage/database defcontext none default storage/database rootcontext none default storage/database relatime off default storage/database redundant_metadata all default storage/database overlay off default但是在過去的幾天裡，ZFS 驅動器沒有任何改變——整個問題才從星期五（7 月 17 日）開始。
此外，如果我複制粘貼命令並再次執行它，它會立即完成 - 仍在執行的命令將繼續掛起。
使用 ls -lah 您可以了解臨時文件如何變得越來越大（大約 150 KB/s）
感謝任何花時間閱讀本文的人！
編輯：我在 wal 歸檔過程中添加了計時記錄，結果如下：
000000080000A57C00000034 1 000000080000A57C00000035 0 000000080000A57C00000036 0 000000080000A57C00000037 1 000000080000A57C00000038 1 000000080000A57C00000039 119 000000080000A57C0000003A 2 000000080000A57C0000003B 1 000000080000A57C0000003C 127 000000080000A57C0000003D 2 000000080000A57C0000003E 1 000000080000A57C0000003F 1 000000080000A57C00000040 1 000000080000A57C00000041 1 000000080000A57C00000042 1 000000080000A57C00000043 1 000000080000A57C00000044 1 000000080000A57C00000045 1 000000080000A57C00000046 1 000000080000A57C00000047 1 000000080000A57C00000048 1 000000080000A57C00000049 105 000000080000A57C0000004A 2 000000080000A57C0000004B 2 000000080000A57C0000004C 1 000000080000A57C0000004D 1 000000080000A57C0000004E 118 000000080000A57C0000004F 2 000000080000A57C00000050 1 000000080000A57C00000051 120 000000080000A57C00000052 2 000000080000A57C00000053 1右邊的數字是對指定文件執行 Rsync 命令所用的秒數。
編輯2：
我用每側 2 個 ram 驅動器重新創建了這個問題。我提取了使用的埠，發現它們都是偶數（可能是一個提示）
我已經在我這邊（目標）的網際網路連接之間切換，問題就消失了。根據討論，這似乎是某個路徑上的網路問題（可能是由於負載平衡）
我將更新最終決議。
編輯3：
我們的供應商是 Hetzner，他們的一個 DECIX 模組（https://www.hetzner-status.de/#16045）有問題。停用後問題就消失了。
由於最初認為故障與網路相關，因此我建議任何人都遵循相同的步驟。
- 在應用程序之外重複相同的傳輸，收集執行時指標、使用的埠、路由路徑
- 重複路由到多個不同的網際網路連接
- 請與您的網際網路提供商/託管服務提供商聯繫並提供資訊
保持這個問題開放是沒有意義的，因為這是一個間歇性的問題，但也許將來有人可能會有同樣的問題。