Archiviazione Premium di Azure: progettata per prestazioni elevate
Si applica a: ✔️ macchine virtuali Linux ✔️ macchine virtuali Windows ✔️ set di scalabilità flessibili ✔️ set di scalabilità uniformi
Questo articolo fornisce linee guida per la creazione di applicazioni ad alte prestazioni usando l'archiviazione Premium di Azure. È possibile usare le istruzioni disponibili in questo documento insieme alle procedure consigliate per le prestazioni applicabili alle tecnologie usate dall'applicazione. Per illustrare le linee guida, viene usato SQL Server in esecuzione nell'archiviazione Premium come esempio in questo documento.
Anche se vengono affrontati gli scenari di prestazioni per il livello di archiviazione in questo articolo, è necessario ottimizzare il livello dell'applicazione. Ad esempio, se si ospita una farm di SharePoint nell'archiviazione Premium, è possibile usare gli esempi di SQL Server di questo articolo per ottimizzare il server di database. È anche possibile ottimizzare il server Web e il server applicazioni di SharePoint Farm per ottenere il massimo livello di prestazioni.
Questo articolo consente di rispondere alle domande comuni seguenti sull'ottimizzazione delle prestazioni dell'applicazione nell'archiviazione Premium:
- Come è possibile misurare le prestazioni dell'applicazione?
- Perché non vengono visualizzate prestazioni elevate previste?
- Quali fattori influenzano le prestazioni dell'applicazione nell'archiviazione Premium?
- In che modo questi fattori influiscono sulle prestazioni dell'applicazione nell'archiviazione Premium?
- Come è possibile ottimizzare le operazioni di input/output al secondo (IOPS), larghezza di banda e latenza?
Queste linee guida vengono fornite specificamente per l'archiviazione Premium perché i carichi di lavoro in esecuzione nell'archiviazione Premium sono estremamente sensibili alle prestazioni. Vengono forniti esempi in base alle esigenze. È anche possibile applicare alcune di queste linee guida alle applicazioni in esecuzione nelle macchine virtuali IaaS (Infrastructure as a Service) con dischi di archiviazione standard.
Nota
A volte ciò che sembra essere un problema di prestazioni del disco è in realtà un collo di bottiglia di rete. In queste situazioni, è consigliabile ottimizzare le prestazioni di rete.
Per eseguire il benchmark del disco, vedere gli articoli seguenti:
- Per Linux: Eseguire il benchmark dell'applicazione in Archiviazione su disco di Azure
- Per Windows: Eseguire il benchmark di un disco
Se la macchina virtuale supporta la rete accelerata, assicurarsi che sia abilitata. Se non è abilitata, è possibile abilitarla in macchine virtuali già distribuite sia in Windows che in Linux.
Prima di iniziare, se non si ha familiarità con l'archiviazione Premium, leggere Selezionare un tipo di disco di Azure per le macchine virtuali IaaS e obiettivi di scalabilità per gli account di archiviazione BLOB di pagine Premium.
Indicatori di prestazioni dell'applicazione
Si valuta se un'applicazione ha prestazioni ottimali o meno usando indicatori di prestazioni come:
- Velocità con cui un'applicazione sta elaborando una richiesta utente.
- Quantità di dati che un'applicazione elabora per ogni richiesta.
- Numero di richieste elaborate da un'applicazione in un periodo di tempo specifico.
- Per quanto tempo un utente deve attendere di ricevere una risposta dopo l'invio della richiesta.
I termini tecnici per questi indicatori di prestazioni sono operazioni di I/O al secondo, velocità effettiva o larghezza di banda e latenza.
In questa sezione vengono illustrati gli indicatori di prestazioni comuni nel contesto dell'archiviazione Premium. Nella sezione Elenco di controllo delle applicazioni prestazioni per i dischi si apprenderà come misurare questi indicatori di prestazioni per l'applicazione. Più avanti in Ottimizzare le prestazioni dell'applicazione vengono illustrati i fattori che influiscono su questi indicatori di prestazioni e consigli per ottimizzarli.
IOPS
Le operazioni di I/O al secondo sono il numero di richieste inviate dall'applicazione ai dischi di archiviazione in un secondo. Un'operazione di input/output può essere di lettura o di scrittura, sequenziale o casuale. Le applicazioni OLTP (Online Transaction Processing) come un sito Web online devono elaborare immediatamente molte richieste utente simultanee. Le richieste utente sono transazioni di database a elevato utilizzo di aggiornamento e inserimento, che l'applicazione deve elaborare rapidamente. Per questo motivo, le applicazioni OLTP richiedono operazioni di I/O al secondo molto elevate.
Le applicazioni OLTP gestiscono milioni di richieste di I/O piccole e casuali. Se si crea un'applicazione di questo tipo, sarà necessario progettare l'infrastruttura dell'applicazione in modo che sia ottimizzata per IOPS. Per altre informazioni su tutti i fattori da considerare per ottenere operazioni di I/O al secondo elevate, vedere Ottimizzare le prestazioni dell'applicazione.
Quando si collega un disco di archiviazione Premium alla macchina virtuale su larga scala, Azure effettua il provisioning di un numero garantito di operazioni di I/O al secondo in base alla specifica del disco. Ad esempio, un disco P50 effettua il provisioning di 7.500 operazioni di I/O al secondo. Ogni dimensione di macchina virtuale su larga scala ha anche un limite di operazioni di I/O al secondo specifico che può sostenere. Ad esempio, una macchina virtuale GS5 Standard ha un limite di 80.000 operazioni di I/O al secondo.
Velocità effettiva
La velocità effettiva o la larghezza di banda sono la quantità di dati inviati dall'applicazione ai dischi di archiviazione in un intervallo specificato. Se l'applicazione esegue operazioni di input/output con grandi dimensioni di unità di I/O, richiede una velocità effettiva elevata. Le applicazioni data warehouse tendono a eseguire operazioni a elevato utilizzo di analisi che accedono a grandi porzioni di dati alla volta ed eseguono in genere operazioni bulk. In altri termini, queste applicazioni richiedono una velocità effettiva più elevata. Se si crea un'applicazione di questo tipo, sarà necessario progettarne l'infrastruttura in modo che sia ottimizzata per la velocità effettiva. Nella sezione successiva vengono illustrati i fattori che è necessario ottimizzare per ottenere questa ottimizzazione.
Quando si collega un disco di archiviazione Premium a una macchina virtuale su larga scala, Azure effettua il provisioning della velocità effettiva in base a tale specifica del disco. Ad esempio, un disco P50 effettua il provisioning della velocità effettiva del disco da 250 MB/sec. Ogni dimensione di macchina virtuale su larga scala ha anche un limite di velocità effettiva specifico che può sostenere. Ad esempio, la macchina virtuale GS5 Standard ha una velocità effettiva massima di 2.000 MB/sec.
Esiste una relazione tra velocità effettiva e operazioni di I/O al secondo, come illustrato nella formula seguente.
È importante determinare la velocità effettiva ottimale e i valori di IOPS richiesti dall'applicazione. Quando si tenta di ottimizzarne uno, anche l'altro è interessato. Per altre informazioni sull'ottimizzazione delle operazioni di I/O al secondo e della velocità effettiva, vedere Ottimizzare le prestazioni dell'applicazione.
Latenza
La latenza è il tempo necessario per un'applicazione per ricevere una singola richiesta, inviarla ai dischi di archiviazione e inviare la risposta al client. La latenza è una misura essenziale delle prestazioni di un'applicazione, oltre a IOPS e velocità effettiva. La latenza di un disco di archiviazione Premium è il tempo necessario per recuperare le informazioni per una richiesta e comunicarla di nuovo all'applicazione. L'archiviazione Premium offre latenze costantemente basse. I dischi Premium sono progettati per fornire latenze di millisecondi a cifra singola per la maggior parte delle operazioni di I/O. Se si abilita la memorizzazione nella cache dell'host ReadOnly nei dischi di archiviazione Premium, è possibile ottenere una latenza di lettura molto inferiore. Per altre informazioni sulla memorizzazione nella cache del disco, vedere Memorizzazione nella cache del disco.
Quando si ottimizza l'applicazione per ottenere operazioni di I/O al secondo e velocità effettiva più elevate, influisce sulla latenza dell'applicazione. Dopo aver ottimizzato le prestazioni dell'applicazione, valutare la latenza dell'applicazione per evitare un comportamento imprevisto di latenza elevata.
Alcune operazioni del piano di controllo sui dischi gestiti potrebbero spostare il disco da un percorso di archiviazione a un altro. Lo spostamento del disco tra posizioni di archiviazione viene orchestrato tramite una copia in background dei dati, che può richiedere diverse ore per il completamento. In genere, il tempo è inferiore a 24 ore a seconda della quantità di dati nei dischi. Durante questo periodo, l'applicazione può riscontrare una latenza di lettura superiore al solito perché alcune letture possono essere reindirizzate alla posizione originale e richiedere più tempo per il completamento.
Durante una copia in background, non c'è alcun effetto sulla latenza di scrittura per la maggior parte dei tipi di disco. Per i dischi SSD Premium v2 e Ultra, se il disco ha dimensioni di settore 4K, si verifica una latenza di lettura superiore. Se il disco ha dimensioni del settore 512e, si verifica una latenza di lettura e scrittura superiore.
Le operazioni del piano di controllo seguenti potrebbero spostare il disco tra posizioni di archiviazione e causare una maggiore latenza:
- Aggiornare il tipo di archiviazione.
- Scollegare e collegare un disco da una macchina virtuale a un'altra.
- Creare un disco gestito da un disco rigido virtuale.
- Creare un disco gestito da uno snapshot.
- Convertire dischi non gestiti a Managed Disks.
Elenco di controllo delle applicazioni per le prestazioni per i dischi
Il primo passaggio per la progettazione di applicazioni ad alte prestazioni in esecuzione nell'archiviazione Premium è comprendere i requisiti di prestazioni dell'applicazione. Dopo la raccolta dei requisiti relativi alle prestazioni, sarà possibile ottimizzare l'applicazione per ottenere le prestazioni più elevate possibili.
Nella sezione precedente sono stati illustrati gli indicatori di prestazioni comuni: operazioni di I/O al secondo, velocità effettiva e latenza. È necessario identificare gli indicatori di prestazioni essenziali per consentire all'applicazione di offrire l'esperienza utente desiderata. Ad esempio, un valore elevato per IOPS è molto importante per le applicazioni OLTP che elaborano milioni di transazioni al secondo. La velocità effettiva elevata è fondamentale per le applicazioni del data warehouse che elaborano grandi quantità di dati in un secondo. La latenza estremamente bassa è fondamentale per applicazioni in tempo reale come siti Web di streaming video live.
È quindi necessario misurare i requisiti massimi relativi alle prestazioni per l'intero ciclo di vita dell'applicazione. Usare l'elenco di controllo di esempio seguente come inizio. Registrare i requisiti di prestazioni massimi durante i periodi di carico di lavoro normali, di picco e di minore ora. Identificando i requisiti per tutti i livelli di carico di lavoro, è possibile determinare il requisito di prestazioni complessivo dell'applicazione.
Ad esempio, il carico di lavoro normale di un sito Web di e-commerce è le transazioni che serve durante la maggior parte dei giorni in un anno. Il carico di lavoro massimo del sito Web è rappresentato dalle transazioni che serve durante le stagioni festivi o eventi di vendita speciali. Il carico di lavoro di picco viene in genere riscontrato per un periodo limitato, ma può richiedere all'applicazione di ridimensionare due o più volte il normale funzionamento. Occorre trovare i requisiti relativi al 50° percentile, al 90° percentile e al 99° percentile. Queste informazioni consentono di filtrare gli outlier nei requisiti di prestazioni ed è possibile concentrarsi sull'ottimizzazione dei valori corretti.
Elenco di controllo per i requisiti relativi alle prestazioni dell'applicazione
| Requisiti per le prestazioni | 50 percentile | 90 percentile | 99 percentile |
|---|---|---|---|
| Numero massimo di transazioni al secondo | |||
| % di operazioni di lettura | |||
| % di operazioni di scrittura | |||
| % di operazioni casuali | |||
| % di operazioni sequenziali | |||
| Dimensioni della richiesta di I/O | |||
| Velocità effettiva media | |||
| Velocità effettiva massima | |||
| Latenza minima | |||
| Latenza media | |||
| CPU massima | |||
| Utilizzo medio CPU | |||
| Memoria massima | |||
| Memoria media | |||
| Profondità della coda |
Nota
Valutare la possibilità di ridimensionare questi numeri in base alla crescita futura prevista dell'applicazione. È consigliabile pianificare in anticipo la crescita perché potrebbe essere più difficile modificare l'infrastruttura per migliorare le prestazioni in un secondo momento.
Se si dispone di un'applicazione esistente e si vuole passare all'archiviazione Premium, compilare prima di tutto l'elenco di controllo precedente per l'applicazione esistente. Compilare quindi un prototipo dell'applicazione nell'archiviazione Premium e progettare l'applicazione in base alle linee guida descritte in Ottimizzare le prestazioni dell'applicazione. L'articolo successivo illustra gli strumenti disponibili per raccogliere le misurazioni relative alle prestazioni.
Contatori per misurare i requisiti relativi alle prestazioni per l'applicazione
Il modo migliore per misurare i requisiti di prestazioni dell'applicazione consiste nell'usare PerfMongli strumenti di monitoraggio forniti dal sistema operativo del server. È possibile usare PerfMon per Windows e iostat per Linux. Questi strumenti acquisiscono i contatori corrispondenti a ogni misura illustrata nella sezione precedente. È necessario acquisire i valori di questi contatori quando l'applicazione esegue i carichi di lavoro normali, di picco e di minore ora.
I PerfMon contatori sono disponibili per processore, memoria e ogni disco logico e disco fisico del server. Quando si usano dischi di Archiviazione Premium con una VM, i contatori per dischi fisici sono relativi a ogni disco di Archiviazione Premium e i contatori per dischi logici sono relativi a ogni volume creato nei dischi di Archiviazione Premium. È necessario acquisire i valori per i dischi che ospitano il carico di lavoro dell'applicazione. Se è presente un mapping uno-a-uno tra dischi logici e fisici, è possibile fare riferimento ai contatori dei dischi fisici. In caso contrario, fare riferimento ai contatori dei dischi logici.
In Linux il iostat comando genera un report sull'utilizzo della CPU e del disco. Il report di utilizzo dischi fornisce statistiche relative al singolo dispositivo o alla singola partizione. Se è presente un server di database con dati e log in dischi separati, raccogliere questi dati per entrambi i dischi. La tabella seguente descrive i contatori per dischi, processori e memoria.
| Contatore | Descrizione | PerfMon | iostat |
|---|---|---|---|
| Operazioni di I/O al secondo o operazioni al secondo | Numero di richieste di I/O inviate al disco di archiviazione/sec | Letture disco/sec Scritture su disco/sec |
Tps r/s w/s |
| Letture e scritture del disco | % delle operazioni di lettura e scrittura eseguite sul disco | % Tempo di lettura disco % Tempo di scrittura su disco |
r/s w/s |
| Velocità effettiva | Quantità di dati letti o scritti sul disco/sec | Byte letti dal disco/sec Byte di scrittura disco/sec |
kB_read/s kB_wrtn/s |
| Latenza | Tempo totale per completare una richiesta di I/O su disco | Disco medio sec/lettura Disco medio sec/scrittura |
aspettare svctm |
| Dimensioni di I/O | Dimensioni delle richieste di I/O nei dischi di archiviazione | Byte/lettura medi del disco Byte/scrittura medi del disco |
avgrq-sz |
| Profondità della coda | Numero di richieste di I/O in sospeso in attesa di lettura o scrittura nel disco di archiviazione | Lunghezza della coda del disco corrente | avgqu-sz |
| Memoria massima | Quantità di memoria necessaria per eseguire l'applicazione senza problemi | % Byte di cui è stato eseguito il commit in uso | Use vmstat |
| CPU massima | Quantità di CPU necessaria per eseguire l'applicazione senza problemi | % tempo processore | %util |
Altre informazioni su iostat e PerfMon.
Ottimizzare le prestazioni delle applicazioni
I fattori principali che influenzano le prestazioni di un'applicazione in esecuzione nell'archiviazione Premium sono la natura delle richieste di I/O, le dimensioni della macchina virtuale, le dimensioni del disco, il numero di dischi, la memorizzazione nella cache del disco, il multithreading e la profondità della coda. È possibile controllare alcuni di questi fattori con manopole fornite dal sistema.
La maggior parte delle applicazioni potrebbe non offrire un'opzione per modificare direttamente le dimensioni di I/O e la profondità della coda. Ad esempio, se si usa SQL Server, non è possibile scegliere le dimensioni di I/O e la profondità della coda. SQL Server sceglie i valori ottimali per le dimensioni di I/O e la profondità della coda per ottenere il massimo livello di prestazioni. È importante comprendere gli effetti di entrambi i tipi di fattori sulle prestazioni dell'applicazione in modo da poter effettuare il provisioning di risorse appropriate per soddisfare le esigenze di prestazioni.
In questa sezione fare riferimento all'elenco di controllo dei requisiti dell'applicazione creato per identificare quanto è necessario ottimizzare le prestazioni dell'applicazione. In base all'elenco di controllo, è possibile determinare quali fattori di questa sezione è necessario ottimizzare.
Per verificare gli effetti di ogni fattore sulle prestazioni dell'applicazione, eseguire gli strumenti di benchmarking sulla configurazione dell'applicazione. Per la procedura per eseguire strumenti di benchmarking comuni nelle macchine virtuali Windows e Linux, vedere gli articoli sul benchmarking alla fine di questo documento.
Breve panoramica su come ottimizzare IOPS, velocità effettiva e latenza
La tabella seguente riepiloga i fattori di prestazioni e i passaggi necessari per ottimizzare operazioni di I/O al secondo, velocità effettiva e latenza. Le sezioni che seguono questo riepilogo descrivono ogni fattore in modo più approfondito.
Per altre informazioni sulle dimensioni delle macchine virtuali e sulle operazioni di I/O al secondo, velocità effettiva e latenza disponibili per ogni tipo di macchina virtuale, vedere Dimensioni per le macchine virtuali in Azure.
| Fattori relativi alle prestazioni | Operazioni di I/O al secondo | Velocità effettiva | Latenza |
|---|---|---|---|
| Scenario di esempio | Applicazione OLTP aziendale che richiede una frequenza molto elevata di transazioni al secondo. | Applicazione aziendale di tipo data warehouse che elabora quantità elevate di dati. | Applicazioni quasi in tempo reale che necessitano di risposte immediate alle richieste degli utenti, ad esempio i giochi online. |
| Fattori relativi alle prestazioni | |||
| Dimensioni di I/O | Le dimensioni di I/O inferiori producono operazioni di I/O superiori. | Le dimensioni di I/O maggiori producono una velocità effettiva maggiore. | |
| Dimensioni della VM | Usare una dimensione di VM che offre IOPS superiori ai requisiti dell'applicazione. | Usare una dimensione di macchina virtuale con un limite di velocità effettiva maggiore del requisito dell'applicazione. | Usare una dimensione di VM che offre limiti di ridimensionamento superiori ai requisiti dell'applicazione. |
| Dimensioni disco | Usare una dimensione di disco che offre IOPS superiori ai requisiti dell'applicazione. | Usare una dimensione del disco con un limite di velocità effettiva maggiore del requisito dell'applicazione. | Usare una dimensione di disco che offre limiti di ridimensionamento superiori ai requisiti dell'applicazione. |
| Limiti di scalabilità di macchine virtuali e dischi | Il limite di operazioni di I/O al secondo delle dimensioni della macchina virtuale scelta deve essere maggiore del totale di operazioni di I/O al secondo basate sui dischi di archiviazione collegati. | Il limite di velocità effettiva delle dimensioni della macchina virtuale scelta deve essere maggiore della velocità effettiva totale guidata dai dischi di archiviazione Premium collegati. | I limiti di scalabilità delle dimensioni della macchina virtuale scelta devono essere superiori ai limiti di scalabilità totali dei dischi di archiviazione Premium collegati. |
| Memorizzazione nella cache del disco | Abilitare la cache ReadOnly nei dischi di archiviazione Premium con operazioni di lettura elevate per ottenere operazioni di I/O al secondo di lettura superiori. | Abilitare la cache ReadOnly nei dischi di archiviazione Premium con operazioni di lettura elevate per ottenere latenze di lettura molto basse. | |
| Striping del disco | Usare più dischi ed eseguirne lo striping insieme per ottenere un limite combinato di operazioni di I/O al secondo e velocità effettiva più elevate. Il limite combinato per ogni VM deve essere superiore ai limiti combinati dei dischi Premium collegati. | ||
| Dimensioni di striping | Dimensioni di striping ridotte per il modello di I/O casuale ridotto visualizzato nelle applicazioni OLTP. Ad esempio, usare una dimensione di striping di 64 KB per un'applicazione OLTP di SQL Server. | Dimensioni di striping maggiori per il modello di I/O sequenziale di grandi dimensioni visualizzato nelle applicazioni del data warehouse. Ad esempio, usare una dimensione di striping di 256 KB per un'applicazione di SQL Server Data Warehouse. | |
| Multithreading | Usare il multithreading per eseguire il push di un numero più elevato di richieste nell'archiviazione Premium per portare a operazioni di I/O al secondo e velocità effettiva più elevate. Ad esempio, in SQL Server impostare un valore MAXDOP elevato per allocare più CPU a SQL Server. | ||
| Profondità della coda | Una maggiore profondità della coda produce operazioni di I/O al secondo più elevate. | Una maggiore profondità della coda produce una velocità effettiva più elevata. | La profondità della coda più piccola produce latenze inferiori. |
Natura delle richieste di I/O
Una richiesta di I/O è un'unità di operazione di input/output eseguita dall'applicazione. L'identificazione della natura delle richieste di I/O, casuali o sequenziali, di lettura o scrittura, di piccole o grandi dimensioni, consente di determinare i requisiti di prestazioni dell'applicazione. È importante comprendere la natura delle richieste di I/O per prendere le decisioni giuste quando si progetta l'infrastruttura dell'applicazione. Le operazioni di I/O devono essere distribuite in modo uniforme per ottenere le migliori prestazioni possibili.
Le dimensioni di I/O sono uno dei fattori più importanti. Le dimensioni di I/O sono le dimensioni della richiesta di operazione di input/output generata dall'applicazione. Le dimensioni di I/O influiscono in modo significativo sulle prestazioni, soprattutto sulle operazioni di I/O al secondo e sulla larghezza di banda che l'applicazione può ottenere. La formula seguente illustra la relazione tra operazioni di I/O al secondo, dimensioni di I/O e larghezza di banda/velocità effettiva.
Alcune applicazioni consentono di modificare le dimensioni di I/O, mentre alcune applicazioni non lo sono. Ad esempio, SQL Server determina le dimensioni di I/O ottimali e non fornisce agli utenti alcuna manopola per modificarla. D'altra parte, Oracle fornisce un parametro denominato DB_BLOCK_SIZE, che è possibile usare per configurare le dimensioni della richiesta di I/O del database.
Se si usa un'applicazione, che non consente di modificare le dimensioni di I/O, usare le linee guida in questo articolo per ottimizzare l'indicatore KPI delle prestazioni più rilevante per l'applicazione. Ad esempio:
- Un'applicazione OLTP genera milioni di richieste di I/O piccole e casuali. Per gestire questi tipi di richieste di I/O, è necessario progettare l'infrastruttura dell'applicazione per ottenere operazioni di I/O al secondo più elevate.
- Un'applicazione di data warehousing genera richieste di I/O di grandi dimensioni e sequenziali. Per gestire questi tipi di richieste di I/O, è necessario progettare l'infrastruttura dell'applicazione per ottenere una maggiore larghezza di banda o velocità effettiva.
Se si usa un'applicazione che consente di modificare le dimensioni di I/O, usare questa regola generale per le dimensioni di I/O oltre ad altre linee guida sulle prestazioni:
- Dimensioni di I/O inferiori per ottenere operazioni di I/O superiori. Ad esempio, 8 KB per un'applicazione OLTP.
- Dimensioni di I/O maggiori per ottenere una maggiore larghezza di banda/velocità effettiva. Ad esempio, 1.024 KB per un'applicazione data warehouse.
Di seguito è riportato un esempio di come calcolare le operazioni di I/O al secondo e la velocità effettiva/larghezza di banda per l'applicazione.
Si consideri un'applicazione che usa un disco P30. Il numero massimo di operazioni di I/O al secondo e velocità effettiva/larghezza di banda che un disco P30 può raggiungere è rispettivamente di 5.000 operazioni di I/O al secondo e 200 MB/sec. Se l'applicazione richiede il numero massimo di operazioni di I/O dal disco P30 e si usano dimensioni di I/O inferiori, ad esempio 8 KB, la larghezza di banda risultante che è possibile ottenere è 40 MB/sec. Se l'applicazione richiede la velocità effettiva/larghezza di banda massima da un disco P30 e si usano dimensioni di I/O maggiori, ad esempio 1.024 KB, le operazioni di I/O al secondo risultanti sono minori, ad esempio 200 operazioni di I/O al secondo.
Ottimizzare le dimensioni di I/O in modo che soddisfi i requisiti di I/O al secondo e velocità effettiva/larghezza di banda dell'applicazione. La tabella seguente riepiloga le diverse dimensioni di I/O e le operazioni di I/O corrispondenti e la velocità effettiva per un disco P30.
| Requisito dell'applicazione | Dimensioni di I/O | IOPS | Velocità effettiva/Larghezza di banda |
|---|---|---|---|
| Numero massimo di IOPS | 8 KB | 5,000 | 40 MB/sec |
| Velocità effettiva massima | 1.024 KB | 200 | 200 MB/sec |
| Velocità effettiva massima + operazioni di I/O al secondo elevate | 64 kB | 3.200 | 200 MB/sec |
| Numero massimo di operazioni di I/O al secondo e velocità effettiva elevata | 32 KB | 5,000 | 160 MB/sec |
Per ottenere operazioni di I/O al secondo e larghezza di banda superiori al valore massimo di un singolo disco di archiviazione Premium, usare più dischi Premium con striping. Ad esempio, eseguire lo striping di due dischi P30 per ottenere un numero combinato di operazioni di I/O al secondo pari a 10.000 operazioni di I/O al secondo o una velocità effettiva combinata di 400 MB/sec. Come illustrato nella sezione successiva, è necessario usare una dimensione di macchina virtuale che supporti le operazioni di I/O al secondo e la velocità effettiva combinate del disco.
Nota
Con l'aumento delle operazioni di I/O al secondo o della velocità effettiva, aumenta anche l'altro. Assicurarsi di non raggiungere i limiti di velocità effettiva o operazioni di I/O al secondo del disco o della macchina virtuale quando si aumenta uno.
Per verificare gli effetti delle dimensioni di I/O sulle prestazioni dell'applicazione, è possibile eseguire strumenti di benchmarking nella macchina virtuale e nei dischi. Creare più esecuzioni di test e usare dimensioni di I/O diverse per ogni esecuzione per visualizzare l'effetto. Per altre informazioni, vedere gli articoli di benchmarking alla fine di questo documento.
Dimensioni delle macchine virtuali su larga scala
Quando si inizia a progettare un'applicazione, una delle prime operazioni da eseguire consiste nel scegliere una macchina virtuale per ospitare l'applicazione. L'archiviazione Premium include dimensioni di macchine virtuali su larga scala che possono eseguire applicazioni che richiedono una potenza di calcolo superiore e prestazioni di I/O del disco locale elevate. Queste macchine virtuali offrono processori più veloci, un rapporto memoria-core superiore e un'unità SSD (Solid State Drive) per il disco locale. Esempi di macchine virtuali su larga scala che supportano l'archiviazione Premium sono le macchine virtuali serie DS e GS.
Le macchine virtuali su larga scala sono disponibili in dimensioni diverse con un numero diverso di core CPU, memoria, sistema operativo e dimensioni temporanee del disco. Ogni dimensione della macchina virtuale ha anche un numero massimo di dischi dati che è possibile collegare alla macchina virtuale. La dimensione della macchina virtuale scelta influisce sulla quantità di elaborazione, memoria e capacità di archiviazione disponibili per l'applicazione. Influisce anche sul costo di calcolo e archiviazione. Ad esempio, le specifiche seguenti riguardano le dimensioni massime della macchina virtuale in una serie DS e una serie GS.
| Dimensioni della VM | Core CPU | Memoria | Dimensioni di disco della VM | Numero massimo di dischi dati | Dimensioni della cache | IOPS | Limiti di I/O della cache della larghezza di banda |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | SISTEMA OPERATIVO = 1.023 GB SSD locale = 224 GB |
32 | 576 GB | 50.000 operazioni di I/O al secondo 512 MB/sec |
4.000 operazioni di I/O al secondo e 33 MB/sec |
| Standard_GS5 | 32 | 448 GB | SISTEMA OPERATIVO = 1.023 GB SSD locale = 896 GB |
64 | 4224 GB | 80.000 operazioni di I/O al secondo 2.000 MB/sec |
5.000 operazioni di I/O al secondo e 50 MB/sec |
Per visualizzare un elenco completo di tutte le dimensioni di macchine virtuali di Azure disponibili, vedere Dimensioni per le macchine virtuali in Azure. Scegliere una dimensione di VM in grado di soddisfare e adeguarsi ai requisiti relativi alle prestazioni dell'applicazione. Tenere conto anche delle considerazioni importanti seguenti quando si scelgono le dimensioni delle macchine virtuali.
Limiti di scalabilità
I limiti massimi per IOPS per ogni VM e ogni disco sono diversi e indipendenti gli uni dagli altri. Assicurarsi che l'applicazione stia guidando operazioni di I/O al secondo entro i limiti della macchina virtuale e i dischi Premium collegati. In caso contrario, la limitazione delle prestazioni dell'applicazione è limitata.
Si supponga, ad esempio, che i requisiti dell'applicazione siano pari a 4.000 IOPS. Per ottenere questo livello, effettuare il provisioning di un disco P30 in una macchina virtuale DS1. Il disco P30 può raggiungere fino a 5.000 IOPS. La VM DS1 è tuttavia limitata a 3.200 IOPS. Pertanto, le prestazioni dell'applicazione sono vincolate dal limite di macchine virtuali a 3.200 operazioni di I/O al secondo e le prestazioni sono ridotte. Per evitare questa situazione, scegliere una macchina virtuale e una dimensione del disco che soddisfano entrambi i requisiti dell'applicazione.
Costo dell'operazione
In molti casi, è possibile che il costo complessivo dell'operazione usando l'archiviazione Premium sia inferiore rispetto all'uso dell'archiviazione standard.
Ad esempio, si consideri un'applicazione che richiede 16.000 IOPS. Per ottenere queste prestazioni, è necessaria una macchina virtuale IaaS di Azure Standard_D14, che può offrire un numero massimo di operazioni di I/O al secondo pari a 16.000 usando 32 dischi di archiviazione standard da 1 TB. Ogni disco di archiviazione Standard da 1 TB può raggiungere un valore massimo di 500 IOPS.
- Il costo stimato di questa macchina virtuale al mese è di $ 1.570.
- Il costo mensile di 32 dischi di archiviazione standard è di $ 1.638.
- Il costo mensile stimato è di $ 3.208.
Se è stata ospitata la stessa applicazione nell'archiviazione Premium, sono necessarie dimensioni di macchina virtuale inferiori e meno dischi di archiviazione Premium, riducendo il costo complessivo. Una macchina virtuale Standard_DS13 può soddisfare il requisito di 16.000 operazioni di I/O al secondo usando quattro dischi P30. La macchina virtuale DS13 ha un numero massimo di operazioni di I/O al secondo pari a 25.600 e ogni disco P30 ha un numero massimo di operazioni di I/O al secondo pari di 5.000. Questa configurazione consente complessivamente di ottenere 5.000 x 4 = 20.000 IOPS.
- Il costo stimato di questa macchina virtuale al mese è di $1.003.
- Il costo mensile di quattro dischi di archiviazione Premium P30 è di $ 544,34.
- Il costo mensile stimato è di $1.544.
La tabella seguente riepiloga la suddivisione dei costi di questo scenario per l'archiviazione Standard e Premium.
| Costo mensile | Standard | Premium |
|---|---|---|
| Costo di VM al mese | $ 1.570,58 (Standard_D14) | $ 1.003,66 (Standard_DS13) |
| Costo dei dischi al mese | $ 1.638,40 (32 x dischi da 1 TB) | $ 544,34 (4 x dischi P30) |
| Costo complessivo al mese | $ 3.208,98 | $ 1.544,34 |
Distribuzioni Linux
Con l'archiviazione Premium si ottiene lo stesso livello di prestazioni per le macchine virtuali che eseguono Windows e Linux. Sono supportati molti tipi di distribuzioni Linux. Per altre informazioni, vedere Distribuzioni linux approvate in Azure.
Distribuzioni diverse sono più adatte per diversi tipi di carichi di lavoro. Vengono visualizzati diversi livelli di prestazioni a seconda della distribuzione in cui è in esecuzione il carico di lavoro. Testare le distribuzioni di Linux con l'applicazione e scegliere quella migliore per le esigenze specifiche.
Quando si esegue Linux con archiviazione Premium, controllare gli aggiornamenti più recenti sui driver necessari per garantire prestazioni elevate.
Dimensioni dei dischi di Archiviazione Premium
L'archiviazione Premium offre diverse dimensioni, in modo da poter scegliere quella più adatta alle proprie esigenze. Ogni dimensione di disco ha un limite di scala diverso per IOPS, larghezza di banda e archiviazione. Scegliere le dimensioni corrette del disco di archiviazione Premium in base ai requisiti dell'applicazione e alle dimensioni delle macchine virtuali su larga scala. La tabella seguente illustra le dimensioni dei dischi e le relative funzionalità. Le dimensioni P4, P6, P15, P60, P70 e P80 sono attualmente supportate solo per i dischi gestiti.
| Dimensioni SSD Premium | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Dimensioni disco in GiB | 4 | 8 | 16 | 32 | 64 | 128 | 256 | 512 | 1.024 | 2.048 | 4.096 | 8,192 | 16,384 | 32.767 |
| Operazioni di I/O al secondo con provisioning di base per disco | 120 | 120 | 120 | 120 | 240 | 500 | 1.100 | 2.300 | 5,000 | 7.500 | 7.500 | 16.000 | 18.000 | 20.000 |
| **Operazioni di I/O al secondo con provisioning espanso per disco | N/D | N/D | N/D | N/D | N/D | N/D | N/D | N/D | 8.000 | 16.000 | 20.000 | 20.000 | 20.000 | 20.000 |
| Velocità effettiva con provisioning di base per disco | 25 MB/s | 25 MB/s | 25 MB/s | 25 MB/s | 50 MB/s | 100 MB/s | 125 MB/s | 150 MB/s | 200 MB/s | 250 MB/s | 250 MB/s | 500 MB/s | 750 MB/s | 900 MB/s |
| **Velocità effettiva con provisioning espanso per disco | N/D | N/D | N/D | N/D | N/D | N/D | N/D | N/D | 300 MB/s | 600 MB/s | 900 MB/s | 900 MB/s | 900 MB/s | 900 MB/s |
| Numero massimo di operazioni di I/O al secondo in modalità burst per disco | 3.500 | 3.500 | 3.500 | 3.500 | 3.500 | 3.500 | 3.500 | 3.500 | 30.000* | 30.000* | 30.000* | 30.000* | 30.000* | 30.000* |
| Velocità effettiva massima in modalità burst per disco | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* |
| Durata massima in modalità burst | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | 30 min | Nessun limite* | Nessun limite* | Nessun limite* | Nessun limite* | Nessun limite* | Nessun limite* |
| Idoneo per la prenotazione | No | No | No | No | No | No | No | No | Sì, fino a un anno | Sì, fino a un anno | Sì, fino a un anno | Sì, fino a un anno | Sì, fino a un anno | Sì, fino a un anno |
*Si applica solo ai dischi con bursting on demand abilitato.
**Si applica solo ai dischi con performance plus (anteprima) abilitate.
Il numero di dischi scelto dipende dalla dimensione scelta per il disco. È possibile usare un singolo disco P50 o più dischi P10 per soddisfare i requisiti dell'applicazione. Prendere in considerazione le considerazioni elencate qui quando si fa la scelta.
Limiti di scalabilità (operazioni di I/O al secondo e velocità effettiva)
I limiti di operazioni di I/O al secondo e velocità effettiva di ogni dimensione del disco Premium sono diversi e indipendenti dai limiti di scalabilità delle macchine virtuali. Assicurarsi che le operazioni di I/O al secondo e la velocità effettiva totali dei dischi siano entro i limiti di scalabilità delle dimensioni della macchina virtuale scelta.
Ad esempio, se un requisito dell'applicazione è una velocità effettiva massima di 250 MB/sec e si usa una macchina virtuale DS4 con un singolo disco P30, la macchina virtuale DS4 può rinunciare a una velocità effettiva di 256 MB/sec. Tuttavia, un singolo disco P30 ha un limite di velocità effettiva di 200 MB/sec. Pertanto, l'applicazione è vincolata a 200 MB/sec a causa del limite di disco. Per superare questo limite, effettuare il provisioning di più dischi dati nella macchina virtuale o ridimensionare i dischi in P40 o P50.
Nota
Le letture gestite dalla cache non sono incluse nelle operazioni di I/O al secondo del disco e nella velocità effettiva, quindi non sono soggette ai limiti del disco. La cache ha un limite di operazioni di I/O al secondo e velocità effettiva separate per ogni macchina virtuale.
Ad esempio, inizialmente le letture e le scritture sono rispettivamente 60 MB/sec e 40 MB/sec. Nel corso del tempo, la cache migliora la propria operatività e fornisce un numero sempre maggiore di operazioni di lettura dalla cache. È quindi possibile ottenere una velocità effettiva di scrittura superiore dal disco.
Numero di dischi
Determinare il numero di dischi necessari valutando i requisiti dell'applicazione. Ogni dimensione di VM prevede anche un limite per il numero di dischi che possono essere collegati alla VM. In genere, questa quantità è due volte il numero di core. Assicurarsi che la dimensione di VM scelta sia in grado di supportare il numero di dischi necessari.
Tenere presente che i dischi di archiviazione Premium hanno funzionalità di prestazioni superiori rispetto ai dischi di archiviazione standard. Se si esegue la migrazione dell'applicazione da una macchina virtuale IaaS di Azure usando l'archiviazione Standard all'archiviazione Premium, è probabile che siano necessari meno dischi Premium per ottenere prestazioni uguali o superiori per l'applicazione.
Memorizzazione nella cache del disco
Le macchine virtuali su larga scala che usano l'archiviazione Premium hanno una tecnologia di memorizzazione nella cache a più livelli denominata BlobCache. BlobCache usa una combinazione della RAM host e dell'unità SSD locale per la memorizzazione nella cache. Questa cache è disponibile per i dischi persistenti di archiviazione Premium e i dischi locali della macchina virtuale. Per impostazione predefinita, questa impostazione della cache è impostata su ReadWrite per i dischi del sistema operativo e ReadOnly per i dischi dati ospitati nell'archiviazione Premium. Con la memorizzazione nella cache del disco abilitata nei dischi di archiviazione Premium, le macchine virtuali su larga scala possono ottenere livelli estremamente elevati di prestazioni che superano le prestazioni del disco sottostanti.
Avviso
La memorizzazione nella cache del disco non è supportata per i dischi da 4 TiB e superiori. Se più dischi sono collegati alla macchina virtuale, ogni disco più piccolo di 4 TiB supporta la memorizzazione nella cache.
La modifica dell'impostazione della cache di un disco di Azure scollega e ricollega il disco di destinazione. Se si tratta del disco del sistema operativo, la macchina virtuale viene riavviata. Arrestare tutte le applicazioni e i servizi che potrebbero essere interessati da questa interruzione prima di modificare l'impostazione della cache del disco. Se non si seguono tali raccomandazioni potrebbe verificarsi un danneggiamento dei dati.
Per altre informazioni sul funzionamento di BlobCache , vedere il post di blog All'interno di Archiviazione Premium di Azure.
È importante abilitare la memorizzazione nella cache nel set corretto di dischi. Il fatto che sia necessario abilitare la memorizzazione nella cache del disco in un disco Premium o meno dipende dal modello di carico di lavoro gestito dal disco. La tabella seguente mostra le impostazioni della cache predefinite per il sistema operativo e i dischi dati.
| Tipo di disco | Impostazione predefinita per la cache |
|---|---|
| Disco del sistema operativo | ReadWrite |
| Disco dati | ReadOnly |
È consigliabile usare le impostazioni della cache del disco seguenti per i dischi dati.
| Impostazione per la memorizzazione nella cache su disco | Raccomandazione per quando usare questa impostazione |
|---|---|
| None | Configurare host-cache come Nessuno per i dischi di sola scrittura e di scrittura.Configure host-cache as None for write-only and write-heavy disks. |
| ReadOnly | Configurare host-cache come ReadOnly per i dischi di sola lettura e di lettura/scrittura. |
| ReadWrite | Configurare host-cache come ReadWrite solo se l'applicazione gestisce correttamente la scrittura di dati memorizzati nella cache in dischi persistenti quando necessario. |
ReadOnly
Configurando la memorizzazione nella cache ReadOnly nei dischi dati di archiviazione Premium, è possibile ottenere una bassa latenza di lettura e ottenere operazioni di I/O al secondo e velocità effettiva di lettura molto elevate per l'applicazione per due motivi:
- Le letture eseguite dalla cache, che si trova nella memoria della macchina virtuale e nell'unità SSD locale, sono più veloci delle letture dal disco dati, che si trova in Archiviazione BLOB di Azure.
- L'archiviazione Premium non conta le letture gestite dalla cache verso le operazioni di I/O al secondo del disco e la velocità effettiva. Per questo motivo, l'applicazione può ottenere operazioni di I/O al secondo e velocità effettiva totali più elevate.
ReadWrite
Per impostazione predefinita, i dischi del sistema operativo hanno la memorizzazione nella cache ReadWrite abilitata. È stato aggiunto di recente anche il supporto per la memorizzazione nella cache ReadWrite nei dischi dati. Se si usa la memorizzazione nella cache ReadWrite , è necessario disporre di un modo appropriato per scrivere i dati dalla cache ai dischi permanenti. Ad esempio, SQL Server gestisce automaticamente la scrittura di dati memorizzati nella cache nei dischi di archiviazione permanente. L'uso della cache ReadWrite con un'applicazione che non gestisce la persistenza dei dati necessari può causare la perdita di dati, se la macchina virtuale si arresta in modo anomalo.
None
Attualmente l'impostazione Nessuno è supportata solo nei dischi dati. Non è supportato nei dischi del sistema operativo. Se si imposta Nessuno su un disco del sistema operativo, esegue l'override di questa impostazione internamente e la imposta su ReadOnly.
Ad esempio, è possibile applicare queste linee guida a SQL Server in esecuzione nell'archiviazione Premium seguendo questa procedura:
- Configurare la cache ReadOnly nei dischi di archiviazione Premium che ospitano file di dati.
- La velocità di lettura dalla cache riduce il tempo di query di SQL Server perché le pagine di dati vengono recuperate più velocemente dalla cache rispetto ai dischi dati direttamente dai dischi dati.
- La gestione delle letture dalla cache significa che è disponibile una maggiore velocità effettiva dai dischi dati Premium. SQL Server può usare questa velocità effettiva aggiuntiva per recuperare più pagine di dati e altre operazioni, ad esempio backup/ripristino, caricamenti batch e ricompilazione dell'indice.
- Configurare la cache None nei dischi di archiviazione Premium che ospitano i file di log.
- I file di log hanno principalmente operazioni di scrittura, quindi non traggono vantaggio dalla cache ReadOnly .
Ottimizzare le prestazioni nelle macchine virtuali Linux
Per tutti i dischi SSD Premium o Ultra, è possibile disabilitare le barriere per i file system sul disco per migliorare le prestazioni quando è noto che non sono presenti cache che potrebbero perdere dati. Se la memorizzazione nella cache dei dischi di Azure è impostata su ReadOnly o Nessuno, è possibile disabilitare le barriere. Tuttavia, se la memorizzazione nella cache è impostata su ReadWrite, le barriere devono rimanere abilitate per garantire la durabilità della scrittura. Le barriere sono in genere abilitate per impostazione predefinita, ma è possibile disabilitare le barriere usando uno dei metodi seguenti a seconda del tipo di file system:
- reiserFS: usare l'opzione barrier=none mount per disabilitare le barriere. Per abilitare in modo esplicito le barriere, usare barrier=flush.
- ext3/ext4: usare l'opzione di montaggio barrier=0 per disabilitare le barriere. Per abilitare in modo esplicito le barriere, usare barrier=1.
- XFS: usare l'opzione di montaggio nobarrier per disabilitare le barriere. Per abilitare in modo esplicito le barriere, usare la barriera. A partire dalla versione 4.10 del kernel Linux principale, la progettazione del file system XFS garantisce sempre la durabilità. La disabilitazione delle barriere non ha alcun effetto e l'opzione nobarrier è deprecata. Tuttavia, alcune distribuzioni di Linux potrebbero aver eseguito il backporting delle modifiche apportate a una versione di distribuzione con una versione precedente del kernel. Rivolgersi al fornitore di distribuzione per verificare lo stato della distribuzione e della versione in esecuzione.
Striping del disco
Quando una macchina virtuale a scalabilità elevata è collegata a diversi dischi persistenti di archiviazione Premium, i dischi possono essere raggruppati per aggregare le operazioni di I/O, la larghezza di banda e la capacità di archiviazione.
In Windows è possibile usare gli spazi di archiviazione per lo striping dei dischi. È necessario configurare una colonna per ogni disco in un pool. In caso contrario, le prestazioni complessive del volume con striping possono essere inferiori al previsto a causa di una distribuzione non uniforme del traffico tra i dischi.
Usando l'interfaccia utente di Server Manager, è possibile impostare il numero totale di colonne su 8 per un volume con striping. Quando si collegano più di otto dischi, usare PowerShell per creare il volume. Usando PowerShell, è possibile impostare il numero di colonne uguale al numero di dischi. Ad esempio, se sono presenti 16 dischi in un singolo set di striping, specificare 16 le colonne nel NumberOfColumns parametro del cmdlet di New-VirtualDisk PowerShell.
In Linux usare l'utilità MDADM per lo striping dei dischi. Per informazioni su come eseguire lo striping dei dischi in Linux, vedere Configurare RAID software in Linux.
Dimensioni di striping
Un elemento importante della configurazione dello striping del disco è la dimensione di striping. Le dimensioni dello striping o del blocco sono il blocco più piccolo di dati che un'applicazione può gestire in un volume con striping. La dimensione di striping configurabile dipende dal tipo di applicazione e dal relativo modello di richieste. Se si sceglie la dimensione di striping errata, potrebbe verificarsi un errore di I/O, con un calo delle prestazioni dell'applicazione.
Ad esempio, se una richiesta di I/O generata dall'applicazione è maggiore delle dimensioni di striping del disco, il sistema di archiviazione lo scrive oltre i limiti dell'unità di striping su più dischi. Quando è il momento di accedere a tali dati, è necessario cercare in più unità di striping per completare la richiesta. L'effetto cumulativo di questo comportamento può portare a una riduzione significativa delle prestazioni. D'altra parte, se la dimensione della richiesta di I/O è inferiore alle dimensioni di striping e, se è casuale, le richieste di I/O potrebbero aggiungere sullo stesso disco, causando un collo di bottiglia e infine degradando le prestazioni di I/O.
Scegliere una dimensione di striping appropriata in base a tipo di carico di lavoro eseguito dall'applicazione. Per le richieste di I/O casuali di piccole dimensioni, usare una dimensione di striping inferiore. Per le richieste di I/O sequenziali di grandi dimensioni, usare una dimensione di striping maggiore. Scopri le raccomandazioni relative alle dimensioni di striping per l'applicazione in esecuzione nell'archiviazione Premium. Per SQL Server configurare dimensioni di striping pari a 64 KB per carichi di lavoro OLTP e 256 KB per carichi di lavoro di tipo data warehouse. Per altre informazioni, vedere Procedure consigliate per le prestazioni per SQL Server in macchine virtuali di Azure.
Nota
è possibile effettuare lo striping di un massimo di 32 dischi di Archiviazione Premium in una VM di serie DS e di 64 dischi di Archiviazione Premium in una VM di serie GS.
Multithreading
Azure ha progettato la piattaforma di archiviazione Premium per essere parallela in modo massiccio. Per questo motivo, un'applicazione multithreading ottiene prestazioni superiori rispetto a un'applicazione a thread singolo. Un'applicazione multithreading suddivide le attività in più thread e aumenta l'efficienza dell'esecuzione usando la macchina virtuale e le risorse disco al massimo.
Ad esempio, se l'applicazione è in esecuzione su una VM a core singolo con due thread, la CPU può passare da un thread all'altro per ottenere l'efficienza. Mentre un thread è in attesa del completamento di un I/O su disco, la CPU può passare all'altro thread. In questo modo, due thread possono ottenere molto di più rispetto a un singolo thread. Se la macchina virtuale ha più di un core, diminuisce ulteriormente il tempo di esecuzione perché ogni core può eseguire attività in parallelo.
Potrebbe non essere possibile modificare il modo in cui un'applicazione fuori uso implementa il threading singolo o il multithreading. Ad esempio, SQL Server è in grado di gestire più CPU e multicore. Tuttavia, SQL Server decide in quali condizioni usa uno o più thread per elaborare una query. Può eseguire query e compilare indici usando il multithreading. Per una query che prevede l'unione di tabelle di grandi dimensioni e l'ordinamento dei dati prima di tornare all'utente, SQL Server usa probabilmente più thread. Un utente non può controllare se SQL Server esegue una query usando un singolo thread o più thread.
Esistono impostazioni di configurazione che è possibile modificare per influenzare l'elaborazione multithreading o parallela di un'applicazione. Ad esempio, per SQL Server è la max degree of parallelism configurazione. Questa impostazione denominata MAXDOP consente di configurare il numero massimo di processori che SQL Server può usare durante l'elaborazione parallela. È possibile configurare MAXDOP per singole query o per operazioni sull'indice. Questa funzionalità è utile quando si vogliono bilanciare le risorse del sistema per un'applicazione critica per le prestazioni.
Si supponga, ad esempio, che l'applicazione che usa SQL Server esegua una query di grandi dimensioni e un'operazione sull'indice contemporaneamente. Si supponga di voler che l'operazione sull'indice sia più efficiente rispetto alla query di grandi dimensioni. In questo caso, è possibile impostare il valore MAXDOP dell'operazione sull'indice su un valore superiore al valore MAXDOP per la query. In questo modo, SQL Server dispone di più processori che può usare per l'operazione di indice rispetto al numero di processori che può dedicare alla query di grandi dimensioni. Tenere presente che non si controlla il numero di thread usati da SQL Server per ogni operazione. È possibile controllare il numero massimo di processori dedicati per il multithreading.
Altre informazioni sui gradi di parallelismo in SQL Server. Informazioni su come tali impostazioni influiscono sul multithreading nell'applicazione e sulle relative configurazioni per ottimizzare le prestazioni.
Profondità della coda
La profondità della coda o la lunghezza della coda o la dimensione della coda corrisponde al numero di richieste di I/O in sospeso nel sistema. Il valore della profondità della coda determina il numero di operazioni di I/O che l'applicazione può allineare, ovvero il processo dei dischi di archiviazione. Influisce su tutti e tre gli indicatori di prestazioni dell'applicazione descritti in questo articolo: operazioni di I/O al secondo, velocità effettiva e latenza.
La profondità della coda e il multithreading sono strettamente correlati. Il valore di profondità della coda indica la quantità di multithreading che può essere ottenuta dall'applicazione. Se la profondità della coda è grande, l'applicazione può eseguire più operazioni contemporaneamente, in altre parole, più multithreading. Se la profondità della coda è ridotta, anche se l'applicazione è multithreading, non avrà richieste sufficienti allineate per l'esecuzione simultanea.
In genere, le applicazioni off-the-shelf non consentono di modificare la profondità della coda, perché se è impostata in modo non corretto, fa più male che bene. Le applicazioni impostano il valore corretto della profondità della coda per ottenere prestazioni ottimali. È importante comprendere questo concetto in modo da poter risolvere i problemi di prestazioni con l'applicazione. È anche possibile osservare gli effetti della profondità della coda eseguendo gli strumenti di benchmarking nel sistema.
Alcune applicazioni forniscono impostazioni per influenzare la profondità della coda. Ad esempio, l'impostazione MAXDOP in SQL Server illustrata nella sezione precedente. MAXDOP è un modo per influenzare la profondità della coda e il multithreading, anche se non modifica direttamente il valore di profondità della coda di SQL Server.
Profondità elevata della coda
Un valore elevato per la profondità della coda consente di allineare più operazioni sul disco. Il disco conosce in anticipo la richiesta successiva nella coda. Il disco può quindi pianificare le operazioni in anticipo ed elaborarle in una sequenza ottimale. Poiché l'applicazione invia più richieste al disco, il disco può elaborare più operazioni di I/O parallele. In definitiva, l'applicazione può ottenere operazioni di I/O al secondo più elevate. Poiché l'applicazione sta elaborando più richieste, aumenta anche la velocità effettiva totale dell'applicazione.
In genere, un'applicazione può raggiungere la velocità effettiva massima con 8-16+ operazioni di I/O in sospeso per ogni disco collegato. Se una profondità della coda è una, l'applicazione non esegue il push di un numero sufficiente di operazioni di I/O nel sistema e elabora una quantità minore in un determinato periodo. In altre parole, minore velocità effettiva.
In SQL Server, ad esempio, impostando il valore MAXDOP per una query per 4 informare SQL Server che può usare fino a quattro core per eseguire la query. SQL Server determina il valore di profondità della coda migliore e il numero di core per l'esecuzione della query.
Profondità ottimale della coda
Un valore di profondità della coda molto elevato presenta anche i suoi svantaggi. Se il valore di profondità della coda è troppo elevato, l'applicazione tenta di guidare operazioni di I/O al secondo molto elevate. A meno che l'applicazione non disponga di dischi persistenti con operazioni di I/O al secondo con provisioning sufficiente, un valore di profondità della coda molto elevato può influire negativamente sulle latenze dell'applicazione. La formula seguente illustra la relazione tra operazioni di I/O al secondo, latenza e profondità della coda.
Non è consigliabile configurare la profondità della coda su un valore elevato, ma su un valore ottimale, che può offrire operazioni di I/O al secondo sufficienti per l'applicazione senza influire sulle latenze. Ad esempio, se la latenza dell'applicazione deve essere di 1 millisecondo, la profondità della coda necessaria per ottenere 5.000 operazioni di I/O al secondo è QD = 5.000 x 0,001 = 5.
Profondità coda per il volume con striping
Per un volume con striping, mantenere una profondità della coda sufficientemente elevata in modo che ogni disco abbia una profondità massima della coda singolarmente. Si consideri, ad esempio, un'applicazione che esegue il push di una profondità della coda di 2 e che sono presenti quattro dischi nello striping. Le due richieste di I/O passano a due dischi e i due dischi rimanenti sono inattive. Configurare quindi la profondità della coda in modo che tutti i dischi possano essere occupati. La formula seguente illustra come determinare la profondità della coda dei volumi con striping.
Limitazione
L'archiviazione Premium effettua il provisioning di un numero specificato di operazioni di I/O al secondo e velocità effettiva a seconda delle dimensioni della macchina virtuale e dei dischi scelti. Ogni volta che l'applicazione tenta di gestire operazioni di I/O al secondo o velocità effettiva superiori a questi limiti, la macchina virtuale o il disco può gestire, l'archiviazione Premium la limita. Il risultato è una riduzione delle prestazioni nell'applicazione, che può comportare una latenza più elevata, una velocità effettiva inferiore o un numero inferiore di operazioni di I/O al secondo.
Se l'archiviazione Premium non limita, l'applicazione potrebbe non riuscire completamente superando le risorse che possono raggiungere. Per evitare problemi di prestazioni a causa della limitazione, effettuare sempre il provisioning di risorse sufficienti per l'applicazione. Prendere in considerazione quanto illustrato nelle sezioni precedenti relative alle dimensioni delle macchine virtuali e alle dimensioni del disco. Il benchmarking è il modo migliore per individuare le risorse necessarie per ospitare l'applicazione.
Passaggi successivi
Per eseguire il benchmark del disco, vedere gli articoli seguenti:
- Per Linux: Eseguire il benchmark dell'applicazione in Archiviazione su disco di Azure
- Per Windows: Eseguire il benchmark di un disco
Altre informazioni sui tipi di disco disponibili:
- Per Linux: selezionare un tipo di disco
- Per Windows: selezionare un tipo di disco
Per gli utenti di SQL Server, vedere gli articoli sulle procedure consigliate per le prestazioni per SQL Server: