我在 EC2 实例（特别是 i3.8xlarge）上运行批量计算作业，并将大型（10 GB）二进制文件上传到每个实例。我们的办公室有“千兆位”（Century Link），我通常以 30-40 MBps 的速度将这些文件上传（通过 scp）到 EC2。本地机器是 RH7 Linux 机器。然而，我经常观察到一件奇怪的事情：上传速度急剧下降到 300-400 kBps。
- 我通过 speedtest.net 验证了网络性能良好
- 降低的上传速度始终为 300-400 kBps
- 这一现象大约一个月前开始
- 我可以从 Gnome 终端的不同选项卡同时将同一个文件上传到同一个实例（显然是不同的输出路径），并且获得良好的性能
- 上传通常会意外地恢复到良好的速率
因此瓶颈似乎与单个 scp 进程有关。亚马逊不宣传任何类型的上传限制。当我观察到这种情况时，我们的网络人员确认网络运行良好。
答案1
我怀疑你的EBS 突发余额已经用完了。该博客链接为您提供了有关如何显示 EBS 卷突发信用的说明。
这卷类型页面上有一些关于 EBS 和爆发的信息。
通用型 SSD (gp2) 卷提供经济高效的存储，是各种工作负载的理想选择。这些卷的延迟仅为几毫秒，并且能够在较长时间内突增至 3,000 IOPS。在最低 100 IOPS（33.33 GiB 及以下）和最高 16,000 IOPS（5,334 GiB 及以上）之间，基准性能以每 GiB 卷大小 3 IOPS 的速率线性扩展。AWS 设计 gp2 卷以在 99% 的时间内提供其预配置性能。gp2 卷的大小范围为 1 GiB 到 16 TiB。
简而言之，您会积累突发信用，并且随着您大量使用磁盘，信用会耗尽。当这种情况发生时，您会获得基准性能。磁盘越大，信用越多，您耗尽信用的可能性就越小。有各种文章（例如这个) 您可以阅读有关它们的内容。
实例存储卷没有突发系统，这就是它们始终快速运行的原因。
这里的解决方案可能是缓冲对实例存储的写入，然后在后台将它们传输到 EBS 卷。rsync 可能合适。
答案2
好吧，所以我能够通过将文件写入板载 NVMe SSD 而不是 EBS 存储来“解决”该问题（？）。不过，这毫无意义。EBS 的写入能力肯定比 300-400 kBps 更好！