Risolvere i problemi di prestazioni File di Azure

  • Articolo

Nota

CentOS a cui si fa riferimento in questo articolo è una distribuzione Linux e raggiungerà End Of Life (EOL). Prendere in considerazione l'uso e pianificare di conseguenza. Per altre informazioni, vedere Indicazioni sulla fine del ciclo di vita di CentOS.

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

Si applica a

Tipo di condivisione file SMB NFS
Condivisioni file standard (GPv2), LRS/ZRS
Condivisioni file standard (GPv2), GRS/GZRS
Condivisioni file Premium (FileStorage), LRS/ZRS

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 su 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 quando accedono alle condivisioni file di Azure per carichi di lavoro a elevato utilizzo di I/O. Assicurarsi che l'hotfix KB3114025 sia installato. Questo hotfix migliora le prestazioni degli handle di creazione e chiusura.

È possibile eseguire lo script seguente per verificare se l'hotfix è stato installato:

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

Nota

Windows Server 2012 immagini R2 in Azure Marketplace hanno KB3114025 hotfix installati per impostazione predefinita, a partire da dicembre 2015.

Il carico di lavoro viene limitato

Le richieste vengono limitate quando vengono raggiunti i limiti delle operazioni di I/O al secondo (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 delle richieste può comportare prestazioni scarse per il client.

Per comprendere i limiti per le condivisioni file standard e Premium, vedere Destinazioni di condivisione file e scalabilità file. A seconda del carico di lavoro, è spesso possibile evitare la limitazione passando da condivisioni file di Azure standard a premium.

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

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

Causa 1: la condivisione o l'account di archiviazione viene limitato

Per verificare se la condivisione o l'account di archiviazione è limitato, è possibile accedere alle metriche di Azure e usarle nel portale. È anche possibile creare avvisi che invieranno una notifica se una condivisione viene limitata o sta per essere limitata. Vedere Risolvere i problemi File di Azure creando avvisi.

Importante

Per gli account di archiviazione standard con condivisioni file di grandi dimensioni abilitate, la limitazione si verifica a livello di account. Per le condivisioni file Premium e le condivisioni file standard senza LFS abilitato, la limitazione si verifica a livello di condivisione.

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

  2. Nel riquadro sinistro, in Monitoraggio, selezionare Metriche.

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

  4. Selezionare Transazioni come metrica.

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

    Per le condivisioni file standard che non hanno condivisioni file di grandi dimensioni abilitate, vengono registrati i tipi di risposta seguenti se una richiesta viene limitata a livello di condivisione:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

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

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Per le condivisioni 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, potrebbe essere 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à 'Tipo di risposta'.

Soluzione

Causa 2: Carico di lavoro pesante per metadati o spazio dei nomi

Se la maggior parte delle richieste è incentrata sui metadati (ad createfileesempio , , openfileclosefile, queryinfoo querydirectory), la latenza sarà peggiore di 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 delle proprietà 'NOME API'.

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 nella cache dei metadati.

  • 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 sui file sui dati. Questo approccio funziona per scenari di writer/lettore singolo o scenari con più lettori e senza writer. Poiché il file system è di proprietà del client anziché File di Azure, in questo modo le operazioni sui metadati possono essere locali. L'installazione offre prestazioni simili a quelle dell'archiviazione locale collegata direttamente. Tuttavia, poiché i dati si trova in un disco rigido virtuale, non è possibile accedervi tramite altri mezzi diversi dal montaggio SMB, ad esempio l'API REST o tramite 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 e eseguirne il mapping a un'unità di rete disponibile , ad esempio Z:.
    2. Passare a Gestione disco e selezionare Azione > Create disco rigido virtuale.
    3. Impostare Percorso sull'unità di rete a cui viene eseguito il mapping della condivisione file di Azure, impostare Dimensioni disco rigido virtuale in base alle esigenze e selezionare Dimensione fissa.
    4. Seleziona OK. Al termine della 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 scegliere 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 verrà 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 di condivisione file di Azure standard in Z:e il mapping del disco rigido virtuale nell'unità E: .
    8. Le operazioni di metadati pesanti sui file nell'unità mappata al disco rigido virtuale (E:) dovrebbero avere prestazioni molto migliori rispetto all'unità mappata alla condivisione file di Azure (Z:). Se lo si desidera, dovrebbe essere possibile disconnettere l'unità di rete mappata (Z:) e comunque accedere all'unità VHD montata (E:).
    • Per montare un disco rigido virtuale in un client Windows, è anche possibile usare il Mount-DiskImage cmdlet di PowerShell.
    • Per montare un disco rigido virtuale in Linux, consultare la documentazione relativa alla distribuzione di Linux. Ecco un esempio.

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 delle applicazioni aumentando il numero di thread.
  • Passare ad 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 i quattro

Se usi SMB MultiChannel e il numero di canali che hai superato i quattro, le prestazioni saranno scarse. Per determinare se il numero di connessioni supera quattro, usare il cmdlet get-SmbClientConfiguration di PowerShell per visualizzare le impostazioni del numero di connessioni correnti.

Soluzione

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

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

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

Soluzione

È consigliabile aumentare il valore del parametro del read_ahead_kb 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. attenersi alla seguente 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 avanzato 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 dalla condivisione file. Un altro motivo per la 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 è un'indicazione della latenza probabilmente causata dalla rete o dal client. Vedere Metriche delle transazioni in File di Azure informazioni di riferimento per i dati di monitoraggio.

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

Causa

Una potenziale 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 esiste 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 raggiungibile da una macchina virtuale è associata a un singolo core.

Soluzione alternativa

Prestazioni lente in una condivisione file di Azure montata in una macchina virtuale Linux

Causa 1: Memorizzazione nella cache

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

Soluzione per la causa 1

Per verificare se la memorizzazione nella cache è disabilitata, cercare la cache= voce .

Cache=none indica che la memorizzazione nella cache è disabilitata. Rimontare la condivisione usando il comando di montaggio predefinito o aggiungendo in modo esplicito l'opzione cache=strict al comando di montaggio per assicurarsi che la modalità di memorizzazione nella cache predefinita o la modalità di memorizzazione nella cache "strict" sia abilitata.

In alcuni scenari, l'opzione serverino di montaggio può causare l'esecuzione stat del ls comando su ogni voce di directory. Questo comportamento comporta una riduzione 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 sudo mount | grep cifs comando e controllandone l'output. Di seguito è riportato un output di esempio:

//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 di nuovo File di Azure eseguendo il comando mount dalla documentazione. Verificare quindi che la voce /etc/fstab abbia le opzioni corrette.

Causa 2: Limitazione delle richieste

È possibile che si verifichi una limitazione delle richieste e che le richieste vengano inviate a una coda. È possibile verificarlo sfruttando le metriche di Archiviazione di Azure in Monitoraggio di Azure. È anche possibile creare avvisi che notificano se una condivisione viene limitata o sta per essere limitata. Vedere Risolvere i problemi File di Azure creando avvisi.

Soluzione per la causa 2

Assicurarsi che l'app si trova all'interno delle destinazioni di scalabilità File di Azure. Se si usano condivisioni file di Azure standard, è 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 eseguire il montaggio con un'opzione nostrictsync per evitare di forzare lo scaricamento di SMB in ogni fsync chiamata. 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 (ls -l comando ). L'esecuzione diretta di query sui metadati dei file tramite il stat comando restituirà i metadati del file più aggiornati.

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

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 la cache nel computer client non è sufficiente per directory di grandi dimensioni.

Soluzione

Per risolvere questo problema, modificare il valore del Registro di sistema per consentire la DirectoryCacheEntrySizeMax memorizzazione nella cache di elenchi di directory più grandi nel computer client:

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

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

Copia lenta dei file da e verso condivisioni file di Azure

Le prestazioni potrebbero risultare lente quando si tenta di trasferire i file nel servizio File di Azure. Se non si dispone di un requisito specifico per le dimensioni minime di I/O, è consigliabile usare 1 MiB come dimensione di I/O per ottenere prestazioni ottimali.

Copia lenta dei file da e verso File di Azure in Windows

  • Se si conoscono le dimensioni finali di un file che si sta estendendo con le scritture e il software non presenta problemi di compatibilità quando la coda non scritta nel file contiene zeri, impostare le dimensioni del file in anticipo invece di fare in modo che ogni scrittura venga estesa.

  • Usare il metodo di copia corretto:

    • Usare AzCopy per qualsiasi trasferimento tra due condivisioni file.
    • Usare Robocopy tra condivisioni file in un computer locale.

Chiamate eccessive di DirectoryOpen/DirectoryClose

Causa

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

Soluzione alternativa

Una correzione per questo problema è disponibile in April Platform Update per Windows.

SMB multicanale non viene attivato

Causa

Modifiche recenti alle impostazioni di configurazione multicanale SMB senza un rimontaggio.

Soluzione

  • Dopo le modifiche apportate alle impostazioni di configurazione multicanale SMB del client O dell'account 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 il carico di I/O con una profondità elevata della coda, ad esempio QD=8, ad esempio copiando un file per attivare SMB multicanale. Per il sistema operativo del server, SMB multicanale viene attivato con QD=1, il che significa che non appena si avviano le operazioni di I/O nella condivisione.

Prestazioni lente durante l'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. Questo avviene spesso perché gli strumenti di decompressione eseguono una serie di operazioni sui metadati durante il processo di decompressione di un archivio compresso. Per ottenere prestazioni ottimali, è consigliabile copiare l'archivio compresso dalla condivisione file di Azure nel disco locale, decomprimerlo e quindi usare uno strumento di copia come Robocopy (o AzCopy) per copiare di nuovo nella condivisione file di Azure. L'uso di uno strumento di copia come Robocopy può compensare la riduzione delle prestazioni 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 del file con numero elevato nelle condivisioni file può comportare latenze elevate. Ciò si verifica in genere con siti Web ospitati in condivisioni file con struttura di directory annidata approfondita. Uno scenario tipico è l'applicazione Web ospitata in IIS in cui viene configurata la notifica di modifica dei file per ogni directory nella configurazione predefinita. Ogni modifica (ReadDirectoryChangesW) sulla condivisione per cui il client è registrato esegue 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 condivisioni e quindi una latenza sul 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 della metrica per l'ambito dell'account di archiviazione.
  4. Selezionare Transazioni come metrica.
  5. Aggiungere un filtro per ResponseType e verificare se le richieste hanno un codice di SuccessWithThrottling risposta (per SMB o NFS) o ClientThrottlingError (per REST).

Soluzione

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

  • Aumentare la frequenza dell'intervallo di polling delle notifiche di modifica 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\ConfigPollMilliSecondsnel Registro di sistema 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 file per ridurre il volume di notifica. Per impostazione predefinita, IIS usa la configurazione da Web.config file nella directory fisica a cui viene eseguito il mapping della directory virtuale, nonché in qualsiasi directory figlio in tale directory fisica. Se non si vuole usare Web.config file nelle directory figlio, specificare false per l'attributo allowSubDirConfig nella directory virtuale. Altri dettagli sono disponibili qui.

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

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