# 性能规格 S3 Files 可自动扩展吞吐量和 IOPS 以匹配您的工作负载，而无需您预调配或管理容量。本页介绍 S3 Files 的性能特征。 ## 性能摘要 | | | | --- |--- | | 每个文件系统的总读取吞吐量 | 高达每秒数 TB | | 每个文件系统的总写入吞吐量 | 1–5 GiB/s | | 使用 S3 Files 时每个 S3 存储桶的最大读取 IOPS | 无限制（将多个文件系统附加到同一个存储桶） | | 使用 S3 Files 时每个 S3 存储桶的最大写入 IOPS | 无限制（将多个文件系统附加到同一个存储桶） | | 每个文件系统的最大读取 IOPS | 250,000 | | 每个文件系统的最大写入 IOPS | 50000 | | 每个客户端的最大读取吞吐量 | 3 GiB/s | ## S3 Files 如何提供性能 S3 Files 从两个存储层提供数据，并自动将每个操作路由到最适合它的层。 **高性能存储**：文件系统中的低延迟存储层，其中存放着活跃使用的文件数据和元数据。S3 Files 自动管理此存储，在您访问文件时将数据复制到该存储，并移除未在可配置的到期窗口内读取的数据。您需要为驻留在高性能存储上的数据支付存储费率。 **直接从 S3 存储桶中**：在两种情况下，S3 Files 会直接从 S3 存储桶流式传输文件读取：当文件的数据未存储在文件系统的高性能存储中时，以及对于 >= 1 MiB 的大型读取（即使数据也驻留在文件系统的高性能存储中）。S3 存储桶针对高吞吐量进行了优化，而文件系统的高性能存储层则针对低延迟访问进行了优化。这种直接从 S3 存储桶流式传输数据的分层方法为顺序读取提供了高吞吐量，因此非常适合分析、媒体处理和其它流式传输工作负载。S3 Files 将小文件（默认情况下 < 128 KiB）的数据异步导入到文件系统的高性能存储，以便在后续读取时实现低延迟访问。由于 S3 Files 会自动应用这种双层模型，因此您不必在延迟和吞吐量之间做出选择。小型文件工作负载可以获得文件系统性能。大型文件工作负载可以获得 S3 吞吐量。混合工作负载则兼顾两者。 ## 读取性能读取吞吐量随连接的计算实例数量和每个实例内的并行度而变化。每个客户端的最大读取吞吐量为 3 GiB/s。S3 Files 支持高达每秒数 TB 的聚合读取吞吐量，每个文件系统支持高达 250000 次读取 IOPS。 ## 写入性能写入的内容会进入高性能存储，并且可以立即实现耐久性。根据区域不同，S3 Files 支持 1–5 GiB/s 的聚合写入吞吐量，每个文件系统最多支持 50000 次写入 IOPS。写入性能随工作负载活动而弹性扩展。当您在文件系统中修改文件时，S3 Files 会等待大约 60 秒，汇总这段时间内对该文件的所有后续更改，然后再复制到 S3 存储桶。这意味着可以在单个 S3 PUT 请求中捕获对同一文件的快速连续写入，而不是为每个单独的更改生成新的对象版本，从而降低您的 S3 请求成本和存储成本。如果您在 S3 Files 将您的更改复制回 S3 存储桶后继续修改该文件，它将根据需要复制后续更改。 ## 首次访问延迟首次访问目录时，S3 Files 会导入该目录中所有文件的元数据，根据您的导入配置，还会导入小文件的数据。因此，您的初始访问比后续操作花费的时间更长。导入后，所有后续的目录列表和文件访问都将以低延迟返回。 ## 同步性能 S3 Files 在后台同步您的文件系统和 S3 存储桶之间的更改。 **从 S3 导入更改**：当其它应用程序在您的 S3 存储桶中添加或修改对象时，S3 Files 通常会在几秒钟内反映文件系统中的更改。S3 Files 对于每个文件系统每秒最多处理 2400 个对象更改，导入数据吞吐量高达每秒 700 MB。 **将更改导出到 S3**：当您通过文件系统写入文件时，S3 Files 会将您的更改批处理大约 60 秒，以便将快速连续写入整合到单个 S3 对象版本中，从而降低 S3 请求和存储版本成本。在批处理时段之后，S3 Files 会将文件复制到您的 S3 存储桶。S3 Files 对于每个文件系统每秒最多可导出 800 个文件，导出数据吞吐量高达每秒 2700 MB。 | 操作指标 | 值 | 单位 | | --- | --- | --- | | 从 S3 存储桶导入 IOPS | 2400 | 每个文件系统每秒对象数 | | 从 S3 存储桶导入吞吐量 | 700 | MB/秒 | | 导出到 S3 存储桶 IOPS | 800 | 每个文件系统每秒文件数 | | 导出到 S3 存储桶吞吐量 | 2700 | MB/秒 | Amazon S3 使用扁平存储结构，其中对象由其键名称标识。虽然 S3 Files 可让您在目录中组织数据，但 S3 没有原生的目录概念。文件系统中显示为目录的内容是由 S3 存储桶中对象的键共享的常用前缀。此外，S3 对象是不可变的，不支持原子重命名。因此，当您重命名或移动文件时，S3 Files 必须使用更新的键将数据写入新对象，然后删除原始键。重命名或移动目录时，S3 Files 必须对共享该前缀的每个对象重复此过程。因此，当您重命名或移动包含数千万个文件的目录时，您的 S3 请求成本和同步时间会显著增加。尽管重命名在文件系统上是即时的，但包含 100000 个文件的目录重命名需要几分钟才能完全反映在 S3 存储桶中。有关更多信息，请参阅 [了解重命名和移动操作的影响](s3-files-synchronization.md#s3-files-sync-rename-move)。如果您的工作负载生成更改的速度快于同步速度，则 S3 Files 会对更改进行排队并按顺序进行处理。您可以使用 `PendingExports` CloudWatch 指标监控待定导出的数量。有关更多信息，请参阅 [使用 Amazon CloudWatch 监控 S3 Files](s3-files-monitoring-cloudwatch.md)。 ## 监控性能您可以使用 Amazon CloudWatch 监控文件系统的性能。S3 Files 发布的指标包括 `DataReadBytes`、`DataWriteBytes`、`MetadataReadBytes` 和 `MetadataWriteBytes`，您可以使用这些指标来跟踪一段时间内的吞吐量和 IOPS。有关更多信息，请参阅 [使用 Amazon CloudWatch 监控 S3 Files](s3-files-monitoring-cloudwatch.md)。