Che diavolo è un DTU?

Autore ospite:Andy Mallon (@AMtwo)

No, sul serio. Che cos'è una DTU?

Quando si distribuisce un'applicazione, una delle prime domande che si pone è "Quanto costerà?" La maggior parte di noi ha eseguito questo tipo di esercizio per il dimensionamento di un'installazione di SQL Server a un certo punto, ma cosa succede se si esegue la distribuzione nel cloud? Con le distribuzioni di Azure IaaS, non è cambiato molto:stai ancora creando un server basato sul conteggio della CPU, una certa quantità di memoria e configurando l'archiviazione per fornire IOPS sufficienti per il tuo carico di lavoro. Tuttavia, quando si passa a PaaS, il database SQL di Azure viene ridimensionato con livelli di servizio diversi, in cui le prestazioni vengono misurate in DTU. Che diavolo è un DTU?

So cos'è un BTU. Forse DTU sta per Database Thermal Unit? È la quantità di potenza di elaborazione necessaria per aumentare di un grado la temperatura del data center? Invece di tirare a indovinare, controlliamo la documentazione e vediamo cosa ha da dire Microsoft:

OK, questa era la mia seconda ipotesi, ma qual è la "misura mista"? Come posso tradurre ciò che so sul dimensionamento di un server nel dimensionamento di un database SQL di Azure? Sfortunatamente, non esiste un modo semplice per tradurre "2 core CPU e 4 GB di memoria" in una misurazione DTU.

Non esiste un calcolatore DTU?

Sì! Microsoft ci fornisce un calcolatore DTU da stimare il livello di servizio corretto del database SQL di Azure. Per usarlo, scaricare ed eseguire uno script di PowerShell (sql-perfmon.ps1) sul server durante l'esecuzione di un carico di lavoro in SQL Server. Lo script genera un CSV che contiene quattro contatori perfmon:(1) % totale del tempo del processore, (2) letture totali del disco al secondo, (3) scritture totali del disco al secondo e (4) byte di registro totali scaricati al secondo. Questo output CSV viene quindi caricato nel Calcolatore DTU, che stima quale livello di servizio soddisferà meglio le tue esigenze. Gli unici dati che la calcolatrice DTU prende oltre al CSV è il numero di core della CPU sul server che ha generato il file. Il calcolatore DTU è ancora un po' una scatola nera:non è facile mappare ciò che sappiamo dai nostri database locali in Azure.

Vorrei sottolineare che la definizione di DTU è che è "una misura combinata di CPU, memoria , e I/O dati e I/O del registro delle transazioni…” Nessuno dei contatori perfmon utilizzati dal calcolatore DTU tiene conto della memoria, ma è chiaramente elencato nella definizione come parte del calcolo. Questo non è necessariamente un problema, ma è la prova che il calcolatore DTU non sarà perfetto.

Caricherò del carico sintetico nel calcolatore DTU e vedrò se riesco a capire come funziona quella scatola nera. In effetti, realizzerò completamente i CSV in modo da poter controllare totalmente i numeri perfmon che carichiamo nel calcolatore DTU. Esaminiamo una metrica alla volta. Per ogni metrica, caricheremo 25 minuti (1500 secondi, mi piacciono i numeri rotondi) di dati fabbricati e vedremo come quei dati perfmon vengono convertiti in DTU.

CPU

Creerò un CSV che simula un server a 16 core, aumentando lentamente l'utilizzo della CPU fino a raggiungere il 100%. Dal momento che ho intenzione di simulare il ramp-up su un server a 16 core, creerò il mio CSV per aumentare 1/16 alla volta, simulando essenzialmente un core maxing out, quindi un secondo maxing out, quindi il terzo, ecc. Per tutto il tempo, il CSV mostrerà zero letture, scritture e svuotamenti del registro. Un server non genererebbe mai un carico di lavoro come questo, ma questo è il punto. Sto isolando completamente l'utilizzo della CPU in modo da poter vedere come la CPU influisce sulle DTU.

Creerò un file CSV con una riga al secondo e ogni 94 secondi aumenterò il contatore del tempo del processore % totale di circa il 6%. Gli altri tre contatori saranno in tutti i casi zero. Ora, carico questo file sulla calcolatrice DTU (e dico alla calcolatrice DTU di considerare 16 core), ed ecco l'output:

Attesa? Non ho aumentato l'utilizzo della CPU in 16 passaggi pari? Questo grafico DTU mostra solo cinque passaggi. Devo aver fatto un pasticcio. No:il mio CSV aveva 16 passaggi pari, ma questo (apparentemente) non si traduce in modo uniforme in DTU. Almeno non secondo il calcolatore DTU. Sulla base del nostro test CPU al massimo, la nostra mappatura da CPU a DTU a livello di servizio sarebbe simile a questa:

Guardare questi dati ci dice alcune cose:

1. Un core CPU, utilizzato al 100% equivale a 100 DTU.
2. Le DTU aumentano più o meno linearmente all'aumentare della CPU, ma apparentemente a singhiozzo.
3. I livelli di servizio Basic e Standard sono inferiori a un singolo core della CPU.
4. Qualsiasi server multi-core si tradurrebbe in una certa dimensione all'interno del livello di servizio Premium.

Legge

Questa volta userò la stessa metodologia. Genererò un CSV con numeri crescenti per il contatore di letture/secondo, con gli altri contatori perfmon a zero. Aumenterò lentamente il numero nel tempo. Questa volta, aumentiamo a blocchi di 2000, ogni 100 secondi, fino a raggiungere 30000. Questo ci dà lo stesso tempo totale di 25 minuti, tuttavia, questa volta ho 15 passaggi invece di 16. (Mi piacciono i numeri rotondi.)

Quando carichiamo questo CSV sul calcolatore DTU, ci fornisce questo grafico DTU:

Aspetta un secondo... sembra abbastanza simile al primo grafico. Ancora una volta, sta aumentando di 5 incrementi irregolari, anche se avevo 15 passaggi pari nel mio file. Diamo un'occhiata in formato tabellare:

Di nuovo, vediamo che i livelli Base e Standard vengono saltati abbastanza rapidamente (meno di 2000 letture/sec), ma poi il livello Premium è piuttosto ampio, da 2000 a 30000 letture al secondo. Nella tabella sopra, "Letture/sec" potrebbe probabilmente essere considerato "IOPS" ... O, tecnicamente, solo "OPS" poiché non ci sono scritture per costituire la parte "input" di IOPS.

Scrive

Se creiamo un CSV utilizzando la stessa formula che abbiamo usato per le letture e carichiamo quel CSV nella calcolatrice DTU, otterremo un grafico identico al grafico per le letture:

Gli IOPS sono IOPS, quindi che si tratti di una lettura o di una scrittura, sembra che il calcolo DTU lo consideri allo stesso modo. Tutto ciò che sappiamo (o pensiamo di sapere) sulle letture sembra applicarsi allo stesso modo alle scritture.

Byte di registro scaricati

Siamo all'ultimo contatore perfmon:log byte scaricati al secondo. Questa è un'altra misura di IO, ma specifica del log delle transazioni di SQL Server. Nel caso in cui non hai ancora preso piede, sto creando questi CSV in modo che i valori alti vengano calcolati come un DB Azure P15, quindi semplicemente dividendo il valore per suddividerlo in passaggi pari. Questa volta, passeremo da 5 milioni a 75 milioni, a passi di 5 milioni. Come abbiamo fatto in tutti i test precedenti, gli altri contatori perfmon saranno zero. Poiché questo contatore di prestazioni è in byte al secondo e ne stiamo misurando in milioni, possiamo pensare a questo nell'unità con cui siamo più a nostro agio:Megabyte al secondo.

Carichiamo questo CSV sul calcolatore DTU e otteniamo il seguente grafico:

La forma di questo grafico sta diventando piuttosto prevedibile. Tranne questa volta, avanziamo un po' più velocemente i livelli, raggiungendo P15 dopo soli 8 passaggi (rispetto a 11 per IO e 12 per CPU). Questo potrebbe portarti a pensare:"Questo sarà il mio collo di bottiglia più stretto!" ma non ne sarei così sicuro. Quante volte stai generando 75 MB di log in un secondo ? Sono 4,5 GB al minuto . È un sacco di attività nel database. Il mio carico di lavoro sintetico non è necessariamente un carico di lavoro realistico.

Combinare tutto

OK, ora che abbiamo visto dove alcuni dei limiti superiori sono isolati, combinerò i dati e vedrò come si confrontano quando CPU, I/O e I/O del registro delle transazioni si verificano tutti contemporaneamente, dopotutto , non è così che accadono effettivamente le cose?

Per creare questo CSV, ho semplicemente preso i valori esistenti che abbiamo usato per ogni singolo test sopra e ho combinato quei valori in un unico CSV, che produce questo bel grafico:

Fornisce anche il messaggio:

Se guardi l'asse Y, vedrai che abbiamo raggiunto "1.000k" (cioè 1 milione) di DTU al segno di 1200 secondi. Sembra... ehm... sbagliato? Se osserviamo i test di cui sopra, il punteggio di 1200 secondi è stato quando tutte e 4 le singole metriche hanno raggiunto il punteggio di 4000 DTU, livello P15. Ha senso che saremmo fuori portata, ma la forma del grafico non ha molto senso per me:penso che il calcolatore DTU abbia appena alzato le mani e detto:"Qualunque cosa, Andy. È molto. È troppo molto. È un miliardo di DTU. Questo carico di lavoro non è adatto per il database SQL di Azure."

OK, quindi cosa succede prima il segno di 1200 secondi? Riduciamo il CSV e lo inviamo nuovamente alla calcolatrice con solo i primi 1200 secondi. I valori massimi per ogni colonna sono:81% CPU (o apx 13 core al 100%), 24000 letture/sec, 24000 scritture/sec e 60 MB di log scaricati/sec.

Ciao, vecchio amico... Quella forma familiare è tornata di nuovo. Di seguito è riportato un riepilogo dei dati del CSV e delle stime del Calcolatore DTU per l'utilizzo totale delle DTU e per il livello di servizio.

Ora, diamo un'occhiata a come i singoli calcoli DTU (quando li abbiamo valutati isolatamente) si confrontano con i calcoli DTU di questo controllo più recente:

Noterai che il calcolo delle DTU non è semplice come sommare le tue DTU separate. Come afferma la definizione che ho citato all'inizio, è una "misura combinata" di quelle metriche separate. La formula usata per "miscelare" è complicata e in realtà non abbiamo quella formula. Quello che possiamo vedere è che le stime del DTU Calculator sono inferiori rispetto alla somma dei calcoli DTU separati.

Mappatura delle DTU sull'hardware tradizionale

Prendiamo i dati dalla calcolatrice DTU e proviamo a mettere insieme alcune ipotesi su come l'hardware tradizionale potrebbe essere mappato ad alcuni livelli del database SQL di Azure.

Per prima cosa, assumiamo che "letture/sec" e "scritture/sec" si traducano direttamente in IOPS, senza che sia necessaria alcuna traduzione. In secondo luogo, assumiamo che l'aggiunta di questi due contatori ci darà il nostro IOPS totale. Terzo, ammettiamo che non abbiamo idea di cosa sia l'utilizzo della memoria e non abbiamo modo di trarre conclusioni su questo fronte.

Mentre sto stimando le specifiche hardware, sceglierò anche una possibile dimensione della macchina virtuale di Azure che si adatta a ciascuna configurazione hardware. Esistono molte dimensioni simili di macchine virtuali di Azure, ognuna ottimizzata per diverse metriche delle prestazioni, ma sono andato avanti e ho limitato le mie scelte alla serie A e alla serie DSv2.

Il livello Base è incredibilmente limitato. È utile per un uso occasionale/casuale ed è un modo economico per "parcheggiare" il database quando non lo si utilizza. Ma se stai eseguendo una vera applicazione, il livello Basic non funzionerà per te.

Anche il livello Standard è piuttosto limitato, ma per piccole applicazioni è in grado di soddisfare le tue esigenze. Se si dispone di un server a 2 core che esegue una manciata di database, tali database potrebbero rientrare singolarmente nel livello Standard. Allo stesso modo, se si dispone di un server con un solo database, che esegue 1 core CPU al 100% (o 2 core in esecuzione al 50%), probabilmente è solo potenza sufficiente per ribaltare la scala nel livello di servizio Premium-P1.

Se si usa un server multicore in locale (o IaaS), si cerca all'interno del livello di servizio Premium nel database SQL di Azure. Si tratta solo di determinare la potenza di CPU e I/O necessaria per il carico di lavoro. Il tuo server a 2 core da 4 GB probabilmente ti porta da qualche parte intorno a un database SQL di Azure P6. In un carico di lavoro CPU puro (con zero I/O), un database P15 può gestire 16 core di elaborazione, ma una volta aggiunto IO al mix, qualsiasi cosa più grande di ~12 core non si adatta al database SQL di Azure.

La prossima volta prenderò alcuni carichi di lavoro effettivi e confronterò le prestazioni tra i livelli di servizio. Le stime del calcolatore DTU saranno accurate? Lo scopriremo.

Informazioni sull'autore