我查看了usage guide 和config docs，只是没有看到。这是我的 bash 脚本的输出，它在 S3 出现故障时使用 s3cmd sync：
WARNING: Retrying failed request: /some/bucket/path/
WARNING: 503 (Service Unavailable):
WARNING: Waiting 3 sec...
WARNING: Retrying failed request: /some/bucket/path/
WARNING: 503 (Service Unavailable):
WARNING: Waiting 6 sec...
ERROR: The read operation timed out
看起来它正在使用指数退避重试两次，然后失败。肯定有某种方法可以明确说明s3cmd 应该重试失败的网络调用多少次？
【问题讨论】：
我认为您无法设置最大重试次数。我在 GitHub (https://github.com/s3tools/s3cmd/blob/master/S3/S3.py) 上查看了它的源代码。
看起来该值是 5 并且是硬编码的：
第 240 行：
## Maximum attempts of re-issuing failed requests
_max_retries = 5
并且重试间隔计算为：
第 1004 行：
def _fail_wait(self, retries):
# Wait a few seconds. The more it fails the more we wait.
return (self._max_retries - retries + 1) * 3
以及执行重试的实际代码：
if response["status"] >= 500:
e = S3Error(response)
if response["status"] == 501:
## NotImplemented server error - no need to retry
retries = 0
if retries:
warning(u"Retrying failed request: %s" % resource['uri'])
warning(unicode(e))
warning("Waiting %d sec..." % self._fail_wait(retries))
time.sleep(self._fail_wait(retries))
return self.send_request(request, retries - 1)
else:
raise e
所以我认为在第二次尝试之后发生了一些其他错误并导致它退出重试循环。
【讨论】：
503 不太可能是因为 S3 已关闭，它几乎永远不会“关闭”。您的帐户很可能已被限制，因为您在太短的时间内发出了太多请求。
如果您控制速度，您应该放慢您的请求，或者我会建议选择更好的键，即不都以相同前缀开头的键 - 一个很好的范围广泛的键将允许 s3 传播工作量更好。
来自 Jeff Barr 的博文：
此外，S3 中的键是按前缀分区的。
正如我们所说，S3 具有自动化功能，可以不断寻找 需要拆分的键空间。分区被拆分要么是由于 持续的高请求率，或者因为它们包含大量 键（这会减慢分区内的查找速度）。有 将键移动到新创建的分区的开销，但 请求率低且没有特殊技巧，我们可以保持性能 即使在分区拆分操作期间也相当高。这种分裂 操作在整个 S3 上每天发生数十次，然后简单地进行 从用户性能的角度来看没有注意到。但是，当请求 单个分区的速率显着增加，分区拆分 对请求性能不利。那么，如何做这些更重的 工作量随着时间的推移而工作？键本身的智能命名！
我们经常看到向 S3 引入新的工作负载，其中内容是 按用户 ID 或游戏 ID 或其他类似的半无意义组织 标识符。通常这些标识符会逐渐增加 数字或各种类型的日期时间结构。不幸的 涉及 S3 扩展的这种命名选择有两个方面： 首先，所有新内容最终必然归一个人所有 分区（记住上面的请求率……）。二、所有 包含稍旧（通常不太“热”）内容的分区 变冷比其他命名约定快得多，有效 浪费每个分区每秒可以进行的可用操作 随着时间的推移，让所有旧的都变冷来支持。
使这些方案在 S3 中运行良好的最简单技巧几乎是 任何请求率都是简单地颠倒这个数字的顺序 标识符（使用秒精度的日期或基于时间的 身份标识）。这些标识符然后有效地以随机 数字——其中有几个——然后扇出 跨许多潜在子分区的事务。其中每一个 子分区的比例足够接近线性（即使有一些 内容更热或更冷），每个没有有意义的操作 第二个预算也被浪费了。事实上，S3 甚至有一个算法 检测这种并行类型的写入模式，并会自动 同时从同一个父级创建多个子分区 – 随着请求热度增加系统的每秒操作预算 被检测到。
https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/
【讨论】：