Solución de problemas de rendimiento Azure Files

  • Artículo

Nota:

CentOS al que se hace referencia en este artículo es una distribución de Linux y llegará al final de la vida útil (EOL). Considere su uso y planifique en consecuencia. Para obtener más información, consulte Guía de fin de vida de CentOS.

En este artículo se enumeran los problemas comunes relacionados con el rendimiento del recurso compartido de archivos de Azure y se proporcionan posibles causas y soluciones alternativas. Para obtener el máximo valor de esta guía de solución de problemas, se recomienda leer primero Descripción Azure Files rendimiento.

Se aplica a

Tipo de recurso compartido de archivos SMB NFS
Recursos compartidos de archivos estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Solución de problemas generales de rendimiento

En primer lugar, descarte algunas razones comunes por las que podría tener problemas de rendimiento.

Está ejecutando un sistema operativo antiguo.

Si la máquina virtual cliente (VM) ejecuta Windows 8.1 o Windows Server 2012 R2, o un kernel o una distribución de Linux anterior, es posible que experimente problemas de rendimiento al acceder a recursos compartidos de archivos de Azure. Actualice el sistema operativo cliente o aplique las correcciones siguientes.

Consideraciones sobre Windows 8.1 y Windows Server 2012 R2

Es posible que los clientes que ejecutan Windows 8.1 o Windows Server 2012 R2 vean una latencia mayor de la esperada al acceder a recursos compartidos de archivos de Azure para cargas de trabajo intensivas de E/S. Asegúrese de que la revisión de KB3114025 está instalada. Esta revisión mejora el rendimiento de los identificadores de creación y cierre.

Puede ejecutar el siguiente script para comprobar si la revisión se ha instalado:

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

Si la revisión está instalada, se muestra la siguiente salida:

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

Nota:

Windows Server 2012 imágenes de R2 de Azure Marketplace tienen KB3114025 de revisiones instaladas de forma predeterminada, a partir de diciembre de 2015.

La carga de trabajo se está limitando

Las solicitudes se limitan cuando se alcanzan los límites de operaciones de E/S por segundo (IOPS), entrada o salida de un recurso compartido de archivos. Por ejemplo, si el cliente supera las IOPS de línea base, el servicio Azure Files lo limitará. La limitación puede dar lugar a que el cliente experimente un rendimiento deficiente.

Para comprender los límites de los recursos compartidos de archivos estándar y premium, consulte Destinos de escalado de archivos y recursos compartidos de archivos. En función de la carga de trabajo, a menudo se puede evitar la limitación al pasar de recursos compartidos de archivos de Azure estándar a premium.

Para obtener más información sobre cómo la limitación en el nivel de recurso compartido o en la cuenta de almacenamiento puede provocar problemas de latencia alta, bajo rendimiento y rendimiento general, consulte Uso compartido o cuenta de almacenamiento limitada.

Latencia alta, bajo rendimiento o baja IOPS

Causa 1: Se está limitando el uso compartido o la cuenta de almacenamiento

Para confirmar si se está limitando el recurso compartido o la cuenta de almacenamiento, puede acceder a las métricas de Azure y usarlas en el portal. También puede crear alertas que le notificarán si un recurso compartido se está limitando o está a punto de limitarse. Consulte Solución de problemas de Azure Files mediante la creación de alertas.

Importante

En el caso de las cuentas de almacenamiento estándar con recursos compartidos de archivos grandes (LFS) habilitados, la limitación se produce en el nivel de cuenta. Para los recursos compartidos de archivos premium y los recursos compartidos de archivos estándar sin LFS habilitado, la limitación se produce en el nivel de recurso compartido.

  1. En el Azure Portal, vaya a la cuenta de almacenamiento.

  2. En el panel izquierdo, en Supervisión, seleccione Métricas.

  3. Seleccione Archivo como espacio de nombres de métrica para el ámbito de la cuenta de almacenamiento.

  4. Seleccione Transacciones como métrica.

  5. Agregue un filtro para Tipo de respuesta y, a continuación, compruebe si se ha limitado alguna solicitud.

    En el caso de los recursos compartidos de archivos estándar que no tienen recursos compartidos de archivos grandes habilitados, se registran los siguientes tipos de respuesta si una solicitud está limitada en el nivel de recurso compartido:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    En el caso de los recursos compartidos de archivos estándar que tienen recursos compartidos de archivos grandes habilitados, se registran los siguientes tipos de respuesta si una solicitud está limitada en el nivel de cuenta de cliente:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    En el caso de los recursos compartidos de archivos premium, se registran los siguientes tipos de respuesta si una solicitud está limitada en el nivel de recurso compartido:

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

    Si se ha autenticado una solicitud limitada con Kerberos, es posible que vea un prefijo que indica el protocolo de autenticación, como:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Para obtener más información sobre cada tipo de respuesta, consulte Dimensiones de métricas.

    Captura de pantalla que muestra el filtro de propiedad

Solución

Causa 2: Carga de trabajo pesada de metadatos o espacio de nombres

Si la mayoría de las solicitudes están centradas en metadatos (como createfile, openfile, closefile, queryinfoo querydirectory), la latencia será peor que la de las operaciones de lectura y escritura.

Para determinar si la mayoría de las solicitudes están centradas en metadatos, comience siguiendo los pasos del 1 al 4, como se ha descrito anteriormente en la causa 1. En el paso 5, en lugar de agregar un filtro para Tipo de respuesta, agregue un filtro de propiedad para el nombre de la API.

Captura de pantalla que muestra el filtro de propiedad

Soluciones alternativas

  • Compruebe si la aplicación se puede modificar para reducir el número de operaciones de metadatos.

  • Si usa recursos compartidos de archivos de Azure SMB premium, use el almacenamiento en caché de metadatos.

  • Separe el recurso compartido de archivos en varios recursos compartidos de archivos dentro de la misma cuenta de almacenamiento.

  • Agregue un disco duro virtual (VHD) en el recurso compartido de archivos y monte el disco duro virtual desde el cliente para realizar operaciones de archivo en los datos. Este enfoque funciona para escenarios o escenarios de un solo escritor o lector con varios lectores y sin escritores. Dado que el sistema de archivos es propiedad del cliente en lugar de Azure Files, esto permite que las operaciones de metadatos sean locales. La configuración ofrece un rendimiento similar al del almacenamiento conectado directamente localmente. Sin embargo, dado que los datos están en un DISCO duro virtual, no se puede acceder a ellos a través de ningún otro medio que no sea el montaje smb, como la API REST o a través de la Azure Portal.

    1. Desde la máquina que necesita acceder al recurso compartido de archivos de Azure, monte el recurso compartido de archivos con la clave de cuenta de almacenamiento y asígnelo a una unidad de red disponible (por ejemplo, Z:).
    2. Vaya a Administración de discos y seleccione Acción > Create VHD.
    3. Establezca Ubicación en la unidad de red a la que está asignado el recurso compartido de archivos de Azure, establezca Tamaño del disco duro virtual según sea necesario y seleccione Tamaño fijo.
    4. Seleccione Aceptar. Una vez completada la creación del VHD, se montará automáticamente y aparecerá un nuevo disco sin asignar.
    5. Haga clic con el botón derecho en el nuevo disco desconocido y seleccione Inicializar disco.
    6. Haga clic con el botón derecho en el área sin asignar y cree un nuevo volumen simple.
    7. Debería ver que aparece una nueva letra de unidad en Administración de discos que representa este VHD con acceso de lectura y escritura (por ejemplo, E:). En Explorador de archivos, debería ver el nuevo VHD en la unidad de red del recurso compartido de archivos de Azure asignado (Z: en este ejemplo). Para ser claro, debe haber dos letras de unidad presentes: la asignación de red estándar del recurso compartido de archivos de Azure en Z:y la asignación de VHD en la unidad E:.
    8. Debería haber un rendimiento mucho mejor en las operaciones de metadatos pesadas en los archivos de la unidad asignada de VHD (E:) frente a la unidad asignada del recurso compartido de archivos de Azure (Z:). Si lo desea, debe ser posible desconectar la unidad de red asignada (Z:) y seguir teniendo acceso a la unidad vhd montada (E:).
    • Para montar un VHD en un cliente Windows, también puede usar el Mount-DiskImage cmdlet de PowerShell.
    • Para montar un disco duro virtual en Linux, consulte la documentación de la distribución de Linux. Este es un ejemplo.

Causa 3: Aplicación de un solo subproceso

Si la aplicación que usa es de un solo subproceso, esta configuración puede dar lugar a un rendimiento de IOPS significativamente menor que el rendimiento máximo posible, en función del tamaño del recurso compartido aprovisionado.

Solución

  • Aumente el paralelismo de la aplicación aumentando el número de subprocesos.
  • Cambie a aplicaciones donde sea posible el paralelismo. Por ejemplo, para las operaciones de copia, puede usar AzCopy o RoboCopy de clientes Windows o el comando paralelo de clientes Linux.

Causa 4: El número de canales SMB supera los cuatro

Si usa SMB multicanal y el número de canales que tiene supera los cuatro, esto provocará un rendimiento deficiente. Para determinar si el recuento de conexiones supera los cuatro, use el cmdlet get-SmbClientConfiguration de PowerShell para ver la configuración actual del recuento de conexiones.

Solución

Establezca la configuración de Windows por NIC para SMB para que el total de canales no supere los cuatro. Por ejemplo, si tiene dos NIC, puede establecer el máximo por NIC en dos mediante el siguiente cmdlet de PowerShell: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Causa 5: El tamaño de lectura anticipada es demasiado pequeño (solo NFS)

A partir de la versión 5.4 del kernel de Linux, el cliente NFS de Linux usa un valor predeterminado read_ahead_kb de 128 kibibytes (KiB). Este pequeño valor podría reducir la cantidad de rendimiento de lectura de archivos grandes.

Solución

Se recomienda aumentar el valor del parámetro kernel read_ahead_kb a 15 mebibytes (MiB). Para cambiar este valor, establezca el tamaño de lectura anticipada de forma persistente agregando una regla en udev, un administrador de dispositivos de kernel de Linux. Siga estos pasos:

  1. En un editor de texto, cree el archivo /etc/udev/rules.d/99-nfs.rules escribiendo y guardando el texto siguiente:

    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. En una consola, aplique la regla udev ejecutando el comando udevadm como superusuario y volviendo a cargar los archivos de reglas y otras bases de datos. Para que udev tenga en cuenta el nuevo archivo, solo tiene que ejecutar este comando una vez.

    sudo udevadm control --reload

Latencia muy alta para las solicitudes

Causa

La máquina virtual cliente podría encontrarse en una región diferente al recurso compartido de archivos. Otra razón para una latencia alta podría deberse a la latencia causada por el cliente o la red.

Solución

  • Ejecute la aplicación desde una máquina virtual que se encuentre en la misma región que el recurso compartido de archivos.
  • Para la cuenta de almacenamiento, revise las métricas de transacción SuccessE2ELatency y SuccessServerLatency mediante Azure Monitor en Azure Portal. Una diferencia alta entre los valores de métricas SuccessE2ELatency y SuccessServerLatency es una indicación de latencia que probablemente se debe a la red o al cliente. Consulte Métricas de transacciones en Azure Files Referencia de datos de supervisión.

El cliente no puede lograr el rendimiento máximo admitido por la red

Causa

Una posible causa es la falta de compatibilidad multicanal smb para recursos compartidos de archivos estándar. Actualmente, Azure Files solo admite un solo canal para recursos compartidos de archivos estándar, por lo que solo hay una conexión desde la máquina virtual cliente al servidor. Esta única conexión se fija a un único núcleo en la máquina virtual cliente, por lo que el rendimiento máximo posible de una máquina virtual está enlazado por un único núcleo.

Solución alternativa

Rendimiento lento en un recurso compartido de archivos de Azure montado en una máquina virtual Linux

Causa 1: Almacenamiento en caché

Una posible causa del rendimiento lento es el almacenamiento en caché deshabilitado. El almacenamiento en caché puede ser útil si tiene acceso a un archivo repetidamente. De lo contrario, puede ser una sobrecarga. Compruebe si usa la memoria caché antes de deshabilitarla.

Solución para la causa 1

Para comprobar si el almacenamiento en caché está deshabilitado, busque la cache= entrada.

Cache=none indica que el almacenamiento en caché está deshabilitado. Vuelva a montar el recurso compartido mediante el comando de montaje predeterminado o agregando explícitamente la cache=strict opción al comando mount para asegurarse de que el modo de almacenamiento en caché predeterminado o el modo de almacenamiento en caché "estricto" está habilitado.

En algunos escenarios, la serverino opción de montaje puede hacer que el ls comando se ejecute stat en cada entrada de directorio. Este comportamiento produce una degradación del rendimiento al enumerar un directorio grande. Puede comprobar las opciones de montaje en la entrada /etc/fstab :

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

También puede comprobar si se usan las opciones correctas ejecutando el sudo mount | grep cifs comando y comprobando su salida. A continuación se muestra una salida de ejemplo:

//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)

Si la cache=strict opción o serverino no está presente, vuelva a desmontar y montar Azure Files ejecutando el comando mount desde la documentación. A continuación, vuelva a comprobar que la entrada /etc/fstab tiene las opciones correctas.

Causa 2: Limitación

Es posible que esté experimentando una limitación y que las solicitudes se envíen a una cola. Para comprobarlo, aproveche las métricas de Azure Storage en Azure Monitor. También puede crear alertas que le notifiquen si un recurso compartido se está limitando o está a punto de limitarse. Consulte Solución de problemas de Azure Files mediante la creación de alertas.

Solución para la causa 2

Asegúrese de que la aplicación está dentro de los destinos de escala de Azure Files. Si usa recursos compartidos de archivos de Azure estándar, considere la posibilidad de cambiar a Premium.

El rendimiento en los clientes Linux es menor que el de los clientes de Windows.

Causa

Se trata de un problema conocido con la implementación del cliente SMB en Linux.

Solución alternativa

  • Distribuya la carga entre varias máquinas virtuales.
  • En la misma máquina virtual, use varios puntos de montaje con una nosharesock opción y distribuya la carga entre estos puntos de montaje.
  • En Linux, intente montar con una nostrictsync opción para evitar forzar un vaciado smb en cada fsync llamada. Para Azure Files, esta opción no interfiere con la coherencia de los datos, pero podría dar lugar a metadatos de archivo obsoletos en listas de directorios (ls -l comando). Consultar directamente los metadatos de archivo mediante el stat comando devolverá los metadatos de archivo más actualizados.

Latencias elevadas para cargas de trabajo con muchos metadatos que implican amplias operaciones abiertas o cerradas

Causa

Falta de compatibilidad con las concesiones de directorio.

Solución alternativa

  • Si es posible, evite usar un identificador de apertura y cierre excesivo en el mismo directorio en un breve período de tiempo.
  • En el caso de las máquinas virtuales Linux, aumente el tiempo de espera de caché de entrada de directorio especificando actimeo=<sec> como una opción de montaje. De forma predeterminada, el tiempo de espera es de 1 segundo, por lo que un valor mayor, como 30 segundos, podría ayudar.
  • En el caso de las máquinas virtuales CentOS Linux o Red Hat Enterprise Linux (RHEL), actualice el sistema a CentOS Linux 8.2 o RHEL 8.2. Para otras distribuciones de Linux, actualice el kernel a la versión 5.0 o posterior.

Enumeración lenta de archivos y carpetas

Causa

Este problema puede producirse si no hay suficiente memoria caché en el equipo cliente para directorios grandes.

Solución

Para resolver este problema, ajuste el valor del Registro para permitir el DirectoryCacheEntrySizeMax almacenamiento en caché de listas de directorios más grandes en el equipo cliente:

  • Ubicación: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Nombre del valor: DirectoryCacheEntrySizeMax
  • Tipo de valor: DWORD

Por ejemplo, puede establecerlo en 0x100000 y ver si el rendimiento mejora.

Copia lenta de archivos hacia y desde recursos compartidos de archivos de Azure

Es posible que vea un rendimiento lento al intentar transferir archivos al servicio de Azure Files. Si no tiene un requisito de tamaño mínimo de E/S específico, se recomienda usar 1 MiB como tamaño de E/S para un rendimiento óptimo.

Copia lenta de archivos hacia y desde Azure Files en Windows

  • Si conoce el tamaño final de un archivo que está ampliando con escrituras y el software no tiene problemas de compatibilidad cuando la cola no escrita del archivo contiene ceros, establezca el tamaño del archivo de antemano en lugar de hacer que cada escritura sea una escritura extensible.

  • Use el método de copia correcto:

    • Use AzCopy para cualquier transferencia entre dos recursos compartidos de archivos.
    • Use Robocopy entre recursos compartidos de archivos en un equipo local.

Excesivas llamadas DirectoryOpen/DirectoryClose

Causa

Si el número de llamadas DirectoryOpen/DirectoryClose se encuentra entre las principales llamadas API y no espera que el cliente realice tantas llamadas, el problema podría deberse al software antivirus instalado en la máquina virtual cliente de Azure.

Solución alternativa

Hay una corrección para este problema disponible en la actualización de la plataforma de abril para Windows.

SMB multicanal no se está desencadenando

Causa

Cambios recientes en la configuración multicanal de SMB sin volver a montar.

Solución

  • Después de realizar cambios en la configuración multicanal del cliente SMB de Windows o de la cuenta SMB, debe desmontar el recurso compartido, esperar 60 segundos y volver a montar el recurso compartido para desencadenar el multicanal.
  • En el caso del sistema operativo cliente Windows, genere carga de E/S con una profundidad de cola elevada, por ejemplo, QD=8, por ejemplo, copiando un archivo para desencadenar SMB multicanal. Para el sistema operativo del servidor, SMB multicanal se desencadena con QD=1, lo que significa que en cuanto se inicia cualquier E/S en el recurso compartido.

Rendimiento lento al descomprimir archivos

Según el método de compresión exacto y la operación de descompresión utilizada, las operaciones de descompresión pueden funcionar más lentamente en un recurso compartido de archivos de Azure que en el disco local. Esto suele deberse a que las herramientas de descompresión realizan varias operaciones de metadatos en el proceso de realizar la descompresión de un archivo comprimido. Para obtener el mejor rendimiento, se recomienda copiar el archivo comprimido del recurso compartido de archivos de Azure en el disco local, descomprimirlo allí y, a continuación, usar una herramienta de copia como Robocopy (o AzCopy) para copiar de nuevo en el recurso compartido de archivos de Azure. El uso de una herramienta de copia como Robocopy puede compensar el menor rendimiento de las operaciones de metadatos en Azure Files en relación con el disco local mediante el uso de varios subprocesos para copiar datos en paralelo.

Alta latencia en sitios web hospedados en recursos compartidos de archivos

Causa

La notificación de cambio de archivo de número alto en los recursos compartidos de archivos puede dar lugar a latencias altas. Esto suele ocurrir con sitios web hospedados en recursos compartidos de archivos con una estructura de directorios anidada profunda. Un escenario típico es la aplicación web hospedada en IIS, donde la notificación de cambio de archivo está configurada para cada directorio en la configuración predeterminada. Cada cambio (ReadDirectoryChangesW) en el recurso compartido para el que está registrado el cliente inserta una notificación de cambio del servicio de archivos al cliente, que toma los recursos del sistema, y el problema empeora con el número de cambios. Esto puede provocar una limitación de recursos compartidos y, por tanto, provocar una mayor latencia del lado cliente.

Para confirmarlo, puede usar métricas de Azure en el portal.

  1. En el Azure Portal, vaya a la cuenta de almacenamiento.
  2. En el menú de la izquierda, en Supervisión, seleccione Métricas.
  3. Seleccione Archivo como espacio de nombres de métrica para el ámbito de la cuenta de almacenamiento.
  4. Seleccione Transacciones como métrica.
  5. Agregue un filtro para ResponseType y compruebe si alguna solicitud tiene un código de respuesta de SuccessWithThrottling (para SMB o NFS) o ClientThrottlingError (para REST).

Solución

  • Si no se usa la notificación de cambio de archivo, deshabilite la notificación de cambio de archivo (preferida).

  • Aumente la frecuencia del intervalo de sondeo de notificaciones de cambio de archivo para reducir el volumen.

    Actualice el intervalo de sondeo del proceso de trabajo W3WP a un valor mayor (por ejemplo, 10 o 30 minutos) según sus necesidades. Establezca HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSecondsen el registro y reinicie el proceso W3WP.

  • Si el directorio físico asignado del sitio web tiene una estructura de directorios anidada, puede intentar limitar el ámbito de las notificaciones de cambio de archivo para reducir el volumen de notificaciones. De forma predeterminada, IIS usa la configuración de Web.config archivos en el directorio físico al que está asignado el directorio virtual, así como en cualquier directorio secundario de ese directorio físico. Si no desea usar Web.config archivos en directorios secundarios, especifique false para el allowSubDirConfig atributo en el directorio virtual. Puede encontrar más detalles aquí.

    Establezca la configuración del directorio allowSubDirConfig virtual de IIS en Web.Config para false excluir los directorios secundarios físicos asignados del ámbito.

Consulte también

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.