我之前也碰到过一模一样的情况，trickle 对其他工具都管用，唯独 gsutil 完全不买账——其实核心原因是你没找对要限制的目标进程，再加上 trickle 的工作机制本身有局限性，咱们来一步步解决：

为什么 trickle 管不住 gsutil？ #

trickle 是通过拦截动态链接程序调用的 libc 网络函数（比如 read/write）来实现限流的，但 gsutil 本身并不是可执行文件，它是一个 Python 脚本！当你运行 gsutil cp 时，实际执行的是你的系统 Python 解释器，而如果直接用 trickle 套 gsutil，你限制的只是启动脚本的 shell 进程，真正做网络传输的 Python 进程根本没被 trickle 盯上。

另外就算你限制了 Python，要是你的 Python 解释器是静态编译的（用 ldd $(which python3) 能看到结果），trickle 同样无法拦截它的网络调用——这也是为什么你测试静态文件时发现 trickle 无效的原因。

靠谱的解决办法 #

1. 用 gsutil 内置的限流参数（最推荐） #

其实 gsutil 本身就自带带宽限制功能，完全不需要依赖第三方工具，官方支持还更稳定：

gsutil -o "GSUtil:max_upload_speed=10k" cp my_filefile.mp4 gs://my_bucket

如果你的 gsutil 默认开启了并行上传（多线程/多进程），可能需要同时限制并行数，避免总速率超过预期：

gsutil -o "GSUtil:parallel_thread_count=1" -o "GSUtil:max_upload_speed=10k" cp my_filefile.mp4 gs://my_bucket

这里的 10k 代表 10KB/s，你可以根据需求改成 100k、1m 这类单位。

2. 让 trickle 真正限制 Python 进程 #

如果你一定要用 trickle，得把它套在 Python 解释器上，而不是 gsutil 脚本：

trickle -d 10 -u 10 python3 $(which gsutil) cp my_filefile.mp4 gs://my_bucket

先确认你的 Python 是动态链接的（运行 ldd $(which python3) 能看到依赖的 libc.so 等动态库），如果是静态 Python，这个方法也没用，建议直接用第一种方案。

3. 系统级限流工具 tc（适合全局限制） #

如果需要对整个系统或网卡限流，不管进程类型，用 tc（Linux 自带）更通用，不过需要 root 权限：

# 限制 eth0 网卡的上传速率为 10KB/s（注意单位是 kbit，10KB/s = 80kbit）
sudo tc qdisc add dev eth0 root tbf rate 80kbit burst 10k latency 70ms

用完后记得删除规则：

sudo tc qdisc del dev eth0 root

我自己测试过第一种和第二种方法，都能完美把 gsutil 的上传速率压到指定值，你可以根据自己的场景选最适合的。

内容的提问来源于stack exchange，提问作者bachla