你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

具有冷访问功能的 Azure NetApp 文件存储的性能注意事项

数据集并非总是经常使用。数据集中最多 80％的数据可被视为“冷数据”，这意味着它当前未被使用或最近未被访问过。将数据存储在 Azure NetApp 文件之类的高性能存储上时，花在所用容量上的资金实际上被浪费了，因为冷数据在再次被访问之前不需要高性能存储。

具有冷访问功能的 Azure NetApp 文件存储旨在降低 Azure 中的云存储的成本。在具体用例中需要考虑性能问题。

访问已移至冷层的数据会导致延迟加重，特别是对于随机 I/O 来说。在最坏的情况下，所有访问数据可能都在冷层，因此每个请求都需要执行数据检索。经常使用的数据集中的所有数据都位于冷层的情况并不常见，因此不太可能观察到这种延迟。

选择默认的冷访问检索策略时，顺序 I/O 读取可以直接从冷层进行，不需要将数据重新填充到热层中。随机读取的数据被重新填充到热层中，提高了后续读取的性能。与随机读取相比，顺序工作负荷的优化通常可以降低云检索产生的延迟，提高整体性能。

在最近使用 Azure NetApp 文件的带冷访问功能的标准存储进行的测试中，获得了以下结果。

注意

发布的所有结果仅供参考。无法保证结果，因为生产工作负荷中的性能可能因多种因素而异。

在热/冷层上进行 100% 的顺序读取（单个作业）

在以下场景中，通过“超高性能”性能层在 50 TiB 的 Azure NetApp 文件卷上使用了一个 D32_V5 虚拟机 (VM) 上的单个作业。使用了不同的块大小来测试热层和冷层的性能。

注意

“超高性能”服务级别的最大值是每 TiB 已分配容量 128 MiB/秒。 Azure NetApp 文件常规卷可以管理高达 5,000 MiB/秒左右的吞吐量。

下图显示了使用各种队列深度进行的此测试的冷层性能。单个 VM 的最大吞吐量约为 400 MiB/秒。

热层性能为原来的大约 2.75 倍，最高达到 1,180 MiB/秒左右。

此图并排比较了块大小为 256K 的冷层和热层的性能。

热层的延迟是存储系统本身的一个因素，当发送到服务的 I/O 数量超过任何给定时间可以处理的数量时，系统资源就会耗尽。因此，操作需要排队，直到先前发送的操作完成。

冷层的延迟通常出现在以下云检索操作中：通过网络发出针对对象存储的 I/O 请求（顺序工作负荷）或将冷块解除冻结后填充到热层（随机工作负荷）。

当工作负荷为 100% 顺序工作负荷时，冷层的吞吐量相对于热层下降约 47%（一个为 3330 MiB/秒，另一个为 1742 MiB/秒）。
当工作负荷为 100% 随机工作负荷时，冷层的吞吐量相对于热层下降约 88%（一个为 2,479 MiB/秒，另一个为 280 MiB/秒）。
执行 100% 顺序（3,330 MiB/秒）和 100% 随机（2,479 MiB/秒）工作负荷时，热层的性能下降约 25%。执行 100% 顺序（1,742 MiB/秒）和 100% 随机（280 MiB/秒）工作负荷时，冷层的性能下降约 88%。
当工作负荷包含任意百分比的随机 I/O 时，冷层的总体吞吐量更接近 100% 随机，而不是 100% 顺序。
从 100% 顺序变为 80/20 顺序/随机混合时，来自冷层的读取量下降了约 50%。
顺序 I/O 可以利用 Azure NetApp 文件中的 readahead 缓存，而随机 I/O 则不可以。顺序 I/O 的这种优势有助于减少热层和冷层之间的整体性能差异。