我有一个从Amazon S3下载的脚本.这些脚本的工作时间为99.9%.偶尔我收到以下错误(socket.error:[Errno 104]连接由同行重置).一旦我重新启动代码,错误似乎就消失了.由于很难重现错误.我希望下面的代码剪切将修复错误.具体来说,我希望如果出现错误,它会尝试重新下载该文件.我想知道这段代码是否有用,如果还有其他什么我应该加入.我认为错误计数器可能是好的,所以如果错误确实不断出现,它最终会继续前进.(不完全确定如何添加计数器)

files = [#list of files to download]

for file in files:
    for keys in bucket.list(prefix=file):
        while True:
            try:
                keys.get_contents_to_filename()
            except socket.error:
                continue
            break

Jan Vlcinsky.. 5

我有完全相同的问题.如果你在GitHub上搜索boto,你会发现,我们并不孤单.

还有一个已知的已接受问题:https://github.com/boto/boto/issues/2207

事实上,我们已经习惯了boto和AWS S3服务,我们已经忘记了,这些都是真正的分布式系统,在某些情况下可能会破坏.

我正在归档(下载,tar,上传)大量文件(大约3年,大约15个提要,每个大约每天有1440个版本),并使用Celery更快地完成此操作.我不得不说,我有时会更频繁地收到这些错误,可能达到了AWS S3的性能限制.这些错误通常出现在块中(在我的情况下,我上传大约60 Mbps几个小时).

训练S3表现

当我测量性能时,它被"训练"了.一段时间后,S3桶的响应速度跃升,AWS可能已经检测到更高的负载并启动更多服务它的实例.

另一件事是,boto在许多情况下试图重试,因此我们的呼叫隐藏了很多失败.有时我升级到最新的稳定版本会有所改善.

尝试升级到最新的稳定版 boto

当错误率增加时,降低压力

接受这样一个事实,即AWS S3是具有罕见性能问题的分布式服务

在代码中,我肯定会建议增加一些睡眠,(至少5%,但30秒似乎没什么问题),否则你只是推难当的系统,这可能是在目前不稳定的局势.