一组 Linux EC2 Spot 实例使用从快照恢复的附加 EBS 卷，并且这些实例经常启动和停止。从快照恢复卷后，初始 I/O 吞吐量低于预期，并且工作负载无法获得所需的接近完全预置的 IOPS。SysOps 管理员应如何操作以确保恢复的 EBS 卷立即提供预期的性能？

正确答案是启用快速快照恢复 (FSR)。从快照恢复 EBS 卷时，数据会按需从 Amazon S3 传输到卷。这意味着在所有数据都传输完毕之前，卷的性能可能低于预期。FSR 预先加载数据，确保卷在创建后立即提供其全部预置性能，这对于经常启动和停止的 Spot 实例至关重要。 将快照恢复到未加密的 EBS 卷，然后在性能稳定后再加密，这并不能解决初始性能问题，反而增加了操作复杂性。在恢复快照之前格式化 EBS 卷是不必要的，因为快照已经包含了文件系统，并且格式化操作本身不会改善初始性能。增加 Linux 预读缓冲区可以优化某些工作负载的 I/O 性能，但它不能解决从快照恢复卷时数据按需加载导致的初始性能瓶颈。