Résoudre les problèmes de performances Azure Files

  • Article

Cet article répertorie les problèmes courants liés aux performances du partage de fichiers Azure et fournit des causes et des solutions de contournement potentielles. Pour tirer le meilleur parti de ce guide de résolution des problèmes, nous vous recommandons de commencer par lire Comprendre Azure Files performances.

S’applique à

Type de partage de fichiers SMB NFS
Partages de fichiers standard (GPv2), LRS/ZRS
Partages de fichiers standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

Résolution des problèmes de performances générales

Tout d’abord, excluez certaines raisons courantes pour lesquelles vous pourriez rencontrer des problèmes de performances.

Vous exécutez un ancien système d’exploitation

Si votre machine virtuelle cliente exécute Windows 8.1 ou Windows Server 2012 R2, ou une distribution ou un noyau Linux plus ancien, vous pouvez rencontrer des problèmes de performances lors de l’accès aux partages de fichiers Azure. Mettez à niveau votre système d’exploitation client ou appliquez les correctifs ci-dessous.

Considérations relatives à Windows 8.1 et Windows Server 2012 R2

Les clients qui exécutent Windows 8.1 ou Windows Server 2012 R2 peuvent voir une latence plus élevée que prévu lors de l’accès aux partages de fichiers Azure pour les charges de travail gourmandes en E/S. Vérifiez que le correctif logiciel KB3114025 est installé. Ce correctif logiciel améliore les performances des handles de création et de fermeture.

Vous pouvez exécuter le script suivant pour case activée si le correctif logiciel a été installé :

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

Si le correctif logiciel est installé, la sortie suivante s’affiche :

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

Remarque

Windows Server 2012 les images R2 de Place de marché Azure ont des KB3114025 de correctif logiciel installés par défaut, à partir de décembre 2015.

Votre charge de travail est limitée

Les demandes sont limitées lorsque les limites des opérations d’E/S par seconde (IOPS), d’entrée ou de sortie d’un partage de fichiers sont atteintes. Par exemple, si le client dépasse les IOPS de référence, il est limité par le service Azure Files. La limitation peut entraîner des performances médiocres pour le client.

Pour comprendre les limites des partages de fichiers Standard et Premium, consultez Cibles de partage de fichiers et de mise à l’échelle de fichiers. Selon votre charge de travail, la limitation peut souvent être évitée en passant de partages de fichiers Azure standard à premium.

Pour en savoir plus sur la façon dont la limitation au niveau du partage ou du compte de stockage peut entraîner une latence élevée, un faible débit et des problèmes généraux de performances, consultez La limitation du compte de partage ou de stockage est en cours.

Latence élevée, débit faible ou faible E/S par seconde

Cause 1 : Le compte de partage ou de stockage est limité

Pour vérifier si votre compte de partage ou de stockage est limité, vous pouvez accéder aux métriques Azure et les utiliser dans le portail. Vous pouvez également créer des alertes qui vous avertiront si un partage est limité ou s’il est sur le point d’être limité. Consultez Résoudre les problèmes Azure Files en créant des alertes.

Importante

Pour les comptes de stockage standard avec des partages de fichiers volumineux (LFS) activés, la limitation se produit au niveau du compte. Pour les partages de fichiers Premium et les partages de fichiers standard sans LFS activés, la limitation se produit au niveau du partage.

  1. Dans le Portail Azure, accédez à votre compte de stockage.

  2. Dans le volet gauche, sous Surveillance, sélectionnez Métriques.

  3. Sélectionnez Fichier comme espace de noms de métrique pour l’étendue de votre compte de stockage.

  4. Sélectionnez Transactions comme métrique.

  5. Ajoutez un filtre pour Type de réponse, puis case activée pour voir si des demandes ont été limitées.

    Pour les partages de fichiers standard qui n’ont pas de partages de fichiers volumineux activés, les types de réponse suivants sont enregistrés si une requête est limitée au niveau du partage :

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    Pour les partages de fichiers standard qui ont des partages de fichiers volumineux activés, les types de réponse suivants sont enregistrés si une requête est limitée au niveau du compte client :

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Pour les partages de fichiers Premium, les types de réponse suivants sont enregistrés si une requête est limitée au niveau du partage :

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

    Si une demande limitée a été authentifiée avec Kerberos, vous pouvez voir un préfixe indiquant le protocole d’authentification, par exemple :

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Pour en savoir plus sur chaque type de réponse, consultez Dimensions de métrique.

    Capture d’écran montrant le filtre de propriété « Type de réponse ».

Solution

Cause 2 : Charge de travail importante pour les métadonnées ou l’espace de noms

Si la majorité de vos requêtes sont centrées sur les métadonnées (telles que createfile, , openfileclosefile, queryinfoou querydirectory), la latence sera inférieure à celle des opérations de lecture/écriture.

Pour déterminer si la plupart de vos demandes sont centrées sur les métadonnées, commencez par suivre les étapes 1 à 4, comme indiqué précédemment dans Cause 1. Pour l’étape 5, au lieu d’ajouter un filtre pour le type de réponse, ajoutez un filtre de propriété pour le nom de l’API.

Capture d’écran montrant le filtre de propriété « Nom de l’API ».

Solutions de contournement

  • Vérifiez si l’application peut être modifiée pour réduire le nombre d’opérations de métadonnées.

  • Séparez le partage de fichiers en plusieurs partages de fichiers au sein du même compte de stockage.

  • Ajoutez un disque dur virtuel (VHD) sur le partage de fichiers et montez le disque dur virtuel à partir du client pour effectuer des opérations de fichier sur les données. Cette approche fonctionne pour les scénarios d’écriture/lecteur unique ou les scénarios avec plusieurs lecteurs et aucun enregistreur. Étant donné que le système de fichiers appartient au client plutôt qu’à Azure Files, cela permet aux opérations de métadonnées d’être locales. Le programme d’installation offre des performances similaires à celles du stockage local directement attaché. Toutefois, étant donné que les données se trouvent dans un disque dur virtuel, elles ne sont pas accessibles par d’autres moyens que le montage SMB, comme l’API REST ou via le Portail Azure.

    1. À partir de la machine qui doit accéder au partage de fichiers Azure, montez le partage de fichiers à l’aide de la clé de compte de stockage et mappez-le à un lecteur réseau disponible (par exemple, Z :).
    2. Accédez à Gestion des disques et sélectionnez Action > Créer un disque dur virtuel.
    3. Définissez Emplacement sur le lecteur réseau auquel le partage de fichiers Azure est mappé, définissez la taille du disque dur virtuel en fonction des besoins, puis sélectionnez Taille fixe.
    4. Sélectionnez OK. Une fois la création du disque dur virtuel terminée, il est automatiquement monté et un nouveau disque non alloué s’affiche.
    5. Cliquez avec le bouton droit sur le nouveau disque inconnu, puis sélectionnez Initialiser le disque.
    6. Cliquez avec le bouton droit sur la zone non allouée et créez un nouveau volume simple.
    7. Vous devriez voir apparaître une nouvelle lettre de lecteur dans Gestion des disques représentant ce disque dur virtuel avec accès en lecture/écriture (par exemple, E :). Dans Explorateur de fichiers, vous devez voir le nouveau disque dur virtuel sur le lecteur réseau du partage de fichiers Azure mappé (Z : dans cet exemple). Pour être clair, deux lettres de lecteur doivent être présentes : le mappage réseau de partage de fichiers Azure standard sur Z :, et le mappage de disque dur virtuel sur le lecteur E :.
    8. Les performances devraient être bien meilleures sur les opérations de métadonnées intensives sur les fichiers sur le lecteur mappé VHD (E :) par rapport au lecteur mappé du partage de fichiers Azure (Z :). Si vous le souhaitez, il doit être possible de déconnecter le lecteur réseau mappé (Z :) et d’accéder au lecteur de disque dur virtuel monté (E :).
    • Pour monter un disque dur virtuel sur un client Windows, vous pouvez également utiliser l’applet de Mount-DiskImage commande PowerShell.
    • Pour monter un disque dur virtuel sur Linux, consultez la documentation de votre distribution Linux. Voici un exemple.

Cause 3 : Application monothread

Si l’application que vous utilisez est monothread, cette configuration peut entraîner un débit d’IOPS considérablement inférieur au débit maximal possible, en fonction de la taille de votre partage provisionné.

Solution

  • Augmentez le parallélisme des applications en augmentant le nombre de threads.
  • Basculez vers les applications où le parallélisme est possible. Par exemple, pour les opérations de copie, vous pouvez utiliser AzCopy ou RoboCopy à partir de clients Windows ou la commande parallèle des clients Linux.

Cause 4 : Le nombre de canaux SMB dépasse quatre

Si vous utilisez SMB MultiChannel et que le nombre de canaux dont vous disposez dépasse quatre, les performances sont médiocres. Pour déterminer si votre nombre de connexions dépasse quatre, utilisez l’applet de commande get-SmbClientConfiguration PowerShell pour afficher les paramètres actuels du nombre de connexions.

Solution

Définissez le paramètre Windows par carte réseau pour SMB afin que le nombre total de canaux ne dépasse pas quatre. Par exemple, si vous avez deux cartes réseau, vous pouvez définir la valeur maximale par carte réseau sur deux à l’aide de l’applet de commande PowerShell suivante : Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Cause 5 : La taille de lecture anticipée est trop petite (NFS uniquement)

À compter de la version 5.4 du noyau Linux, le client NFS Linux utilise une valeur par défaut read_ahead_kb de 128 Kibioctets (Kio). Cette petite valeur peut réduire la quantité de débit de lecture pour les fichiers volumineux.

Solution

Nous vous recommandons d’augmenter la valeur du read_ahead_kb paramètre de noyau à 15 miooctets (Mio). Pour modifier cette valeur, définissez la taille de lecture anticipée de manière permanente en ajoutant une règle dans udev, un gestionnaire de périphériques du noyau Linux. Procédez comme suit :

  1. Dans un éditeur de texte, créez le fichier /etc/udev/rules.d/99-nfs.rules en entrant et en enregistrant le texte suivant :

    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. Dans une console, appliquez la règle udev en exécutant la commande udevadm en tant que superutilisateur et en rechargeant les fichiers de règles et autres bases de données. Pour informer udev du nouveau fichier, vous devez exécuter cette commande une seule fois.

    sudo udevadm control --reload

Latence très élevée pour les requêtes

Cause

La machine virtuelle cliente peut se trouver dans une région différente de celle du partage de fichiers. Une autre raison de la latence élevée peut être due à la latence causée par le client ou le réseau.

Solution

  • Exécutez l’application à partir d’une machine virtuelle située dans la même région que le partage de fichiers.
  • Pour votre compte de stockage, passez en revue les métriques de transaction SuccessE2ELatency et SuccessServerLatency via Azure Monitor dans Portail Azure. Une différence élevée entre les valeurs des métriques SuccessE2ELatency et SuccessServerLatency est une indication de latence qui est probablement due au réseau ou au client. Consultez Métriques de transaction dans Azure Files informations de référence sur les données de surveillance.

Le client ne peut pas atteindre le débit maximal pris en charge par le réseau

Cause

L’une des causes potentielles est l’absence de prise en charge multicanal SMB pour les partages de fichiers standard. Actuellement, Azure Files ne prend en charge qu’un seul canal pour les partages de fichiers standard. Il n’existe donc qu’une seule connexion entre la machine virtuelle cliente et le serveur. Cette connexion unique est associée à un seul cœur sur la machine virtuelle cliente, de sorte que le débit maximal réalisable à partir d’une machine virtuelle est lié par un seul cœur.

Solution de contournement

Ralentissement des performances sur un partage de fichiers Azure monté sur une machine virtuelle Linux

Cause 1 : Mise en cache

L’une des causes possibles du ralentissement des performances est la désactivation de la mise en cache. La mise en cache peut être utile si vous accédez à un fichier à plusieurs reprises. Sinon, il peut s’agir d’une surcharge. Vérifiez si vous utilisez le cache avant de le désactiver.

Solution pour la cause 1

Pour case activée si la mise en cache est désactivée, recherchez l’entrée cache= .

Cache=none indique que la mise en cache est désactivée. Remontez le partage à l’aide de la commande de montage par défaut ou en ajoutant explicitement l’option cache=strict à la commande de montage pour vous assurer que le mode de mise en cache par défaut ou de mise en cache « strict » est activé.

Dans certains scénarios, l’option serverino de montage peut entraîner l’exécution stat de la ls commande sur chaque entrée de répertoire. Ce comportement entraîne une dégradation des performances lorsque vous répertoriez un répertoire volumineux. Vous pouvez case activée les options de montage dans votre entrée /etc/fstab :

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

Vous pouvez également case activée si les options appropriées sont utilisées en exécutant la sudo mount | grep cifs commande et en vérifiant sa sortie. Voici un exemple de sortie :

//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 l’option cache=strict ou serverino n’est pas présente, démontez et montez à nouveau Azure Files en exécutant la commande mount à partir de la documentation. Ensuite, vérifiez à nouveau que l’entrée /etc/fstab dispose des options correctes.

Cause 2 : Limitation

Il est possible que vous rencontriez une limitation et que vos demandes soient envoyées à une file d’attente. Vous pouvez le vérifier en tirant parti des métriques stockage Azure dans Azure Monitor. Vous pouvez également créer des alertes qui vous avertissent si un partage est limité ou s’il est sur le point d’être limité. Consultez Résoudre les problèmes Azure Files en créant des alertes.

Solution pour la cause 2

Vérifiez que votre application se trouve dans les Azure Files cibles de mise à l’échelle. Si vous utilisez des partages de fichiers Azure standard, envisagez de passer à Premium.

Le débit sur les clients Linux est inférieur à celui des clients Windows

Cause

Il s’agit d’un problème connu lié à l’implémentation du client SMB sur Linux.

Solution de contournement

  • Répartissez la charge sur plusieurs machines virtuelles.
  • Sur la même machine virtuelle, utilisez plusieurs points de montage avec une nosharesock option et répartissez la charge sur ces points de montage.
  • Sur Linux, essayez de monter avec une nostrictsync option pour éviter de forcer un vidage SMB à chaque fsync appel. Par Azure Files, cette option n’interfère pas avec la cohérence des données, mais elle peut entraîner des métadonnées de fichier obsolètes sur les listes de répertoires (ls -l commande). L’interrogation directe des métadonnées de fichier à l’aide de la stat commande renvoie les métadonnées de fichier les plus récentes.

Latences élevées pour les charges de travail gourmandes en métadonnées impliquant des opérations d’ouverture/de fermeture étendues

Cause

Manque de prise en charge des baux d’annuaire.

Solution de contournement

  • Si possible, évitez d’utiliser un handle d’ouverture/fermeture excessif sur le même répertoire dans un court laps de temps.
  • Pour les machines virtuelles Linux, augmentez le délai d’expiration du cache d’entrée de répertoire en spécifiant actimeo=<sec> comme option de montage. Par défaut, le délai d’expiration étant de 1 seconde, une valeur plus élevée, telle que 30 secondes, peut être utile.
  • Pour les machines virtuelles CentOS Linux ou Red Hat Enterprise Linux (RHEL), mettez à niveau le système vers CentOS Linux 8.2 ou RHEL 8.2. Pour les autres distributions Linux, mettez à niveau le noyau vers la version 5.0 ou ultérieure.

Énumération lente des fichiers et dossiers

Cause

Ce problème peut se produire s’il n’y a pas suffisamment de cache sur l’ordinateur client pour les répertoires volumineux.

Solution

Pour résoudre ce problème, ajustez la valeur de Registre pour autoriser la DirectoryCacheEntrySizeMax mise en cache de listes de répertoires plus volumineuses sur l’ordinateur client :

  • Emplacement: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Nom de la valeur : DirectoryCacheEntrySizeMax
  • Type de la valeur : DWORD

Par exemple, vous pouvez le définir sur 0x100000 et voir si les performances s’améliorent.

Lenteur de la copie de fichiers vers et à partir de partages de fichiers Azure

Vous pouvez constater des performances lentes lorsque vous essayez de transférer des fichiers vers le service Azure Files. Si vous n’avez pas besoin d’une taille d’E/S minimale spécifique, nous vous recommandons d’utiliser 1 Mio comme taille d’E/S pour des performances optimales.

Lenteur de la copie de fichiers vers et depuis Azure Files dans Windows

  • Si vous connaissez la taille finale d’un fichier que vous étendez avec des écritures et que votre logiciel n’a pas de problèmes de compatibilité lorsque la fin non écrite du fichier contient des zéros, définissez la taille du fichier à l’avance au lieu de faire de chaque écriture une écriture d’extension.

  • Utilisez la méthode de copie appropriée :

    • Utilisez AzCopy pour tout transfert entre deux partages de fichiers.
    • Utilisez Robocopy entre des partages de fichiers sur un ordinateur local.

Nombre excessif d’appels DirectoryOpen/DirectoryClose

Cause

Si le nombre d’appels DirectoryOpen/DirectoryClose figure parmi les principaux appels d’API et que vous ne vous attendez pas à ce que le client effectue autant d’appels, le problème peut être dû au logiciel antivirus installé sur la machine virtuelle cliente Azure.

Solution de contournement

Un correctif pour ce problème est disponible dans la mise à jour de la plateforme d’avril pour Windows.

SMB Multichannel n’est pas déclenché

Cause

Modifications récentes apportées aux paramètres de configuration SMB Multichannel sans remontage.

Solution

  • Après toute modification apportée aux paramètres de configuration multicanal du client ou du compte SMB Windows, vous devez démonter le partage, attendre 60 secondes et remonter le partage pour déclencher le multicanal.
  • Pour le système d’exploitation client Windows, générez une charge d’E/S avec une profondeur de file d’attente élevée, par exemple en copiant un fichier pour déclencher SMB Multichannel. Pour le système d’exploitation serveur, SMB Multichannel est déclenché avec QD=1, ce qui signifie que dès que vous démarrez des E/S dans le partage.

Ralentissement des performances lors de la décompression de fichiers

Selon la méthode de compression exacte et l’opération de décompression utilisées, les opérations de décompression peuvent s’effectuer plus lentement sur un partage de fichiers Azure que sur votre disque local. Cela est souvent dû au fait que les outils de décompression effectuent un certain nombre d’opérations de métadonnées dans le processus de décompression d’une archive compressée. Pour des performances optimales, nous vous recommandons de copier l’archive compressée du partage de fichiers Azure sur votre disque local, de le décompresser, puis d’utiliser un outil de copie tel que Robocopy (ou AzCopy) pour le copier vers le partage de fichiers Azure. L’utilisation d’un outil de copie comme Robocopy peut compenser la baisse des performances des opérations de métadonnées dans Azure Files par rapport à votre disque local en utilisant plusieurs threads pour copier des données en parallèle.

Latence élevée sur les sites web hébergés sur des partages de fichiers

Cause

La notification de modification de fichier en nombre élevé sur les partages de fichiers peut entraîner des latences élevées. Cela se produit généralement avec les sites web hébergés sur des partages de fichiers avec une structure de répertoires imbriquée. Un scénario classique est une application web hébergée par IIS où la notification de modification de fichier est configurée pour chaque répertoire dans la configuration par défaut. Chaque modification (ReadDirectoryChangesW) sur le partage pour lequel le client est inscrit envoie une notification de modification du service de fichiers au client, qui prend des ressources système, et le problème s’aggrave avec le nombre de modifications. Cela peut entraîner une limitation du partage et entraîner ainsi une latence plus élevée côté client.

Pour confirmer, vous pouvez utiliser Métriques Azure dans le portail.

  1. Dans le Portail Azure, accédez à votre compte de stockage.
  2. Dans le menu de gauche, sous Surveillance, sélectionnez Métriques.
  3. Sélectionnez Fichier comme espace de noms de métrique pour l’étendue de votre compte de stockage.
  4. Sélectionnez Transactions comme métrique.
  5. Ajoutez un filtre pour ResponseType et case activée pour voir si des requêtes ont un code de SuccessWithThrottling réponse (pour SMB ou NFS) ou ClientThrottlingError (pour REST).

Solution

  • Si la notification de modification de fichier n’est pas utilisée, désactivez la notification de modification de fichier (par défaut).

  • Augmentez la fréquence de l’intervalle d’interrogation des notifications de modification de fichier pour réduire le volume.

    Mettez à jour l’intervalle d’interrogation du processus de travail W3WP avec une valeur supérieure (par exemple, 10 ou 30 minutes) en fonction de vos besoins. Définissez HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSecondsdans votre registre et redémarrez le processus W3WP.

  • Si le répertoire physique mappé de votre site web a une structure de répertoires imbriqués, vous pouvez essayer de limiter l’étendue des notifications de modification de fichier pour réduire le volume de notification. Par défaut, IIS utilise la configuration à partir de Web.config fichiers dans le répertoire physique auquel le répertoire virtuel est mappé, ainsi que dans tous les répertoires enfants de ce répertoire physique. Si vous ne souhaitez pas utiliser Web.config fichiers dans les répertoires enfants, spécifiez false pour l’attribut allowSubDirConfig sur le répertoire virtuel. Vous trouverez plus d’informations ici.

    Définissez le paramètre de répertoire allowSubDirConfig virtuel IIS dans Web.Config sur false pour exclure les répertoires enfants physiques mappés de l’étendue.

Voir aussi

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.