Compartir a través de

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 compartición de archivos SMB NFS
Comparticiones de archivos estándar (GPv2), LRS/ZRS
Comparticiones 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 corrección puntual mejora el rendimiento de la creación y el cierre de identificadores.

Puede ejecutar el siguiente script para comprobar si se ha instalado la actualización rápida.

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

Si el hotfix está instalado, se muestra la siguiente salida:

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.

La carga de trabajo está siendo limitada.

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 limitada.

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 a nivel de cuenta de almacenamiento. En el caso de los recursos compartidos de archivos Premium, la limitación se produce a 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 File como el espacio de nombres de métricas 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.

    Para los recursos compartidos de archivos estándar, se registran los siguientes tipos de respuesta si se limita una solicitud al nivel de la cuenta del cliente:

    • ErrorDeRalentizaciónDeSolicitudDeCuentaDeCliente
    • Error de limitación de ancho de banda de cuenta de cliente

    Si se limita una solicitud a nivel de compartición en las comparticiones de archivos premium, se registran los siguientes tipos de respuesta:

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • ÉxitoConLimitaciónDeIOPSCompartido
    • Error de limitación de salida de ClientShare
    • Error de limitación de entrada de ClientShare
    • ClientShareIopsThrottlingError

    Si se ha autenticado una solicitud restringida con Kerberos, es posible que pueda ver un prefijo que indica el método de autenticación, como:

    • Éxito de Kerberos con Limitación de Salida Compartida
    • 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 pesada de trabajo de metadatos o espacio de nombres

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 los recursos compartidos de archivos de Azure SMB Premium, use el almacenamiento en caché de metadatos.

  • Separe la compartición de archivos en varias comparticiones de archivos dentro de la misma cuenta de almacenamiento.

  • Agregue un disco duro virtual (VHD) al recurso compartido de archivos y móntelo desde el cliente para realizar operaciones de archivos con 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, dado que los datos están en un VHD, no se puede acceder a ellos por ningún otro medio que no sea el montaje SMB, ni mediante la API REST ni a través del portal de Azure.

    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 VHD.
    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 no asignado.
    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. Debería haber un rendimiento mucho mejor en las operaciones intensivas de metadatos sobre archivos de la unidad de disco (E:) asignada a VHD, frente a la unidad de disco (Z:) asignada al recurso compartido de archivos de Azure. 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 VHD (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 solo hilo

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

Configure la opción "Ventanas por NIC" (Windows per 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 monitorizació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 tiene que obtener acceso repetidamente a un archivo. De lo contrario, puede producirse una sobrecarga. Compruebe si está usando la memoria caché antes de deshabilitarla.

Solución para la causa 1

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

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 opción cache=strict al comando de montaje con el fin de asegurarse de que el almacenamiento en caché predeterminado o el modo de almacenamiento en caché "strict" esté habilitado.

En algunos escenarios, la opción de montaje serverino puede hacer que el comando ls 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 comando sudo mount | grep cifs 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 no está presente la opción cache=strict o serverino, desmonte y vuelva a montar Azure Files ejecutando el comando de montaje 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 experimente limitaciones y que las solicitudes se envíen a una cola. Puede comprobarlo aprovechando las métricas de Azure Storage en Azure Monitor. También puede crear alertas que le notifican 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.

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.

Causa 3: El recurso compartido de archivos de Azure alcanza la capacidad

Si el recurso compartido de archivos de Azure está cerca de alcanzar su capacidad, un paso importante es identificar los archivos y directorios más grandes para optimizar el almacenamiento. Este paso le ayuda a comprender qué archivos y carpetas usan más espacio.

Solución alternativa

Para obtener una vista completa del uso del almacenamiento en todo el recurso compartido, monte la raíz del recurso compartido. Esta acción permite una inspección exhaustiva de los tamaños de archivo y directorio. En la raíz del recurso compartido de archivos, ejecute los siguientes comandos para identificar los archivos y directorios más grandes:

	cd /path/to/mount/point
	du -ah --max-depth=1 | sort -rh | head -n 20

Este comando muestra los 20 archivos y directorios más grandes en orden descendente de tamaño. Esta pantalla proporciona una visión general clara del consumo de almacenamiento.

Si no puede montar la raíz del recurso compartido, use el Explorador de Azure Storage o una herramienta de terceros para analizar el uso del almacenamiento. Estas herramientas proporcionan una visión similar de los tamaños de archivos y directorios, sin que sea necesario montar el recurso compartido.

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

Causa

Se trata de un problema conocido que afecta a 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 que tengan una nosharesock opción y propague la carga entre estos puntos de montaje.
  • En sistemas Linux, intente montar utilizando la opción nostrictsync para evitar tener que vaciar SMB en cada llamada de fsync. Para Azure Files, esta opción no interfiere con la coherencia de los datos, pero puede provocar metadatos de archivo obsoletos en listados de directorios (ls -l comando). La consulta directa de los metadatos de archivo mediante el comando stat devuelve los metadatos de archivo más up-to-date.

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

Causa

Falta de soporte para los arrendamientos de directorios.

Solución alternativa

  • Si es posible, evite usar excesivamente un controlador de apertura/cierre en el mismo directorio en un breve periodo de tiempo.
  • 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

Este problema puede producirse si no hay suficiente memoria o caché en la máquina cliente para directorios grandes.

Para resolver este problema, ajuste el valor del Registro DirectoryCacheEntrySizeMax para permitir almacenar en caché listados de directorios más grandes en la máquina 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 está ampliando mediante operaciones de escritura y el software no presenta problemas de compatibilidad cuando la cola no escrita del archivo contiene ceros, establezca el tamaño de archivo con antelación en lugar de hacer que cada escritura sea una escritura de ampliación.

  • 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 en un equipo local.

Excesivas llamadas a 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 necesidad de 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\ConfigPollMilliSecondsen 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.