Compartir vía

Solucionar problemas de rendimiento de 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 del ciclo de vida (EOL). Tenga en cuenta 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 problemas comunes relacionados con el rendimiento de los recursos compartidos de archivos de Azure y se proporcionan posibles causas y soluciones alternativas. Para sacar el máximo partido de esta guía de solución de problemas, se recomienda leer primero Descripción del rendimiento de Azure Files.

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 es posible que tenga problemas de rendimiento.

Está ejecutando un sistema operativo antiguo.

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

Consideraciones para Windows 8.1 y Windows Server 2012 R2

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

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

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

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

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

Nota:

Las imágenes de Windows Server 2012 R2 de Azure Marketplace tienen la revisión KB3114025 instalada de manera predeterminada desde diciembre de 2015.

Se está limitando su carga de trabajo

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

Para conocer los límites de los recursos compartidos de archivos de nivel Estándar y Premium, consulte Objetivos de escalabilidad de archivos y recursos compartidos de archivos. En función de la carga de trabajo, a menudo se puede evitar la limitación pasando 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 el nivel de cuenta de almacenamiento puede provocar alta latencia, bajo rendimiento y problemas de rendimiento generales, consulte Limitación de la cuenta de almacenamiento o recurso compartido.

Latencia alta, bajo rendimiento o IOPS bajas

Causa 1: La cuenta de almacenamiento o recurso compartido está siendo limitando

Para confirmar si se está limitando el recurso compartido o la cuenta de almacenamiento, puede acceder y usar las métricas de Azure en el portal. También puede crear alertas que le notificarán si un recurso compartido está limitado 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, la limitación se produce en el nivel de cuenta de almacenamiento. En el caso de los recursos compartidos de archivos Premium, la limitación se produce en el nivel de recurso compartido.

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

  2. En el panel de la izquierda, en Supervisión, seleccione Métricas.

  3. Seleccione Archivo como el espacio de nombres de la 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, luego, compruebe si se ha limitado alguna solicitud.

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

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Si se limita una solicitud en los recursos compartidos de archivos prémium, se registran los siguientes tipos de respuesta:

    • 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 más información sobre cada tipo de respuesta, consulte Dimensiones de métricas.

    Captura de pantalla que muestra el filtro de propiedades

Solución

Si usa un recurso compartido de archivos Premium, aumente el tamaño del recurso compartido de archivos aprovisionado para aumentar el límite de IOPS. Para más información, consulte Descripción del aprovisionamiento de recursos compartidos de archivos premium.

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

Si la mayoría de las solicitudes se centran en metadatos (como createfile, openfile, closefile, queryinfo o querydirectory), la latencia será peor en comparación con las operaciones de lectura y escritura.

Para determinar si la mayoría de las solicitudes están centradas en los metadatos, empiece por 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 Nombre de 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) al recurso compartido de archivos y móntelo a través desde el cliente para realizar operaciones de archivos en los datos. Este enfoque funciona para escenarios de escritor o lector único o escenarios con varios lectores y sin escritores. Dado que el sistema de archivos es propiedad del cliente y no de Azure Files, esto permite que las operaciones de metadatos sean locales. La configuración ofrece un rendimiento similar al de un almacenamiento con conexión directa local. Sin embargo, como los datos están en un disco duro virtual, solo se puede acceder a ellos a través del montaje de SMB, como la API REST o a través de Azure Portal.

    1. Desde la máquina que necesite acceder al recurso compartido de archivos de Azure, monte el recurso compartido de archivos mediante la clave de la 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 > Crear disco duro virtual.
    3. Establezca en Ubicación la unidad de red a la que está asignado el recurso compartido de archivos de Azure, establezca el valor de Tamaño del disco duro virtual que sea necesario y seleccione Tamaño fijo.
    4. Seleccione Aceptar. Una vez completada la creación del disco duro virtual, 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 en Administración de discos aparece una nueva letra de unidad que representa este disco duro virtual con acceso de lectura y escritura (por ejemplo, E:). En el Explorador de archivos, debería ver el nuevo disco duro virtual en la unidad de red del recurso compartido de archivos de Azure asignado (Z: en este ejemplo). Para que quede claro, debe haber dos letras de unidad presentes: la asignación de red del recurso compartido de archivos de Azure estándar en Z:y la asignación del disco duro virtual en la unidad E:.
    8. Debe haber un rendimiento mucho mejor en las operaciones de metadatos intensivas en archivos de la unidad asignada del disco duro virtual (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 accediendo a la unidad de disco duro virtual montada (E:).
    • Para montar un disco duro virtual en un cliente de Windows, también puede usar el cmdlet de PowerShell Mount-DiskImage.
    • 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 único subproceso

Si la aplicación que usa tiene un único subproceso, esta configuración puede dar lugar a un rendimiento de IOPS significativamente menor que el 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 en las que el paralelismo sea posible. Por ejemplo, para las operaciones de copia, podría usar AzCopy o RoboCopy desde clientes de Windows o el comando parallel en los clientes de Linux.

Causa 4: El número de canales SMB es superior a 4

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

Solución

Establezca el valor Windows per NIC (Ventanas por NIC) de 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 valor pequeño puede reducir la cantidad de rendimiento de lectura para archivos grandes.

Solución

Se recomienda aumentar el valor del read_ahead_kb parámetro kernel 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 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 vuelva a cargar los archivos de reglas y otras bases de datos. Para que udev conozca 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 del cliente podría encontrarse en una región diferente de la del recurso compartido de archivos. Otro motivo por el que la latencia es alta podría ser por 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.
  • En la cuenta de almacenamiento, revise las métricas de transacción SuccessE2ELatency y SuccessServerLatency a través de Azure Monitor en Azure Portal. Si hay una gran diferencia entre las métricas SuccessE2ELatency y SuccessServerLatency, significa que probablemente la latencia es debido a la red y el cliente. Consulte Métricas de transacción en la referencia de datos de supervisión de Azure Files.

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

Causa

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

Solución alternativa

Rendimiento lento en un recurso compartido de archivos de Azure montado en una VM de Linux

Causa 1: Almacenamiento en memoria caché

Una posible causa de un rendimiento lento es que el almacenamiento en caché está deshabilitado. El almacenamiento en caché puede ser útil si está accediendo 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 "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 cuando se muestra un listado de 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 un resultado 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, desmonte y monte Azure Files de nuevo mediante la ejecución del comando mount desde la documentación. A continuación, vuelva a comprobar que la entrada /etc/fstab tiene las opciones correctas.

Causa 2: Limitaciones

Es posible que esté experimentando una limitación y las solicitudes se envían a una cola. Puede comprobarlo aprovechando las métricas de Azure Storage en Azure Monitor. También puede crear alertas que le notifiquen si se está limitando un recurso compartido 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 objetivos de escalabilidad 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 de 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

  • Distribuir la carga entre varias máquinas virtuales.
  • En la misma máquina virtual, use varios puntos de montaje con la opción nosharesock y propague la carga entre estos puntos de montaje.
  • En Linux, intente montar una opción nostrictsync para evitar forzar un vaciado de SMB en cada llamada a fsync. Para Azure Files, esta opción no afecta a la coherencia de los datos, pero puede producir metadatos de archivos obsoletos en la lista de directorios (comando ls -l). La consulta directa de metadatos de archivo mediante el comando stat devolverá los metadatos de archivo más recientes.

Latencias altas para cargas de trabajo con muchos metadatos que implican operaciones de apertura y cierre extensas

Causa

Falta de compatibilidad para las concesiones de directorios.

Solución alternativa

  • Si es posible, evite usar aperturas o cierres excesivos en el mismo directorio en un período de tiempo breve.
  • Para las máquinas virtuales de Linux, aumente el tiempo de espera de caché de entrada de directorio especificando actimeo=<sec> como 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 de CentOS Linux o Red Hat Enterprise Linux (RHEL), actualice el sistema a CentOS Linux 8.2 o RHEL 8.2. En cuanto a las distribuciones de Linux, actualice el kernel a 5.0 o una versión posterior.

Enumeración lenta de archivos y carpetas

Causa

Este problema puede producirse si no hay suficiente memoria caché en la máquina 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 de valor: DirectoryCacheEntrySizeMax
  • Tipo de valor: DWORD

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

Copia de archivos lenta en recursos compartidos de archivos de Azure y desde ellos

Puede que experimente un rendimiento lento cuando intente transferir archivos al servicio Azure Files. Si no tiene un requisito mínimo de tamaño de E/S específico, se recomienda que use 1 MiB como tamaño de E/S para disfrutar de un rendimiento óptimo.

Lentitud al copiar archivos a y desde Azure Files en Windows

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

  • Utilice el método de copia correcto:

    • Use AzCopy para todas las transferencias entre dos recursos compartidos de archivos.
    • Utilice Robocopy entre recursos compartidos de archivos y un equipo local.

Exceso de llamadas DirectoryOpen/DirectoryClose

Causa

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

Solución alternativa

La Actualización de la plataforma para Windows de abril incluye una corrección para este problema.

No se desencadena SMB multicanal.

Causa

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

Solución

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

Rendimiento lento al descomprimir archivos

Según el método de compresión exacto y la operación de descomprimir usada, las operaciones de descompresión pueden realizarse 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 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 copiarlo de nuevo al recurso compartido de archivos de Azure. Usar una herramienta de copia como Robocopy puede compensar el rendimiento reducido de las operaciones de metadatos en Azure Files con respecto al disco local mediante varios hilos para copiar datos en paralelo.

Alta latencia en sitios web hospedados en recursos compartidos de archivos

Causa

La notificación de cambio de un número alto de archivos en recursos compartidos de archivos puede producir 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 se configura la notificación de cambio de archivos para cada directorio en la configuración predeterminada. Cada cambio (ReadDirectoryChangesW) en el recurso compartido en el que está registrado el cliente envía una notificación de cambio desde el servicio de archivos al cliente, que usa recursos del sistema, y el problema empeora con el número de cambios. Esto puede dar lugar a una limitación de recursos compartidos y, por tanto, a una mayor latencia del lado cliente.

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

  1. En 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 el espacio de nombres de la 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 (preferido).

  • Aumente la frecuencia del intervalo de sondeo de notificación de cambio de archivo para reducir el volumen.

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

  • Si el directorio físico asignado del sitio web tiene una estructura de directorio 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 los archivos Web.config en el directorio físico al que se asigna el directorio virtual, así como en los directorios secundarios de ese directorio físico. Si no desea usar archivos Web.config en directorios secundarios, especifique false para el allowSubDirConfig atributo en el directorio virtual. Se pueden 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.