rsync --bwlimit 参数单位必须为 KB/s，设为--bwlimit=1024即约1MB/s；限速仅在客户端生效，服务端rsyncd.conf中无效；与-z压缩联用时，限速作用于压缩后数据流。
rsync --bwlimit 参数必须用 KB/s 单位
rsync 限速只认 --bwlimit，单位是 **KB/s（千字节每秒）**，不是 Mbps 或 MB/s。写成 --bwlimit=1024 表示上限约 1MB/s（1024 × 8 = 8192 Kbps），但注意：这是「平均吞吐量」上限，不是瞬时带宽控制，短时可能略超，长期会压到设定值。
常见错误是误以为单位是 MB/s，结果设成 --bwlimit=1 —— 实际只跑 1KB/s，慢得像卡住；或者写成 --bwlimit=1000000 想限 1Gbps，实际是 1000MB/s，远超物理网卡能力，参数虽生效但失去意义。
-
--bwlimit=500：适合共享带宽的办公网或低配 VPS，留出余量给 HTTP/SSH -
--bwlimit=2000：千兆内网常见值，兼顾速度与稳定性 - 值设为 0 或省略该参数：不限速（默认行为）
限速必须加在 rsync 命令客户端一侧
限速逻辑由 rsync 客户端实现，服务端（rsyncd）不解析 --bwlimit。也就是说，无论你走 SSH 模式（user@host:/path）还是守护进程模式（host::module），都得把 --bwlimit 放在发起同步的那台机器的命令里。
例如，从本地推送到远程服务器，限速 800KB/s：
rsync -avz --bwlimit=800 /data/ user@192.168.1.100:/backup/
反过来，从远程拉取时也一样：
rsync -avz --bwlimit=800 user@192.168.1.100:/logs/ /var/log/remote/
- 服务端配置文件
/etc/rsyncd.conf中没有等效限速字段 - 不要试图在
rsyncd.conf的[module]段里加bwlimit = 500—— rsyncd 会直接忽略 - 如果用 systemd 管理 rsyncd，也不能靠
systemctl set-property间接限速
限速和压缩（-z）一起用时要注意实际效果
-z 开启传输压缩，能减少网络字节数，但会增加 CPU 负担；--bwlimit 限制的是「压缩后实际发出的字节数」速率。所以两者叠加时，真实磁盘 I/O 和网络负载并不线性对应。
举例：源文件 100MB，压缩后发了 40MB，--bwlimit=1000 会按这 40MB 来控速；但目标端解压后写入仍是 100MB，磁盘压力没减小。
- 高 CPU 低带宽场景（如树莓派传大日志）：建议关
-z，只用--bwlimit，避免压缩拖慢整体耗时 - 高带宽低 CPU 场景（如两台 Xeon 服务器间万兆直连）：开
-z+ 合理--bwlimit可降低链路占用 -
--compress-level=1（需 rsync ≥ 3.2.0）可微调压缩强度，比默认更轻量
限速无法解决 TCP 层突发或防火墙限流问题
--bwlimit 是应用层做滑动窗口式的字节计数，它不能规避底层网络抖动、TCP 重传、或机房防火墙对单连接的硬限速（比如某云厂商限制单 SSH 连接最大 2MB/s）。如果你发现即使设了 --bwlimit=500，传输仍频繁中断或被重置，大概率是 OPS 在中间设备做了策略。
这时要配合其他手段：
- 加
--partial：断点续传，避免重传整个文件 - 改用
--inplace：减少临时文件写入，降低 I/O 峰值 - 拆大任务：用
find ... -print0 | xargs -0 -P 2 rsync ...控制并发连接数 - 换协议：若 rsync over SSH 总被掐，可试 rsync daemon 模式（端口非 22），有时绕过策略
真正关键的不是“设多少”，而是观察 --progress 输出里的瞬时速率波动，再结合 iftop -P 22 或 ss -i 看真实 TCP 发送窗口，才能判断限速是否起效、瓶颈在哪。
