我正在通过 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 cat 该文件并将其输出到控制台，这在 rsync 传输之前就完成了。我尝试将其 cat 到 /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 000000080000A578000000E8
WAL 驱动器是具有压缩功能的 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）。停用后，问题消失。
答案1
由于最初认为故障与网络有关，因此我建议任何人都遵循相同的步骤。
- 在应用程序之外重复相同的传输，收集运行时、正在使用的端口、路由路径的指标
- 重复到多个不同的互联网连接，这些连接路由不同
- 联系您的互联网提供商/托管提供商并提供信息
保持这个问题开放是没有意义的，因为这是一个间歇性的问题，但也许将来有人会遇到同样的问题。