排查Azure 文件存储性能问题

  • 项目

注意

本文中引用的 CentOS 是 Linux 发行版， (EOL) 将达到生命周期结束。 相应地考虑使用和计划。 有关详细信息，请参阅 CentOS 生命周期终止指南。

本文列出了与 Azure 文件共享性能相关的常见问题，并提供了潜在的原因和解决方法。 若要从本故障排除指南中获取最大价值，建议首先阅读了解Azure 文件存储性能。

适用对象

文件共享类型 SMB Nfs
标准文件共享 (GPv2) 、LRS/ZRS
标准文件共享 (GPv2) 、GRS/GZRS
高级文件共享 (FileStorage) 、LRS/ZRS

常规性能故障排除

首先，排除出现性能问题的一些常见原因。

你运行的是旧操作系统

如果客户端虚拟机 (VM) 正在运行Windows 8.1、Windows Server 2012 R2 或较旧的 Linux 发行版或内核，则访问 Azure 文件共享时可能会遇到性能问题。 升级客户端 OS 或应用以下修补程序。

Windows 8.1和Windows Server 2012 R2 的注意事项

运行 Windows 8.1 或 Windows Server 2012 R2 的客户端在访问用于 I/O 密集型工作负荷的 Azure 文件共享时，延迟可能会高于预期。 请确保已安装 KB3114025 修补程序。 此修补程序提高了创建和关闭句柄的性能。

可以运行以下脚本来检查是否已安装修补程序：

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

如果安装了修补程序，将显示以下输出：

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

注意

从 2015 年 12 月开始，Azure 市场 中的Windows Server 2012 R2 映像默认安装修补程序KB3114025。

工作负荷受到限制

当达到文件共享的每秒 I/O 操作 (IOPS) 、入口或出口限制时，请求将受到限制。 例如，如果客户端超过基线 IOPS，它将受到Azure 文件存储服务的限制。 限制可能会导致客户端遇到性能不佳的问题。

若要了解标准和高级文件共享的限制，请参阅 文件共享和文件缩放目标。 根据工作负荷，通常可以通过从标准 Azure 文件共享迁移到高级 Azure 文件共享来避免限制。

若要详细了解共享级别或存储帐户级别的限制如何导致高延迟、低吞吐量和常规性能问题，请参阅 共享或存储帐户被限制。

高延迟、低吞吐量或低 IOPS

原因 1：共享或存储帐户受到限制

若要确认共享或存储帐户是否受到限制，可以在门户中访问和使用 Azure 指标。 还可以创建警报，以便在共享受到限制或即将受到限制时通知你。 请参阅通过创建警报排查Azure 文件存储问题。

重要

对于启用了大型文件共享 (LFS) 的标准存储帐户，会在帐户级别进行限制。 对于未启用LFS的高级文件共享和标准文件共享，会在共享级别进行限制。

  1. 在Azure 门户，转到存储帐户。

  2. 在左窗格的 “监视”下，选择“ 指标”。

  3. 选择“ 文件 ”作为存储帐户范围的指标命名空间。

  4. 选择“ 事务 ”作为指标。

  5. 为响应类型添加筛选器，然后检查以查看是否已限制任何请求。

    对于未启用大型文件共享的标准文件共享，如果请求在共享级别受到限制，则会记录以下响应类型：

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    对于启用了大型文件共享的标准文件共享，如果在客户端帐户级别限制请求，则会记录以下响应类型：

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    对于高级文件共享，如果在共享级别限制请求，则会记录以下响应类型：

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareEgressThrottlingError
    • ClientShareIngressThrottlingError
    • ClientShareIopsThrottlingError

    如果使用 Kerberos 对受限制的请求进行身份验证，则可能会看到指示身份验证协议的前缀，例如：

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    若要详细了解每种响应类型，请参阅 指标维度。

    显示“响应类型”属性筛选器的屏幕截图。

解决方案

原因 2：元数据或命名空间繁重的工作负荷

如果大多数请求都是以元数据为中心的 (（例如 createfile、openfile、、 closefilequeryinfo或 querydirectory) ），则延迟将比读/写操作更差。

若要确定大多数请求是否以元数据为中心，请首先按照前面原因 1 中所述的步骤 1-4 操作。 对于步骤 5，无需为 响应类型添加筛选器，而是为 API 名称添加属性筛选器。

显示“API 名称”属性筛选器的屏幕截图。

解决办法

  • 检查是否可以修改应用程序以减少元数据操作的数量。

  • 如果使用高级 SMB Azure 文件共享，请使用 元数据缓存。

  • 将文件共享拆分为同一存储帐户中的多个文件共享。

  • 在文件共享上添加虚拟硬盘 (VHD) ，并从客户端装载 VHD 以针对数据执行文件操作。 此方法适用于单个编写器/读取器方案，或具有多个读取器且没有编写器的方案。 由于文件系统由客户端拥有，而不是Azure 文件存储，因此允许将元数据操作设置为本地操作。 该设置提供的性能类似于本地直接附加存储的性能。 但是，由于数据位于 VHD 中，因此不能通过 SMB 装载以外的任何其他方式（例如 REST API 或Azure 门户）访问这些数据。

    1. 在需要访问 Azure 文件共享的计算机中，使用存储帐户密钥装载文件共享，并将其映射到可用的网络驱动器 (例如 Z：) 。
    2. 转到“磁盘管理”，然后选择“VHD Create操作>”。
    3. 将 “位置” 设置为 Azure 文件共享映射到的网络驱动器，根据需要设置 虚拟硬盘大小 ，然后选择“ 固定大小”。
    4. 选择“确定”。 VHD 创建完成后，它将自动装载，并会出现新的未分配磁盘。
    5. 右键单击新的未知磁盘，然后选择 “初始化磁盘”。
    6. 右键单击未分配的区域并创建新的 简单卷。
    7. 在 磁盘管理 中应会显示一个新的驱动器号，表示此 VHD 具有读/写访问权限 (例如 E：) 。 在 文件资源管理器 中，应会看到映射的 Azure 文件共享的网络驱动器上的新 VHD (Z：在此示例中) 。 要清楚，应存在两个驱动器号：Z：上的标准 Azure 文件共享网络映射和 E： 驱动器上的 VHD 映射。
    8. 与 Azure 文件共享映射驱动器 (Z：) 相比，针对 VHD 映射驱动器上的文件执行大量元数据操作的性能应该要好得多 (E：) 。 如果需要，应可以断开映射的网络驱动器 (Z：) ，并仍 (E：) 访问已装载的 VHD 驱动器。
    • 若要在 Windows 客户端上装载 VHD，也可以使用 Mount-DiskImage PowerShell cmdlet。
    • 若要在 Linux 上装载 VHD，请参阅 Linux 分发版的文档。 下面是一个示例。

原因 3：单线程应用程序

如果使用的应用程序是单线程的，则此设置可能会导致 IOPS 吞吐量明显低于可能的最大吞吐量，具体取决于预配的共享大小。

解决方案

  • 通过增加线程数来提高应用程序并行度。
  • 切换到可能实现并行度的应用程序。 例如，对于复制操作，可以从 Windows 客户端使用 AzCopy 或 RoboCopy，或者从 Linux 客户端使用 并行 命令。

原因 4：SMB 通道数超过 4

如果使用 SMB MultiChannel 并且你拥有的通道数超过 4 个，则会导致性能不佳。 若要确定连接计数是否超过 4，请使用 PowerShell cmdlet get-SmbClientConfiguration 查看当前连接计数设置。

解决方案

为 SMB 设置每个 NIC 的 Windows 设置，使总通道数不超过 4。 例如，如果你有两个 NIC，则可以使用以下 PowerShell cmdlet 将每个 NIC 的最大值设置为两个： Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2。

原因 5：预读大小太小， (NFS 仅)

从 Linux 内核版本 5.4 开始，Linux NFS 客户端使用默认值 read_ahead_kb 128 kibibytes (KiB) 。 此小值可能会降低大型文件的读取吞吐量。

解决方案

建议将 read_ahead_kb 内核参数值增加到 15 兆字节， (MiB) 。 若要更改此值，请在 Linux 内核设备管理器 udev 中添加规则，从而永久设置预读大小。 请按照下列步骤操作：

  1. 在文本编辑器中，通过输入并保存以下文本来创建 /etc/udev/rules.d/99-nfs.rules 文件：

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. 在控制台中，通过以超级用户身份运行 udevadm 命令并重新加载规则文件和其他数据库来应用 udev 规则。 若要使 udev 了解新文件，只需运行此命令一次。

    sudo udevadm control --reload

请求的延迟非常高

原因

客户端 VM 可能位于与文件共享不同的区域。 导致高延迟的其他原因可能是客户端或网络造成的延迟。

解决方案

  • 从与文件共享位于同一区域的 VM 运行应用程序。
  • 对于存储帐户，请在 Azure 门户 中通过 Azure Monitor 查看事务指标 SuccessE2ELatency 和 SuccessServerLatency。 SuccessE2ELatency 和 SuccessServerLatency 指标值之间的较大差异表明延迟可能是由网络或客户端引起的。 请参阅Azure 文件存储监视数据参考中的事务指标。

客户端无法实现网络支持的最大吞吐量

原因

一个潜在原因是缺少对标准文件共享的 SMB 多通道支持。 目前，Azure 文件存储仅支持标准文件共享的单通道，因此只有一个从客户端 VM 到服务器的连接。 此单一连接与客户端 VM 上的单个核心挂钩，因此 VM 可实现的最大吞吐量受单个核心的约束。

解决方法

Linux VM 上装载的 Azure 文件共享的性能降低

原因 1：缓存

性能缓慢的一个可能原因是禁用缓存。 如果重复访问文件，则缓存可能很有用。 否则，它可能是一个开销。 在禁用缓存之前，请检查是否正在使用缓存。

原因 1 的解决方案

若要检查是否禁用缓存，请查找 条目cache=。

Cache=none 指示缓存已禁用。 通过使用默认装载命令或向装载命令显式添加 cache=strict 选项来重新装载共享，以确保启用默认缓存或“严格”缓存模式。

在某些情况下， serverino 装载选项可能会导致 ls 命令针对每个目录条目运行 stat 。 列出大型目录时，此行为会导致性能下降。 可以在 /etc/fstab 条目中检查装载选项：

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

还可以通过运行 sudo mount | grep cifs 命令并检查其输出来检查是否使用了正确的选项。 下面是一个示例输出：

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

cache=strict如果 或 serverino 选项不存在，请通过运行文档中的装载命令来卸载并再次装载Azure 文件存储。 然后，重新检查 /etc/fstab 条目是否具有正确的选项。

原因 2：限制

你可能遇到限制，并且请求正在发送到队列。 可以通过利用 Azure Monitor 中的 Azure 存储指标来验证这一点。 还可以创建警报，以便在共享受到限制或即将受到限制时通知你。 请参阅通过创建警报排查Azure 文件存储问题。

原因 2 的解决方案

确保应用在Azure 文件存储缩放目标范围内。 如果使用标准 Azure 文件共享，请考虑切换到高级版。

Linux 客户端上的吞吐量低于 Windows 客户端的吞吐量

原因

这是在 Linux 上实现 SMB 客户端的已知问题。

解决方法

  • 将负载分散到多个 VM。
  • 在同一 VM 上，使用具有 选项 nosharesock 的多个装入点，并将负载分散在这些装入点上。
  • 在 Linux 上，尝试使用 nostrictsync 选项进行装载，以避免在每次 fsync 调用时强制刷新 SMB。 对于Azure 文件存储，此选项不会影响数据一致性，但可能会导致目录列表上的文件元数据过时， (ls -l 命令) 。 使用 stat 命令直接查询文件元数据将返回最新的文件元数据。

涉及大量打开/关闭操作的元数据密集型工作负载的高延迟

原因

缺少对目录租用的支持。

解决方法

  • 如果可能，请避免在短时间内在同一目录上使用过多的打开/关闭句柄。
  • 对于 Linux VM，通过将 指定 actimeo=<sec> 为装载选项来增加目录条目缓存超时。 默认情况下，超时为 1 秒，因此较大的值（如 30 秒）可能会有所帮助。
  • 对于 CentOS Linux 或 Red Hat Enterprise Linux (RHEL) VM，请将系统升级到 CentOS Linux 8.2 或 RHEL 8.2。 对于其他 Linux 发行版，请将内核升级到 5.0 或更高版本。

文件和文件夹的缓慢枚举

原因

如果客户端计算机上没有足够的缓存用于大型目录，则可能会出现此问题。

解决方案

若要解决此问题，请调整 DirectoryCacheEntrySizeMax 注册表值以允许在客户端计算机中缓存更大的目录列表：

  • 位置： HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • 值名称： DirectoryCacheEntrySizeMax
  • 值类型：DWORD

例如，可以将它设置为 0x100000 并查看性能是否提高。

在 Azure 文件共享中复制文件的速度缓慢

尝试将文件传输到 Azure 文件存储 服务时，可能会看到性能降低。 如果没有特定的最小 I/O 大小要求，建议使用 1 MiB 作为 I/O 大小，以获得最佳性能。

在 Windows 中向和从Azure 文件存储复制文件的速度缓慢

  • 如果知道使用写入扩展的文件的最终大小，并且当文件上的未写入尾部包含零时，软件没有兼容性问题，请提前设置文件大小，而不是使每次写入都是扩展写入。

  • 使用正确的复制方法：

    • 使用 AzCopy 进行两个文件共享之间的任何传输。
    • 在本地计算机上的文件共享之间使用 Robocopy 。

过多的 DirectoryOpen/DirectoryClose 调用

原因

如果 DirectoryOpen/DirectoryClose 调用数是 API 调用中最多的，并且你不希望客户端进行这么多调用，则问题可能是由 Azure 客户端 VM 上安装的防病毒软件引起的。

解决方法

适用于 Windows 的 4 月平台更新中提供了此问题的修补程序。

未触发 SMB 多通道

原因

SMB 多通道配置设置的最新更改，无需重新装载。

解决方案

  • 对 Windows SMB 客户端或帐户 SMB 多通道配置设置进行任何更改后，必须卸载共享，等待 60 秒，然后重新装载共享以触发多通道。
  • 对于 Windows 客户端 OS，请生成队列深度较高的 IO 负载（例如 QD=8），例如复制文件以触发 SMB 多通道。 对于服务器 OS，SMB 多通道触发 QD=1，这意味着一旦启动共享的任何 IO。

解压缩文件时性能缓慢

根据所使用的确切压缩方法和解压缩操作，解压缩操作在 Azure 文件共享上的执行速度可能比在本地磁盘上执行的速度要慢。 这通常是因为解压缩工具在执行解压缩压缩存档的过程中会执行许多元数据操作。 为了获得最佳性能，建议将压缩的存档从 Azure 文件共享复制到本地磁盘，在此处解压缩，然后使用 Robocopy (或 AzCopy) 等复制工具复制回 Azure 文件共享。 使用 Robocopy 等复制工具可以通过使用多个线程并行复制数据来补偿Azure 文件存储中元数据操作相对于本地磁盘的性能下降。

文件共享上托管的网站上的高延迟

原因

文件共享上的高数量文件更改通知可能会导致高延迟。 这通常发生在具有深层嵌套目录结构的文件共享上托管的网站中。 典型的方案是 IIS 托管的 Web 应用程序，其中默认配置中的每个目录都设置了文件更改通知。 每次更改 (ReadDirectoryChangesW) 注册客户端的共享上都会将更改通知从文件服务推送到客户端，这会占用系统资源，并且问题会随着更改次数而恶化。 这可能会导致共享限制，从而导致更高的客户端延迟。

若要确认，可以在门户中使用 Azure 指标。

  1. 在Azure 门户，转到存储帐户。
  2. 在左侧菜单中的 “监视”下，选择“ 指标”。
  3. 选择“ 文件 ”作为存储帐户范围的指标命名空间。
  4. 选择“ 事务 ”作为指标。
  5. 为 ResponseType 和 检查添加筛选器，以查看是否有任何请求的响应代码SuccessWithThrottling为 SMB 或 NFS) 或 REST) ClientThrottlingError ( (。

解决方案

  • 如果未使用文件更改通知，请禁用首选) (文件更改通知。

  • 增加文件更改通知轮询间隔的频率以减少音量。

    将 W3WP 工作进程轮询间隔更新为更高的值 (例如，根据你的要求) 10 或 30 分钟。 在注册表中设置HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds并重启 W3WP 进程。

  • 如果网站的映射物理目录具有嵌套目录结构，则可以尝试限制文件更改通知的范围，以减少通知量。 默认情况下，IIS 使用虚拟目录映射到的物理目录 以及 该物理目录中任何子目录中Web.config文件中的配置。 如果不想在子目录中使用 Web.config 文件，请为allowSubDirConfig虚拟目录上的 属性指定 false 。 可 在此处找到更多详细信息。

    将Web.Config中的 IIS 虚拟目录allowSubDirConfig设置设置为 以false从范围中排除映射的物理子目录。

另请参阅

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。