Я использую AWS для запуска обработки данных. У меня 400 экземпляров пятна в EC2 с 4 процессами каждый, все они записываются в одно ведро в S3. Я начал получать (видимо, необычную) ошибку:
503: Замедление
Кто-нибудь знает, каков фактический предел запроса для ведра S3? Я не могу найти документацию AWS.
Спасибо!
Из того, что я прочитал, Slow Down - очень редкая ошибка. Однако после публикации этого вопроса я получил электронное письмо от AWS, в котором говорилось, что количество запросов LIST ограничено 10 запросами в секунду, потому что у меня слишком много переходов в конкретное ведро.
Я использовал пользовательскую очередь script для проекта, над которым я работаю, и полагался на запросы LIST, чтобы определить следующий элемент для обработки. После запуска этой проблемы я переключился на AWS SQS, который был намного проще реализовать, чем я думал. Нет больше пользовательской очереди, не более массивного количества запросов LIST.
Спасибо за ответы!
Документы AWS 503 в результате временной ошибки. Он не отражает конкретного предела.
В соответствии с разделом "Рекомендации по использованию Amazon S3" по обработке ошибок (http://aws.amazon.com/articles/1904/):
Ошибки 500-й серии указывают на то, что запрос не удался, но может быть повторен. Хотя это редкость, эти ошибки следует ожидать как часть нормального взаимодействия с сервисом и должны быть явно обработаны с помощью экспоненциального алгоритма отсрочки (в идеале - для джиттера). Один такой алгоритм можно найти на http://en.wikipedia.org/wiki/Truncated_binary_exponential_backoff.
В частности, если вы вдруг начнете выполнять сотни PUT в секунду в одном ведро, вы можете обнаружить, что некоторые запросы возвращают ошибку 503 "Slow Down", когда служба работает для перераспределения нагрузки. Как и все ошибки серии 500, они должны обрабатываться с экспоненциальным отклонением.
Несмотря на то, что документация с ошибками S3 менее детализирована, она включает в себя 503 Slow Down (http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html).
Чтобы добавить к тому, что сказал Джеймс, есть некоторые внутренние элементы в разделе S3, которые обсуждались и могут быть использованы для смягчения этого в будущем, поскольку требуется экспоненциальное отключение.
Смотрите здесь: http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html
Вкратце, не храните все с одним и тем же префиксом или есть более высокая вероятность того, что у вас будут эти ошибки. Найдите способ сделать первый символ в префиксе настолько случайным, насколько это возможно, чтобы избежать горячих точек во внутреннем разбиении S3.