Condividi tramite

Risolvere i problemi di prestazioni di File di Azure

  • Articolo

Note

CentOS a cui si fa riferimento in questo articolo è una distribuzione Linux e raggiungerà End Of Life (EOL). Valutare le proprie esigenze e pianificare di conseguenza. Per altre informazioni, vedere Indicazioni sulla fine della vita di CentOS.

Questo articolo elenca i problemi comuni relativi alle prestazioni della condivisione file di Azure e offre possibili cause e soluzioni alternative. Per ottenere il massimo valore da questa guida alla risoluzione dei problemi, è consigliabile leggere prima di tutto Informazioni sulle prestazioni File di Azure.

Si applica a

Tipo di condivisione file SMB NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona

Risoluzione dei problemi generali delle prestazioni

Prima di tutto, escludere alcuni motivi comuni per cui potrebbero verificarsi problemi di prestazioni.

Si sta eseguendo un vecchio sistema operativo

Se la macchina virtuale client esegue Windows 8.1 o Windows Server 2012 R2 o una distribuzione o un kernel Linux meno recente, potrebbero verificarsi problemi di prestazioni durante l'accesso alle condivisioni file di Azure. Aggiornare il sistema operativo client o applicare le correzioni seguenti.

Considerazioni per Windows 8.1 e Windows Server 2012 R2

I client che eseguono Windows 8.1 o Windows Server 2012 R2 potrebbero visualizzare una latenza superiore al previsto durante l'accesso alle condivisioni file di Azure per carichi di lavoro con utilizzo intensivo di I/O. Assicurarsi che sia installato l'hotfix KB3114025 . Questa hotfix consente di migliorare le prestazioni durante la creazione e la chiusura degli handle.

Per verificare se la hotfix è stata installata, è possibile eseguire lo script seguente:

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

Se l'hotfix è installato, viene visualizzato l'output seguente:

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

Note

Da dicembre 2015 la hotfix KB3114025 è installata per impostazione predefinita nelle immagini di Windows Server 2012 R2 presenti in Azure Marketplace.

Il carico di lavoro è in fase di limitazione

Le richieste vengono limitate quando vengono raggiunte le operazioni di I/O al secondo, in ingresso o in uscita per una condivisione file. Ad esempio, se il client supera le operazioni di I/O al secondo di base, verrà limitato dal servizio File di Azure. La limitazione può comportare una riduzione delle prestazioni del client.

Per comprendere i limiti per le condivisioni file standard e Premium, vedere Obiettivi della condivisione file e della scalabilità di file. A seconda del carico di lavoro, la limitazione può spesso essere evitata passando da condivisioni file standard a premium di Azure.

Per altre informazioni su come la limitazione a livello di condivisione o di account di archiviazione può causare una latenza elevata, una velocità effettiva bassa e problemi generali di prestazioni, vedere L'account di condivisione o di archiviazione è in fase di limitazione.

Latenza elevata, velocità effettiva bassa o operazioni di I/O al secondo basse

Causa 1: La condivisione o l'account di archiviazione viene limitata

Per verificare se l'account di condivisione o di archiviazione è limitato, è possibile accedere e usare le metriche di Azure nel portale. È inoltre possibile creare avvisi che informano se una condivisione è limitata o sta per essere limitata. Vedere Risolvere i problemi File di Azure creando avvisi.

Importante

Per gli account di archiviazione standard, la limitazione avviene a livello di account di archiviazione. Per le condivisioni file Premium, la limitazione avviene a livello di condivisione.

  1. Nel portale di Azure passare all'account di archiviazione.

  2. Nel riquadro a sinistra, nella scheda Monitoraggio selezionare Metrica.

  3. Selezionare File come spazio dei nomi delle metriche per l'ambito dell'account di archiviazione.

  4. Selezionare Transazioni come metriche.

  5. Aggiungere un filtro per Tipo di risposta e quindi verificare se le richieste sono state limitate.

    Per le condivisioni file standard, i tipi di risposta seguenti vengono registrati se una richiesta viene limitata a livello di account client:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Per le condivisioni di file premium, vengono registrati i tipi di risposta seguenti se una richiesta viene limitata a livello di condivisione:

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

    Se una richiesta limitata è stata autenticata con Kerberos, è possibile che venga visualizzato un prefisso che indica il protocollo di autenticazione, ad esempio:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Per altre informazioni su ogni tipo di risposta, vedere Dimensioni delle metriche.

    Screenshot che mostra il filtro della proprietà

Soluzione

Se si usa una condivisione file Premium, aumentare le dimensioni della condivisione file di cui è stato effettuato il provisioning per aumentare il limite di operazioni di I/O al secondo. Per altre informazioni, vedere Informazioni sul provisioning per le condivisioni file Premium.

Causa 2: Carico di lavoro elevato dei metadati o dello spazio dei nomi

Se la maggior parte delle richieste è incentrata sui metadati, ad esempio createfile, openfile, closefile, queryinfo o querydirectory) la latenza sarà peggiore rispetto a quella delle operazioni di lettura/scrittura.

Per determinare se la maggior parte delle richieste è incentrata sui metadati, iniziare seguendo i passaggi da 1 a 4 come descritto in precedenza in Causa 1. Per il passaggio 5, invece di aggiungere un filtro per Tipo di risposta, aggiungere un filtro di proprietà per il nome DELL'API.

Screenshot che mostra il filtro di proprietà

Soluzioni alternative

  • Verificare se l'applicazione può essere modificata per ridurre il numero di operazioni sui metadati.

  • Se si usano condivisioni file di Azure SMB Premium, usare la memorizzazione dei metadati nella cache.

  • Separare la condivisione file in più condivisioni file all'interno dello stesso account di archiviazione.

  • Aggiungere un disco rigido virtuale (VHD) nella condivisione file e montare il disco rigido virtuale dal client per eseguire operazioni dei file sui dati. Questo approccio funziona per scenari di scrittura/lettore singoli o scenari con più lettori e senza writer. Poiché il file system è di proprietà del client invece di File di Azure, le operazioni sui metadati possono in questo modo essere locali. La configurazione offre prestazioni simili a quella dell'archiviazione collegata direttamente a livello locale. Tuttavia, poiché i dati si trovano in un disco rigido virtuale, non è possibile accedervi tramite mezzi diversi dal montaggio SMB, come l'API REST o il portale di Azure.

    1. Dal computer che deve accedere alla condivisione file di Azure, montare la condivisione file usando la chiave dell'account di archiviazione ed eseguirne il mapping a un'unità di rete disponibile ,ad esempio Z:.
    2. Passare a Gestione disco e selezionare Azione > Crea disco rigido virtuale.
    3. Impostare Posizione sull'unità di rete a cui è mappata la condivisione file di Azure, impostare Dimensioni disco rigido virtuale in base alle esigenze e selezionare Dimensioni fisse.
    4. Seleziona OK. Una volta completata la creazione del disco rigido virtuale, verrà montato automaticamente e verrà visualizzato un nuovo disco non allocato.
    5. Fare clic con il pulsante destro del mouse sul nuovo disco sconosciuto e selezionare Inizializza disco.
    6. Fare clic con il pulsante destro del mouse sull'area non allocata e creare un Nuovo volume semplice.
    7. Verrà visualizzata una nuova lettera di unità in Gestione disco che rappresenta questo disco rigido virtuale con accesso in lettura/scrittura, ad esempio E:. In Esplora file dovrebbe essere visualizzato il nuovo disco rigido virtuale nell'unità di rete della condivisione file di Azure mappata (Z: in questo esempio). Per essere chiari, devono essere presenti due lettere di unità: il mapping di rete standard della condivisione file di Azure in Z:, e il mapping del disco rigido virtuale nell'unità E:.
    8. Dovrebbero verificarsi prestazioni notevolmente migliori nelle operazioni di metadati pesanti sui file nell'unità mappata del disco rigido virtuale (E:) rispetto all'unità mappata della condivisione file di Azure (Z:). Se lo si desidera, dovrebbe essere possibile disconnettere l'unità di rete mappata (Z:) e accedere comunque all'unità VHD montata (E:).
    • Per montare un disco rigido virtuale in un client Windows, è anche possibile usare il cmdlet Mount-DiskImage di PowerShell.
    • Per montare un disco rigido virtuale in Linux, vedere la documentazione relativa alla distribuzione di Linux. Per un esempio, vedere qui.

Causa 3: Applicazione a thread singolo

Se l'applicazione in uso è a thread singolo, questa configurazione può comportare una velocità effettiva di I/O al secondo significativamente inferiore rispetto alla velocità effettiva massima possibile, a seconda delle dimensioni della condivisione di cui è stato effettuato il provisioning.

Soluzione

  • Aumentare il parallelismo dell'applicazione aumentando il numero di thread.
  • Passare alle applicazioni in cui è possibile il parallelismo. Ad esempio, per le operazioni di copia, è possibile usare AzCopy o RoboCopy dai client Windows o il comando parallelo dai client Linux.

Causa 4: il numero di canali SMB supera quattro

Se si usa SMB multicanale e il numero di canali che si hanno superano quattro, si ottengono prestazioni scarse. Per determinare se il numero di connessioni supera quattro, usare il cmdlet get-SmbClientConfiguration di PowerShell per visualizzare le impostazioni correnti del numero di connessioni.

Soluzione

Impostare l'impostazione di Windows per scheda di interfaccia di rete per SMB in modo che i canali totali non superino quattro. Ad esempio, se si dispone di due schede di interfaccia di rete, è possibile impostare il valore massimo per scheda di interfaccia di rete su due usando il cmdlet di PowerShell seguente: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Causa 5: Le dimensioni read-ahead sono troppo piccole (solo NFS)

A partire dalla versione 5.4 del kernel Linux, il client NFS Linux usa un valore predefinito read_ahead_kb di 128 kibibytes (KiB). Questo valore ridotto potrebbe ridurre la quantità di velocità effettiva di lettura per file di grandi dimensioni.

Soluzione

È consigliabile aumentare il valore del read_ahead_kb parametro del kernel a 15 mebibyte (MiB). Per modificare questo valore, impostare le dimensioni read-ahead in modo permanente aggiungendo una regola in udev, un gestore di dispositivi kernel Linux. Seguire questa procedura:

  1. In un editor di testo creare il file /etc/udev/rules.d/99-nfs.rules immettendo e salvando il testo seguente:

    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. In una console applicare la regola udev eseguendo il comando udevadm come utente con privilegi avanzati e ricaricando i file delle regole e altri database. Per rendere udev consapevole del nuovo file, è necessario eseguire questo comando una sola volta.

    sudo udevadm control --reload

Latenza molto elevata per le richieste

Causa

La macchina virtuale client può trovarsi in un'area diversa rispetto alla condivisione file. Un altro motivo per una latenza elevata potrebbe essere dovuto alla latenza causata dal client o dalla rete.

Soluzione

  • Eseguire l'applicazione da una macchina virtuale che si trova nella stessa area della condivisione file.
  • Per l'account di archiviazione, esaminare le metriche delle transazioni SuccessE2ELatency e SuccessServerLatency tramite Monitoraggio di Azure in portale di Azure. Una differenza elevata tra i valori delle metriche SuccessE2ELatency e SuccessServerLatency indica che la latenza è probabilmente causata dalla rete o dal client. Vedere Metriche delle transazioni nelle informazioni di riferimento sul monitoraggio dei dati dei file di Azure.

Il client non è in grado di ottenere la velocità effettiva massima supportata dalla rete

Causa

Una possibile causa è la mancanza di supporto multicanale SMB per le condivisioni file standard. Attualmente, File di Azure supporta solo un canale singolo per le condivisioni file standard, quindi è presente una sola connessione dalla macchina virtuale client al server. Questa singola connessione è ancorata a un singolo core nella macchina virtuale client, quindi la velocità effettiva massima ottenibile da una macchina virtuale è vincolata da un singolo core.

Soluzione alternativa

Rallentamento delle prestazioni in una condivisione file di Azure montata in una macchina virtuale Linux

Causa 1: memorizzazione nella cache

Una possibile causa del rallentamento delle prestazioni è la disattivazione della memorizzazione nella cache. La memorizzazione nella cache può essere utile se si accede ripetutamente a un file. In caso contrario, può essere un sovraccarico. Controllare se si sta usando la cache prima di disabilitarla.

Soluzione per la causa 1

Per controllare se la memorizzazione nella cache è disattivata, cercare la voce cache cache=.

Cache=none indica che la memorizzazione nella cache è disabilitata. Eseguire nuovamente il montaggio della condivisione usando il comando di montaggio predefinito o aggiungendo esplicitamente l'opzione cache=strict al comando di montaggio per assicurarsi che la modalità di memorizzazione nella cache predefinita o "strict" sia attivata.

In alcuni scenari, l'opzione di montaggio serverino può far sì che il comando ls esegua stat rispetto a ogni voce di directory. Questo comportamento determina una riduzione del livello delle prestazioni quando si elenca una directory di grandi dimensioni. È possibile controllare le opzioni di montaggio nella voce /etc/fstab:

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

È anche possibile controllare se vengono usate le opzioni corrette eseguendo il comando sudo mount | grep cifs e controllandone l'output. Di seguito è riportato un esempio di output:

//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)

Se l'opzione cache=strict o serverino non è presente, smontare e montare nuovamente File di Azure eseguendo il comando di montaggio dalla documentazione. Verificare quindi di nuovo che la voce /etc/fstab disponga delle opzioni corrette.

Causa 2: Limitazione

È possibile che si verifichino limitazioni e che le richieste vengano inviate a una coda. È possibile verificarlo sfruttando Archiviazione di Azure metriche in Monitoraggio di Azure. È inoltre possibile creare avvisi che informano se una condivisione è limitata o sta per essere limitata. Vedere Risolvere i problemi File di Azure creando avvisi.

Soluzione per la causa 2

Assicurarsi che l'app sia all'interno delle destinazioni di scalabilità File di Azure. Se si usano condivisioni file standard di Azure, è consigliabile passare a Premium.

La velocità effettiva nei client Linux è inferiore a quella dei client Windows

Causa

Si tratta di un problema noto relativo all'implementazione del client SMB in Linux.

Soluzione alternativa

  • Distribuire il carico tra più macchine virtuali.
  • Nella stessa macchina virtuale usare più punti di montaggio con un'opzione nosharesock e distribuire il carico tra questi punti di montaggio.
  • In Linux provare a montare con un'opzione nostrictsync per evitare di forzare lo scaricamento di SMB in ogni chiamata fsync. Per File di Azure, questa opzione non interferisce con la coerenza dei dati, ma potrebbe comportare metadati di file non aggiornati negli elenchi di directory (comando ls -l). L'esecuzione diretta di query sui metadati dei file tramite il comando stat restituirà i metadati del file più aggiornati.

Latenze elevate per carichi di lavoro a elevato utilizzo di metadati che comportano operazioni di apertura/chiusura estese

Causa

Mancanza di supporto per i lease di directory.

Soluzione alternativa

  • Se possibile, evitare di usare un handle di apertura/chiusura eccessivo nella stessa directory entro un breve periodo di tempo.
  • Per le macchine virtuali Linux, aumentare il timeout della cache delle voci di directory specificando actimeo=<sec> come opzione di montaggio. Per impostazione predefinita, il timeout è di 1 secondo, quindi un valore maggiore, ad esempio 30 secondi, potrebbe essere utile.
  • Per le macchine virtuali CentOS Linux o Red Hat Enterprise Linux (RHEL), aggiornare il sistema a CentOS Linux 8.2 o RHEL 8.2. Per altre distribuzioni Linux, aggiornare il kernel alla versione 5.0 o successiva.

Enumerazione lenta di file e cartelle

Causa

Questo problema può verificarsi se nel computer client non è disponibile una quantità di cache sufficiente per le directory di grandi dimensioni.

Soluzione

Per risolvere questo problema, modificare il valore del registro DirectoryCacheEntrySizeMax per consentire la memorizzazione nella cache di elenchi di directory di maggiori dimensioni nel computer client:

  • Posizione: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Nome valore: DirectoryCacheEntrySizeMax
  • Tipo valore: DWORD

Ad esempio, è possibile impostarlo su 0x100000 e verificare se le prestazioni migliorano.

Copia lenta di file da e verso condivisioni file di Azure

Si potrebbe verificare un rallentamento delle prestazioni quando si prova a trasferire file nel servizio File di Azure. In assenza di un requisito minimo specifico per la dimensione di I/O, è consigliabile usare 1 MiB per assicurare prestazioni ottimali.

Rallentamento della copia di file da e verso File di Azure in Windows

  • Se si conosce la dimensione finale del file che si vuole estendere con operazioni di scrittura e il software non ha problemi di compatibilità se la parte finale del file non ancora scritta contiene zeri, impostare le dimensioni del file in fase preliminare anziché lasciare che ogni operazione di scrittura venga considerata un'estensione.

  • Usare il metodo di copia corretto:

    • Usare AzCopy per i trasferimenti tra due condivisioni file.
    • Usare Robocopy tra condivisioni file in un computer locale.

Numero eccessivo di chiamate DirectoryOpen/DirectoryClose

Causa

Se il numero di chiamate DirectoryOpen/DirectoryClose è tra le principali chiamate API e non ci si aspetta che il client esegua tale numero di chiamate, il problema potrebbe essere causato dal software antivirus installato nella macchina virtuale del client di Azure.

Soluzione alternativa

Una correzione per questo problema è disponibile nell'aggiornamento della piattaforma di aprile per Windows.

SMB multicanale non viene attivato

Causa

Modifiche recenti alle impostazioni di configurazione multicanale SMB senza rimontare.

Soluzione

  • Dopo le modifiche apportate alle impostazioni di configurazione SMB multicanale o al client SMB di Windows, è necessario smontare la condivisione, attendere 60 secondi e rimontare la condivisione per attivare il multicanale.
  • Per il sistema operativo client Windows, generare un carico di I/O con profondità elevata della coda, ad esempio QD=8, ad esempio copiando un file per attivare SMB multicanale. Per il sistema operativo server, SMB multicanale viene attivato con QD=1, ovvero non appena si avvia un I/O alla condivisione.

Rallentamento delle prestazioni durante il decompressione dei file

A seconda del metodo di compressione esatto e dell'operazione di decompressione usata, le operazioni di decompressione possono essere eseguite più lentamente in una condivisione file di Azure rispetto al disco locale. Ciò è spesso dovuto al fatto che gli strumenti di decompressione eseguano una serie di operazioni di metadati nel processo di decompressione di un archivio compresso. Per ottenere prestazioni ottimali, è consigliabile copiare l'archivio compresso dalla condivisione file di Azure al disco locale, decomprimerlo e quindi usare uno strumento di copia come Robocopy (o AzCopy) per eseguire la copia nella condivisione file di Azure. L'uso di uno strumento di copia come Robocopy può compensare le prestazioni ridotte delle operazioni sui metadati in File di Azure rispetto al disco locale usando più thread per copiare i dati in parallelo.

Latenza elevata nei siti Web ospitati in condivisioni file

Causa

La notifica di modifica dei file con un numero elevato di condivisioni file può comportare latenze elevate. Ciò si verifica in genere con siti Web ospitati in condivisioni file con struttura di directory annidata completa. Uno scenario tipico è l'applicazione Web ospitata in IIS in cui è configurata la notifica di modifica dei file per ogni directory nella configurazione predefinita. Ogni modifica (ReadDirectoryChangesW) nella condivisione registrata dal client per il push di una notifica di modifica dal servizio file al client, che accetta le risorse di sistema e il problema peggiora con il numero di modifiche. Ciò può causare la limitazione delle richieste di condivisione e quindi comportare una latenza lato client più elevata.

Per confermare, è possibile usare Metriche di Azure nel portale.

  1. Nel portale di Azure passare all'account di archiviazione.
  2. Nel menu a sinistra, in Monitoraggio, selezionare Metriche.
  3. Selezionare File come spazio dei nomi delle metriche per l'ambito dell'account di archiviazione.
  4. Selezionare Transazioni come metriche.
  5. Aggiungere un filtro per ResponseType e verificare se le richieste hanno un codice di risposta ( SuccessWithThrottling per SMB o NFS) o ClientThrottlingError (per REST).

Soluzione

  • Se la notifica di modifica dei file non viene usata, disabilitare la notifica di modifica del file (preferita).

  • Aumentare la frequenza dell'intervallo di polling delle notifiche di modifica del file per ridurre il volume.

    Aggiornare l'intervallo di polling del processo di lavoro W3WP a un valore superiore (ad esempio, 10 o 30 minuti) in base alle esigenze. Impostare HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds nel registro e riavviare il processo W3WP.

  • Se la directory fisica mappata del sito Web ha una struttura di directory annidata, è possibile provare a limitare l'ambito delle notifiche di modifica dei file per ridurre il volume di notifica. Per impostazione predefinita, IIS usa la configurazione dai file Web.config nella directory fisica a cui viene eseguito il mapping della directory virtuale, nonché in qualsiasi directory figlio in tale directory fisica. Se non si vogliono usare i file Web.config nelle directory figlio, specificare false per l'attributo allowSubDirConfig nella directory virtuale. Per informazioni dettagliate, vedere questo articolo.

    Impostare l'impostazione della directory allowSubDirConfig virtuale IIS in Web.Config su false per escludere le directory figlio fisiche mappate dall'ambito.

Vedi anche

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.