Partager via

Résoudre les problèmes de niveau de performance d’Azure Files

  • Article

Note

CentOS référencé dans cet article est une distribution Linux et atteint la fin de vie (EOL). Faites le point sur votre utilisation et organisez-vous en conséquence. Pour plus d’informations, consultez les conseils sur la fin de vie centOS.

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

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éraux

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.

Informations pour Windows 8.1 ou 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 de création et d’ouverture des handles.

Vous pouvez exécuter le script suivant pour vérifier 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

Notes

Les images de Windows Server 2012 R2 dans Azure Marketplace ont le correctif logiciel KB3114025 installé par défaut à compter de décembre 2015.

Votre charge de travail est limitée

Les requêtes sont limitées lorsque les limites d’opérations d’E/S par seconde (IOPS) ou les limites d’entrée/de sortie d’un partage de fichiers sont atteintes. Par exemple, si le client dépasse les IOPS de base, 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 des fichiers. Selon votre charge de travail, la limitation peut souvent être évitée en passant des 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 de performances généraux, consultez La limitation du compte de stockage ou de partage est en cours.

Latence élevée, débit faible ou faible IOPS

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

Pour vérifier si votre partage est limité, vous pouvez accéder aux indicateurs de performance 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.

Important

Pour les comptes de stockage standard, la limitation se produit au niveau du compte de stockage. Pour les partages de fichiers Premium, la limitation se produit au niveau du partage.

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

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

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

  4. Sélectionnez Transactions comme métrique.

  5. Ajoutez un filtre pour Type de réponse, puis vérifiez si des requêtes ont été limitées.

    Pour les partages de fichiers standard, les types de réponse suivants sont enregistrés si une demande est limitée au niveau du compte client :

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Pour les partages de fichiers premium, les types de réponse suivants sont consigné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 auprès de 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 mesures.

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

Solution

Si vous utilisez un partage de fichiers premium, augmentez la taille du partage de fichiers approvisionné pour rehausser la limite d’IOPS. Pour plus d’informations, consultez Présentation du provisionnement des partages de fichiers Premium.

Cause 2 : Métadonnées ou charge de travail importante de l’espace de noms

Si la majorité de vos demandes sont centrées sur les métadonnées (comme createfile, openfile, closefile, queryinfo ou querydirectory), la latence sera plus importante que celle des opérations de lecture/d’écriture.

Pour déterminer si la plupart de vos demandes sont centrées sur des métadonnées, commencez par suivre les étapes 1 à 4 décrites 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 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 sur les métadonnées.

  • Si vous utilisez des partages de fichiers Azure SMB Premium, utilisez le cache des 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 à partir du client pour effectuer des opérations de fichiers sur les données. Cette approche fonctionne pour des scénarios à un seul rédacteur/lecteur ou des scénarios avec plusieurs lecteurs et aucun rédacteur. Comme le système de fichiers appartient au client plutôt qu’à Azure Files, les opérations sur les métadonnées peuvent être locales. La configuration offre des performances similaires à celles d’un stockage local directement attaché. Toutefois, étant donné que les données se trouvent dans un disque dur virtuel, elles ne sont accessibles que 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, puis 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é, et 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. Une nouvelle lettre de lecteur devrait apparaître dans Gestion des disques, représentant ce disque dur virtuel avec accès en lecture/écriture (par exemple, E:). Dans l’Explorateur de fichiers, vous devriez 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. Il devrait y avoir de bien meilleures performances sur les opérations de métadonnées lourdes sur les fichiers sur le lecteur mappé du disque dur virtuel (E:) par rapport au lecteur mappé de partage de fichiers Azure (Z:). Si vous le souhaitez, il doit être possible de déconnecter le lecteur réseau mappé (Z:) et de toujours accéder au lecteur VHD monté (E:).
    • Pour monter un disque dur virtuel (VHD) sur un client Windows, vous pouvez également utiliser la cmdlet PowerShell Mount-DiskImage.
    • Pour monter un disque dur virtuel (VHD) sur Linux, consultez la documentation de votre distribution Linux. Voici un exemple.

Cause 3 : Application à thread unique

Si l’application que vous utilisez est à thread unique, cette configuration peut entraîner un débit d’IOPS sensiblement inférieur au débit maximal possible, selon la taille de votre partage approvisionné.

Solution

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

Cause 4 : Le nombre de canaux SMB est supérieur à quatre

Si vous utilisez SMB Multichannel et que vous avez plus de quatre canaux, cela entraîne une dégradation des performances. Pour déterminer si le nombre de vos connexions est supérieur à quatre, utilisez la cmdlet PowerShell get-SmbClientConfiguration pour afficher les paramètres actuels du nombre de connexions.

Solution

Définissez le paramètre Windows par carte réseau pour SMB de sorte 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 la cmdlet PowerShell suivante : Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Cause 5 : La taille en lecture-avance 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 (KiB). 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 du noyau à 15 mebibytes (MiB). Pour modifier cette valeur, définissez la taille en lecture-avance de manière permanente en ajoutant une règle dans udev, un gestionnaire d’appareils du noyau Linux. Effectuez les étapes suivantes :

  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 d’autres bases de données. Pour prendre connaissance du nouveau fichier, vous n’avez besoin d’exécuter cette commande qu’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 autre région que le partage de fichiers. La latence élevée peut également ê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 le portail Azure. Une différence importante entre les valeurs des métriques SuccessE2ELatency et SuccessServerLatency est une indication de la latence probablement due au réseau ou au client. Consultez Métriques de transaction dans les références de données Azure Files.

Impossible pour le client d’atteindre le débit maximal pris en charge par le réseau

Cause

L’une des causes possibles est l’absence de prise en charge de SMB multicanal pour les partages de fichiers standard. Actuellement, Azure Files ne prend en charge qu’un seul canal pour les partages de fichiers standard. Par conséquent, il n’y a qu’une seule connexion de la machine virtuelle cliente au serveur. Cette connexion unique étant fixée à un seul processeur sur l’ordinateur virtuel client, le débit maximal réalisable à partir d’une machine virtuelle est lié par un seul cœur.

Solution de contournement

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

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 que si vous accédez plusieurs fois à un fichier. 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 vérifier 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 avec la commande de montage par défaut ou en ajoutant explicitement l’option cache=strict à la commande de montage pour vérifier l’activation de la mise en cache par défaut ou du mode de mise en cache « strict ».

Dans certains scénarios, l’option de montage serverino peut entraîner la commande ls à exécuter stat dans chaque entrée de répertoire. Ce comportement provoque une dégradation des performances lorsque vous répertoriez le contenu d’un répertoire volumineux. Vous pouvez vérifier les options de montage dans l’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 vérifier si les options correctes sont utilisées en exécutant la commande sudo mount | grep cifs 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 remontez Azure Files en exécutant la commande de montage à partir de la documentation. Revérifiez ensuite que les options sont correctes pour l’entrée /etc/fstab.

Cause 2 : Limitation

Il est possible que rencontriez des limitations et que vos requêtes soient envoyées dans une file d’attente. Vous pouvez cela vérifier en tirant parti des mesures de 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 est incluse dans les objectifs de mise à l’échelle Azure Files. Si vous utilisez des partages de fichiers Azure standard, envisagez de passer à Premium.

Le débit sur les clients Linux est sensiblement plus faible que sur des clients Windows

Cause

Il s’agit d’un problème connu d’implémentation de 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 option nosharesock, et répartissez la charge entre ces points de montage.
  • Sur Linux, essayez d’effectuer le montage avec une option nostrictsync pour éviter de forcer un vidage SMB à chaque appel de fsync. Pour Azure Files, cette option n’interfère pas avec la cohérence des données, mais elle pourrait entraîner la présence de métadonnées de fichier obsolètes dans les listes de répertoires (commande ls -l). L’interrogation directe des métadonnées du fichier à l’aide de la commande stat retournera les métadonnées de fichier les plus récentes.

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

Cause

Absence de prise en charge pour les baux de répertoire.

Solution de contournement

  • Si possible, évitez d’ouvrir/de fermer le descripteur un nombre de fois excessif sur le même répertoire dans un laps de temps bref.
  • Pour les machines virtuelles Linux, augmentez le délai d’expiration du cache du répertoire d’entrée en spécifiant actimeo=<sec> comme option de montage. Par défaut, le délai d’expiration est de 1 seconde. Ainsi, une valeur plus élevée, par exemple de 30 secondes, peut être utile.
  • Pour des 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 une version ultérieure.

Lenteur de l’énumération des fichiers et dossiers

Cause

Ce problème peut se produire quand il n’y a pas suffisamment de mémoire cache sur la machine cliente pour les grands répertoires.

Solution

Pour résoudre ce problème, ajustez la valeur de Registre DirectoryCacheEntrySizeMax pour permettre la mise en cache des listes de répertoires plus grands sur la machine cliente :

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

Par exemple, vous pouvez configurer la valeur sur 0x100000 et observer si les performances s’améliorent.

Lenteur de copie des fichiers vers et depuis des partages de fichiers Azure

Les performances peuvent être ralenties lorsque vous essayez de transférer des fichiers vers le service Azure Files. Si vous n’avez pas d’exigence de taille d’E/S minimum spécifique, nous vous recommandons d’utiliser une taille d’E/S de 1 Mio pour des performances optimales.

Ralentissement des copies de fichiers vers et à partir d’Azure Files sous Windows

  • Si vous connaissez la taille finale d’un fichier que vous étendez avec des écritures, et si votre logiciel ne présente aucun problème de compatibilité lorsque la fin non écrite du fichier contient des zéros, définissez la taille du fichier à l’avance au lieu que chaque écriture soit une écriture d’extension.

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

    • Utilisez AZCopy pour les transferts entre deux partages de fichiers.
    • Utilisez Robocopy entre des partages de fichiers sur un ordinateur local.

Appels DirectoryOpen/DirectoryClose excessifs

Cause

Si les appels DirectoryOpen/DirectoryClose comptent parmi les principaux appels d’API et que vous ne vous attendez pas à ce que le client fasse autant d’appels, le problème pourrait ê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 d’avril de la plateforme pour Windows.

La fonctionnalité SMB Multichannel n’est pas déclenchée

Cause

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

Solution

  • Après toute modification apportée aux paramètres de configuration de la fonctionnalité SMB Multichannel de compte ou de client de SMB Windows, vous devez démonter le partage, attendre 60 secondes, puis remonter le partage pour déclencher la fonctionnalité.
  • Pour le système d’exploitation du client Windows, générez une charge d’E/S avec une profondeur de file d’attente élevée, par exemple de 8, en copiant un fichier pour déclencher la fonctionnalité SMB Multichannel. Pour le système d’exploitation du serveur, la fonctionnalité SMB Multichannel est déclenchée avec une profondeur de file d’attente de 1, c’est-à-dire dès que vous démarrez une E/S sur le partage.

Performances lentes lors de la décompression des fichiers

Selon la méthode de compression et l’opération de décompression exactes utilisées, les opérations 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 sur les métadonnées pendant la décompression d’une archive compressée. Pour optimiser les performances, nous vous recommandons de copier l’archive compressée à partir du partage de fichiers Azure sur votre disque local, de l’y décompresser, puis d’utiliser un outil de copie tel que Robocopy (ou AzCopy) pour copier les fichiers décompressés vers le partage de fichiers Azure. L’utilisation d’un outil de copie tel que Robocopy peut compenser la baisse des performances des opérations sur les 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 des sites web hébergés sur des partages de fichiers

Cause

Un nombre élevé de notifications de modification de fichier sur des partages de fichiers peut entraîner des latences importantes. Cela se produit généralement avec des sites web hébergés sur des partages de fichiers avec une structure de répertoires imbriqués profonde. Un scénario classique est l’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 (push) une notification de modification du service de fichiers au client, ce qui consomme des ressources système, et le problème s’aggrave avec le nombre de modifications. Cela peut entraîner une limitation du partage et, par conséquent, une latence plus élevée côté client.

Pour vérifier cela, vous pouvez utiliser les indicateurs de performances Azure dans le portail :

  1. Dans le portail Azure, accédez à votre compte de stockage.
  2. Dans le menu de gauche, sous Supervision, sélectionnez Métriques.
  3. Sélectionnez Fichier comme espace de noms de métrique pour votre étendue de compte de stockage.
  4. Sélectionnez Transactions comme métrique.
  5. Ajoutez un filtre pour ResponseType et vérifiez 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 (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 vers 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\ConfigPollMilliSeconds dans votre registre, puis redémarrez le processus W3WP.

  • Si le répertoire physique mappé de votre site web a une structure de répertoires imbriquée, 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 fichiers Web.config 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 les fichiers Web.config dans les répertoires enfants, spécifiez false l’attribut allowSubDirConfig sur le répertoire virtuel. Pour plus d’informations, cliquez ici.

    Définissez le paramètre de répertoire allowSubDirConfig virtuel IIS dans Web.Config pour false 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.