Я занимаюсь рефакторингом работы по загрузке ~ 1,2 млн небольших файлов в AWS; ранее эта загрузка производилась поэтапно на машине с процессорами 64 с процессами. Я переключился на асинхронный c + многопроцессорный подход, следуя ограничениям скорости S3 и передовым практикам и рекомендациям по производительности , чтобы сделать это быстрее. С образцами данных я могу достичь времени выполнения всего 1/10. При производственных нагрузках S3 возвращает ошибку «SlowDown».
Фактически бизнес-лог c делает структуру папок такой:
s3://bucket/this/will/not/change/<shard-key>/<items>
Объекты будут равномерно разделены по ~ 30 осколкам -keys, в результате чего каждый префикс содержит ~ 40 тыс. элементов.
У нас есть каждый процесс, записывающий свой собственный префикс и запускающий пакеты по 3 тыс. запросов PUT в asyn c до завершения. После операции пакетной записи существует сон, чтобы гарантировать, что мы не отправим еще один пакет до того, как пройдет 1.1se c, поэтому мы будем учитывать 3500 запросов PUT в секунду.
Проблема в том, что мы получаем Ошибки SlowDown в течение ~ 1 часа, а затем задание записывает все файлы в течение ~ 15 минут. Если мы снизим предел до 1k / se c, это станет еще хуже, работает часами и никогда не заканчивается.
Это распределение ошибок во времени для лимита 3k / se c: 
We are using Python 3.6 with aiobotocore для запуска asyn c.
Выполнение каких-то проб и ошибок, чтобы попытаться понять, как смягчить это, требует навсегда производственных данных и тестирования с меньшим количеством данных дает разные результаты (работает безупречно).
Пропустил ли я какую-либо документацию о том, как правильно масштабировать систему?