Solución de problemas de rendimiento de Azure Files

Se aplica a: ✔️ recursos compartidos de archivos de Azure SMB y NFS

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 obtener el máximo valor de esta guía de solución de problemas, lea primero Understand Azure Files rendimiento.

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 se 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 cliente o aplique las correcciones de la sección siguiente.

Se ha limitado la carga de trabajo

El sistema limita las solicitudes 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 limita. La limitación de velocidad puede hacer que el cliente tenga 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 puede evitar la limitación del rendimiento pasando de recursos compartidos de archivos HDD (estándar) a recursos compartidos de archivos SSD (premium).

Para obtener más información sobre cómo la limitación a nivel de recurso compartido o de cuenta de almacenamiento puede provocar una latencia alta, un bajo rendimiento y problemas generales de rendimiento, consulte Se está limitando el recurso compartido o la cuenta de almacenamiento.

Latencia alta, bajo rendimiento o IOPS bajas

Causa 1: El recurso compartido o la cuenta de almacenamiento está limitada

Para confirmar si el recurso compartido o la cuenta de almacenamiento se está limitando, acceda a las métricas de Azure en el portal y utilícelas. También puede crear alertas que le notifiquen si un recurso compartido está limitado o está a punto de limitarse. Para obtener más información, consulte Solución de problemas de Azure Files mediante la creación de alertas.

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 compruebe si se limitan las solicitudes.

   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
   • Éxito con el Control de Ancho de Banda de Ingreso Compartido
   • ÉxitoConLimitaciónDeIOPSCompartido
   • Error de limitación de salida de ClientShare
   • Error de limitación de entrada de ClientShare
   • ClientShareIopsThrottlingError

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

   • Éxito de Kerberos con Limitación de Salida Compartida
   • KerberosÉxitoConLimitaciónDeIngresoDeCompartir

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

   

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 son operaciones centradas en metadatos, como createfile, openfile, closefile, queryinfoo querydirectory, puede experimentar una mayor latencia en comparación con las operaciones de lectura y escritura.

Para comprobar si la mayoría de las solicitudes están centradas en metadatos, siga los pasos 1 a 4 como se describe en 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. Para obtener más información, consulte Supervisión del uso por IOPS de metadatos.

Soluciones alternativas

• Compruebe si puede modificar la aplicación 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 en lugar de Azure Files, las operaciones de metadatos son 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, como mediante la API REST o el portal de Azure. 1. Desde la máquina que necesita acceder al recurso compartido de archivos de Azure, monte el recurso compartido y asígnelo a una unidad de red disponible (por ejemplo, Z:).

  1. Vaya a Administración de discos y seleccione Acción > Crear VHD.
  2. 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.
  3. Seleccione Aceptar. Cuando finaliza la creación del disco duro virtual, se monta automáticamente y aparece un nuevo disco sin asignar.
  4. Haga clic con el botón derecho en el nuevo disco desconocido y seleccione Inicializar disco.
  5. Haga clic con el botón derecho en el área sin asignar y cree un nuevo volumen simple.
     1. Verá que aparece una nueva letra de unidad en Administración de discos que representa este disco duro virtual con acceso de lectura y escritura (por ejemplo, E:). En el Explorador de archivos, verá el nuevo VHD en la unidad de red del recurso compartido de archivos asignado Azure (Z: en este ejemplo). Para estar claro, hay dos letras de unidad presentes: la asignación de red de recursos compartidos de archivos estándar Azure en Z:y la asignación de VHD en la unidad E: .
     2. Se obtiene un rendimiento mucho mejor en las operaciones intensivas de metadatos sobre archivos de la unidad asignada al VHD (E:) en comparación con la unidad asignada al recurso compartido de archivos de Azure (Z:). Si lo desea, puede 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 MultiChannel y el número de canales que tiene supera los cuatro, esta condición da como resultado un rendimiento 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

Aumente 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

Es posible que la máquina virtual cliente se encuentre en una región diferente del recurso compartido de archivos. Otras razones de latencia alta incluyen 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 a través de Azure Monitor en Azure portal. Una diferencia alta entre los valores de métricas SuccessE2ELatency y SuccessServerLatency indica la latencia que es probable que se deba a la red o al 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 falta de compatibilidad multicanal de SMB con 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 única conexión usa un único núcleo en la máquina virtual cliente, por lo que el rendimiento máximo que se puede lograr desde una máquina virtual está limitado por un único núcleo.

Solución alternativa

• En el caso de los recursos compartidos de archivos premium, habilite SMB multicanal.
• Una máquina virtual con más núcleos podría mejorar el rendimiento.
• La ejecución de la aplicación cliente desde varias máquinas virtuales aumenta el rendimiento.
• Siempre que sea posible, use las API de REST.
• Para los recursos compartidos de archivos NFS de Azure, use nconnect. Consulta Mejora el rendimiento de la compartición de archivos NFS de Azure con nconnect.

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 accede a un archivo repetidamente. 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

Este problema se produce debido a cómo se implementa el 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

• Evite abrir y cerrar excesivamente el mismo directorio en poco 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 la máquina cliente no tiene suficiente memoria o caché para directorios grandes.

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 específico de tamaño mínimo de E/S, use 1 MiB como tamaño de E/S para obtener un rendimiento óptimo.

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

Actualice la plataforma antimalware de Microsoft Defender Antivirus. Descargue las actualizaciones de Microsoft Update Catalog.

SMB Multichannel no se activa

Causa

Cambios recientes en la configuración multicanal de SMB del cliente o la cuenta de Windows, sin volver a montar.

Solución

• Después de realizar cualquier cambio en la configuración de multicanal SMB del cliente de Windows o de la cuenta, desmonte el recurso compartido, espere 60 segundos y vuelva a montar el recurso compartido para activar el multicanal.
• Para el sistema operativo cliente de Windows, genere una carga de E/S con una profundidad de cola alta, como QD=8, por ejemplo, copiando un archivo para activar 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 funcionar más lentamente en un recurso compartido de archivos de Azure que en el disco local. Este rendimiento más lento suele ocurrir porque las herramientas de descomprimir realizan varias operaciones de metadatos en el proceso de realizar la descompresión de un archivo comprimido. Para obtener el mejor rendimiento, copie el archivo comprimido del recurso compartido de archivos Azure en el disco local, descomprima allí y, a continuación, use una herramienta de copia como Robocopy (o AzCopy) para copiarlo de nuevo en el recurso compartido de Azure Files. Mediante el uso de varios subprocesos para copiar datos en paralelo, una herramienta de copia como Robocopy puede compensar el rendimiento reducido de las operaciones de metadatos en Azure Files en relación con el disco local.

Alta latencia en sitios web hospedados en recursos compartidos de archivos

Causa

Un gran número de notificaciones de cambio de archivos en recursos compartidos de archivos puede dar lugar a latencias elevadas. Este problema suele producirse con sitios web hospedados en recursos compartidos de archivos que tienen una estructura de directorio anidada profunda. Un escenario común es una aplicación web hospedada en IIS donde cada directorio de la configuración predeterminada configura una notificación de cambio de archivo. Cada cambio (ReadDirectoryChangesW) en el recurso compartido para el que el cliente se registra provoca que el servicio de archivos envíe una notificación de cambio al cliente. Este proceso toma recursos del sistema y el problema empeora con el número de cambios. Esta condición puede provocar una limitación de recursos compartidos y, por tanto, da lugar a una mayor latencia del lado cliente.

Para confirmarlo, use Azure Métricas 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 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 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 usa la notificación de cambio de archivo, deshabilite (preferido).

  • Deshabilite la notificación de cambio de archivo actualizando FCNMode.
  • Actualice el intervalo de sondeo del proceso de trabajo de IIS (W3WP) a 0 estableciendo HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds en el registro y reinicie el proceso W3WP. Para obtener más información acerca de esta configuración, vea las claves de registro comunes que utilizan muchas partes de IIS.

• 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 a su sitio web tiene una estructura de directorios anidados, intente limitar el alcance de las notificaciones de cambios en los archivos 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

• Solucionar problemas de Azure Files
• Solución de problemas de Azure Files mediante la creación de alertas
• Descripción del rendimiento de Azure Files
• Introducción a las alertas en Microsoft Azure
• Preguntas más frecuentes de Azure Files