Condividi tramite

Risolvere i problemi di prestazioni di File di Azure

  • Articolo

Nota

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

Nota

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 (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 Destinazioni di scalabilità di file e condivisioni 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 Limitare la limitazione della condivisione o dell'account di archiviazione.

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. È anche 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 sinistro, in Monitoraggio selezionare Metriche.

  3. Selezionare File come spazio dei nomi delle metriche 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, i tipi di risposta seguenti vengono registrati se una richiesta viene limitata a livello di account client:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Per le condivisioni file Premium, i tipi di risposta seguenti vengono registrati 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 createfileesempio , closefileopenfile, 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 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. Questo approccio funziona per scenari o scenari di scrittura/lettore singoli con più lettori e senza writer. Poiché il file system è di proprietà del client invece di File di Azure, in questo modo le operazioni sui metadati possono essere locali. La configurazione offre prestazioni simili a quella dell'archiviazione collegata direttamente locale. Tuttavia, poiché i dati si trovano 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 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 Percorso 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 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 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. Ci dovrebbero essere prestazioni molto migliori sulle 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 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, 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 è un'indicazione della latenza che è probabilmente causata dalla rete o dal client. Vedere Metriche delle transazioni in File di Azure Informazioni di riferimento sul monitoraggio dei dati.

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 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 mount per assicurarsi che la modalità di memorizzazione nella cache predefinita o "strict" sia abilitata.

In alcuni scenari, l'opzione di montaggio può causare l'esecuzione serverino 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 verificare se le opzioni corrette vengono usate eseguendo il comando e controllandone l'output sudo mount | grep cifs . 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 di nuovo File di Azure eseguendo il comando mount 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. È anche 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 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 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 non è presente una cache sufficiente nel computer client per directory di grandi dimensioni.

Soluzione

Per risolvere questo problema, modificare il valore del DirectoryCacheEntrySizeMax Registro di sistema per consentire la 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 di 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

È possibile che vengano visualizzate prestazioni lente quando si tenta di trasferire i 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 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 rendere ogni scrittura un'estensione della scrittura.

  • 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 eseleva 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 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 metrica.
  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.