AWS CLI 如何用 multipart_chunksize、max_concurrent_requests 和 max_bandwidth 优化 s3 传输性能【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli当用aws s3 cp、aws s3 sync、aws s3 mv、aws s3 rm这类传输命令批量上传或下载文件时你可能会遇到两类问题传输速度上不去吃不满可用网络带宽或者默认的并发太高把所在环境压出连接超时、系统响应变慢。AWS CLI 的 S3 传输命令是多线程的默认同时有多条请求在飞行并提供了若干配置项来控制这个行为。本文说明multipart_chunksize、max_concurrent_requests和max_bandwidth三个参数各自的作用、默认值以及如何把它们写进 AWS CLI 配置默认位置~/.aws/config后应用到你的传输命令上。这三个参数都是可选的不配置任何值时传输命令本身可以正常工作。主要依据的文档是 s3-config 主题文档可通过aws help topics s3-config查看配置文件格式见 config-vars 主题文档参数默认值与校验逻辑可在 transferconfig.py 中核对。三个参数的默认值与调整时机参数默认值作用max_concurrent_requests10同一时刻允许的最大传输请求数multipart_chunksize8MB上传时最小 5MB启用分片传输后单个分片part的大小max_bandwidthNone不限速上传和下载时允许消费的最大带宽单位是字节/秒max_concurrent_requests控制的是并发上限。文档给出的调整方向有两条调低某些环境下默认的 10 个并发请求会压垮系统导致连接超时或系统响应变慢。调低后 S3 传输命令的资源占用更少代价是传输时间可能变长。如果同时在使用trickle这类限带宽工具调低可能也是必要的。调高希望传输尽快完成、用满可用网络带宽时默认的并发数可能不足以用满带宽调高可以缩短完成时间。multipart_threshold默认 8MB本文不涉及调整决定文件达到多大体积时切换到分片操作一旦走分片路径multipart_chunksize决定每个分片的大小。取值写法有两种直接的字节数如1048576或带大小后缀KB、MB、GB、TB如10MB、1GB。上传时分片大小的下限是 5MB如果给定的分片大小超出 S3 对分片上传的取值范围CLI 会自动把它调整到一个合法值。max_bandwidth只在上传和下载时生效对 copy 和 delete 不生效因为后两者的数据传输发生在服务端。取值写法整数表示字节/秒如1048576即 1MB/s或带速率后缀KB/s、MB/s、GB/s如300KB/s、10MB/s。两种配置方式配置文件或 aws configure set所有 S3 传输配置项必须写在 AWS Config File默认~/.aws/config中顶层s3键之下且所有值都要缩进嵌套。文档给出的配置示例此处保留了原文中与本主题相关的行[profile development] aws_access_key_idfoo aws_secret_access_keybar s3 max_concurrent_requests 20 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 50MB/s注意foo、bar是文档示例中的占位凭证写入你自己的配置时替换为实际值。另一种方式是用aws configure set逐项写入。文档示例中给 default profile 写入这些值的命令是$ aws configure set default.s3.max_concurrent_requests 20 $ aws configure set default.s3.multipart_threshold 64MB $ aws configure set default.s3.multipart_chunksize 16MB $ aws configure set default.s3.max_bandwidth 50MB/s注意命令里带default.前缀表示写入 default profile。若要写给其他 profile改用--profile标志例如给名为test-profile的 profile 设置并发数$ aws configure set s3.max_concurrent_requests 20 --profile test-profile配置来源的优先级在 config-vars 文档 中有明确说明命令行选项 环境变量 配置文件。传输命令运行时实际生效的就是所在 profile 在配置文件中s3键下的这些值。按目标选值提速传输或限制带宽目标是提速。现象是传输时间偏长、带宽利用率不满时文档建议优先调高max_concurrent_requests——它就是控制同时在飞请求数的旋钮。大文件场景下可配合调整multipart_chunksize分片路径下每个 part 的大小直接影响并发传输的粒度但保持不低于 5MB上传下限超出 S3 分片取值范围的值会被自动修正这一点由 CLI 兜底不需要手动处理。目标是限制带宽。文档给出的顺序是先动max_concurrent_requests把传输速率降到目标量级如果只靠调并发数降不到期望的速率再用max_bandwidth进一步限流。文档明确不建议反着来如果设了很高的max_concurrent_requests同时又设了很低的max_bandwidth会出现线程不必要的等待导致额外的资源消耗和连接超时。也就是说低带宽 高并发的组合是反模式限流场景下并发数应当与限流目标匹配。验证配置生效与处理参数报错检查值是否正确写入。两种配置方式最终都落在~/.aws/config上打开该文件确认目标值出现在对应 profile 的s3键内、且带缩进嵌套。aws configure set写入的就是文档示例中这种 INI 嵌套格式如果值写在了s3键之外或没有缩进就不属于 S3 传输配置项。参数非法时的报错可以直接定位。这三个参数以及同组的其他值在 transferconfig.py 中统一校验必须为正整数否则命令报错Value for 参数名 must be a positive integer: 你输入的值报错信息中的参数名和值会替换为实际内容。max_bandwidth额外要求速率形式必须以B/s结尾写成10MB这类不带速率后缀的值会触发Invalid rate: 你输入的值. The value must be expressed as a rate in terms of bytes per seconds (e.g. 10MB/s or 800KB/s)看到这个报错说明值本身合法但单位写法不对改成10MB/s或800KB/s这类带B/s的速率形式即可。运行传输命令观察进度。传输过程中 CLI 会输出进度行。文档说明在 S3 命令还不知道需要执行的总任务数之前进度行的总数会显示为...同组的max_queue_size默认 1000决定任务队列能预见多少任务调大它可以让总任务数更快确定下来代价是占用更多内存。所以调完参数后重跑传输命令进度行从...变为可确定的总量、且传输按预期完成就是配置生效的直接观察点。限制与边界这三个参数只作用于aws s3传输命令组cp、sync、mv、rm它们不改变aws s3api的调用方式。max_bandwidth对服务端执行的 copy 和 delete 不生效只有上传/下载受它约束。multipart_chunksize上传最小 5MB超出 S3 分片取值范围的值由 CLI 自动调整为合法值无需也不应手工规避。所有值必须为正整数max_bandwidth另需B/s速率后缀文档没有给出各参数的最大值或推荐区间取值应依据上面给出的现象带宽利用率、连接超时迭代调整而不是依赖预设数字。配置写在哪个 profile 下就只对使用该 profile 的命令生效aws configure set写 default profile 时要带default.前缀其他 profile 用--profile指定。如果调完并发数和分片大小后传输仍不理想或限流仍不精确下一步回到 s3-config 文档 中的max_queue_size和端点选项如use_accelerate_endpoint需先在 bucket 上启用 S3 Accelerate继续排查。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AWS CLI 如何用 multipart_chunksize、max_concurrent_requests 和 max_bandwidth 优化 s3 传输性能
AWS CLI 如何用 multipart_chunksize、max_concurrent_requests 和 max_bandwidth 优化 s3 传输性能【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli当用aws s3 cp、aws s3 sync、aws s3 mv、aws s3 rm这类传输命令批量上传或下载文件时你可能会遇到两类问题传输速度上不去吃不满可用网络带宽或者默认的并发太高把所在环境压出连接超时、系统响应变慢。AWS CLI 的 S3 传输命令是多线程的默认同时有多条请求在飞行并提供了若干配置项来控制这个行为。本文说明multipart_chunksize、max_concurrent_requests和max_bandwidth三个参数各自的作用、默认值以及如何把它们写进 AWS CLI 配置默认位置~/.aws/config后应用到你的传输命令上。这三个参数都是可选的不配置任何值时传输命令本身可以正常工作。主要依据的文档是 s3-config 主题文档可通过aws help topics s3-config查看配置文件格式见 config-vars 主题文档参数默认值与校验逻辑可在 transferconfig.py 中核对。三个参数的默认值与调整时机参数默认值作用max_concurrent_requests10同一时刻允许的最大传输请求数multipart_chunksize8MB上传时最小 5MB启用分片传输后单个分片part的大小max_bandwidthNone不限速上传和下载时允许消费的最大带宽单位是字节/秒max_concurrent_requests控制的是并发上限。文档给出的调整方向有两条调低某些环境下默认的 10 个并发请求会压垮系统导致连接超时或系统响应变慢。调低后 S3 传输命令的资源占用更少代价是传输时间可能变长。如果同时在使用trickle这类限带宽工具调低可能也是必要的。调高希望传输尽快完成、用满可用网络带宽时默认的并发数可能不足以用满带宽调高可以缩短完成时间。multipart_threshold默认 8MB本文不涉及调整决定文件达到多大体积时切换到分片操作一旦走分片路径multipart_chunksize决定每个分片的大小。取值写法有两种直接的字节数如1048576或带大小后缀KB、MB、GB、TB如10MB、1GB。上传时分片大小的下限是 5MB如果给定的分片大小超出 S3 对分片上传的取值范围CLI 会自动把它调整到一个合法值。max_bandwidth只在上传和下载时生效对 copy 和 delete 不生效因为后两者的数据传输发生在服务端。取值写法整数表示字节/秒如1048576即 1MB/s或带速率后缀KB/s、MB/s、GB/s如300KB/s、10MB/s。两种配置方式配置文件或 aws configure set所有 S3 传输配置项必须写在 AWS Config File默认~/.aws/config中顶层s3键之下且所有值都要缩进嵌套。文档给出的配置示例此处保留了原文中与本主题相关的行[profile development] aws_access_key_idfoo aws_secret_access_keybar s3 max_concurrent_requests 20 multipart_threshold 64MB multipart_chunksize 16MB max_bandwidth 50MB/s注意foo、bar是文档示例中的占位凭证写入你自己的配置时替换为实际值。另一种方式是用aws configure set逐项写入。文档示例中给 default profile 写入这些值的命令是$ aws configure set default.s3.max_concurrent_requests 20 $ aws configure set default.s3.multipart_threshold 64MB $ aws configure set default.s3.multipart_chunksize 16MB $ aws configure set default.s3.max_bandwidth 50MB/s注意命令里带default.前缀表示写入 default profile。若要写给其他 profile改用--profile标志例如给名为test-profile的 profile 设置并发数$ aws configure set s3.max_concurrent_requests 20 --profile test-profile配置来源的优先级在 config-vars 文档 中有明确说明命令行选项 环境变量 配置文件。传输命令运行时实际生效的就是所在 profile 在配置文件中s3键下的这些值。按目标选值提速传输或限制带宽目标是提速。现象是传输时间偏长、带宽利用率不满时文档建议优先调高max_concurrent_requests——它就是控制同时在飞请求数的旋钮。大文件场景下可配合调整multipart_chunksize分片路径下每个 part 的大小直接影响并发传输的粒度但保持不低于 5MB上传下限超出 S3 分片取值范围的值会被自动修正这一点由 CLI 兜底不需要手动处理。目标是限制带宽。文档给出的顺序是先动max_concurrent_requests把传输速率降到目标量级如果只靠调并发数降不到期望的速率再用max_bandwidth进一步限流。文档明确不建议反着来如果设了很高的max_concurrent_requests同时又设了很低的max_bandwidth会出现线程不必要的等待导致额外的资源消耗和连接超时。也就是说低带宽 高并发的组合是反模式限流场景下并发数应当与限流目标匹配。验证配置生效与处理参数报错检查值是否正确写入。两种配置方式最终都落在~/.aws/config上打开该文件确认目标值出现在对应 profile 的s3键内、且带缩进嵌套。aws configure set写入的就是文档示例中这种 INI 嵌套格式如果值写在了s3键之外或没有缩进就不属于 S3 传输配置项。参数非法时的报错可以直接定位。这三个参数以及同组的其他值在 transferconfig.py 中统一校验必须为正整数否则命令报错Value for 参数名 must be a positive integer: 你输入的值报错信息中的参数名和值会替换为实际内容。max_bandwidth额外要求速率形式必须以B/s结尾写成10MB这类不带速率后缀的值会触发Invalid rate: 你输入的值. The value must be expressed as a rate in terms of bytes per seconds (e.g. 10MB/s or 800KB/s)看到这个报错说明值本身合法但单位写法不对改成10MB/s或800KB/s这类带B/s的速率形式即可。运行传输命令观察进度。传输过程中 CLI 会输出进度行。文档说明在 S3 命令还不知道需要执行的总任务数之前进度行的总数会显示为...同组的max_queue_size默认 1000决定任务队列能预见多少任务调大它可以让总任务数更快确定下来代价是占用更多内存。所以调完参数后重跑传输命令进度行从...变为可确定的总量、且传输按预期完成就是配置生效的直接观察点。限制与边界这三个参数只作用于aws s3传输命令组cp、sync、mv、rm它们不改变aws s3api的调用方式。max_bandwidth对服务端执行的 copy 和 delete 不生效只有上传/下载受它约束。multipart_chunksize上传最小 5MB超出 S3 分片取值范围的值由 CLI 自动调整为合法值无需也不应手工规避。所有值必须为正整数max_bandwidth另需B/s速率后缀文档没有给出各参数的最大值或推荐区间取值应依据上面给出的现象带宽利用率、连接超时迭代调整而不是依赖预设数字。配置写在哪个 profile 下就只对使用该 profile 的命令生效aws configure set写 default profile 时要带default.前缀其他 profile 用--profile指定。如果调完并发数和分片大小后传输仍不理想或限流仍不精确下一步回到 s3-config 文档 中的max_queue_size和端点选项如use_accelerate_endpoint需先在 bucket 上启用 S3 Accelerate继续排查。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考