Automatizzare i test sullo storage

Ciao a tutti, oggi parliamo di test molto utili da effettuare sul nostro storage che potrebbe ospitare applicazioni impegnative come SQL. L’articolo è scritto da Danilo Dominici che ringrazio e di cui riporto una breve descrizione.

Danilo Dominici lavora con SQL Server dalla versione 6.5, come sviluppatore ERP e sistemista. Dall'anno 2000, conseguite le principali certificazioni Microsoft (MCSE, MCAD, MCDBA, MCITP Database Administrator e MCT) si occupa per qualche anno di formazione presso i principali partner Microsoft in Italia, erogando corsi principalmente su SQL Server.  Dal 2004 è il database administrator SQL Server e amministratore/architect VMWare presso la Regione Marche, dove si è occupato anche di sviluppo di applicazioni ASP.NET.  Dal 2011 collabora attivamente con UGISS, lo User Group Italiano di SQL Server, come autore e speaker ai workshop su SQL Server 2012 e per l’attività di supporto alla community di SQL Server riceve il riconoscimento Microsoft Certified Community Contributor.  Dallo stesso anno inizia la collaborazione con SolidQ Italia, in cui ricopre il ruolo di Data Platform Specialist e per la quale ha contribuito alla stesura di alcuni capitoli della SQL Server 2012 Upgrade Technical Reference Guide.

 

Introduzione

Lo storage rappresenta uno dei fattori chiave per le prestazioni di un sistema destinato ad ospitare SQL Server. Conoscere a priori come si comportano i dischi, in termini di tempo di accesso e di capacità di I/O, consente di verificare se lo storage che abbiamo a disposizione è conforme a quanto richiesto dalle applicazioni che vi accedono.

In questo articolo, primo di tre, vedremo come si installa ed utilizza uno dei tool più utilizzati per l’analisi delle prestazioni di un disco, il SQLIO Disk Subsystem Benchmark Tool.

Come funziona

SQLIO utilizza uno o più files, creati in precedenza o attraverso il tool stesso, per effettuare dei test di lettura e/o scrittura, variando, attraverso i parametri di esecuzione, le caratteristiche dell’operazione di I/O (dimensione del blocco di bytes letti o scritti, numero di thread utilizzati in parallelo, etc).

Che cosa analizzare

Esistono molti articoli in rete che trattano di SQLIO e di come utilizzarlo per verificare le prestazioni di un disco, ma spesso si trovano indicazioni sulle tipologie di test da effettuare che in realtà poco si adattano a SQL Server.

Vediamo che cosa analizzare: SQL Server, infatti, accede allo storage utilizzando una serie di pattern ben noti.

Per questo motivo non è necessario effettuare i test con tutte le possibili varianti di parametri, ma è possibile concentrarsi solo su quelli specifici per SQL Server.

Nella tabella seguente una lista di test da effettuare con SQLIO per validare un workload tipico di un sistema misto OLTP/DW.

Tipo di I/O	Dimensione blocco	Threads/queue	Che cosa simula
Lettura/scrittura random	8K	# cores / files	File dati OLTP
Scrittura sequenziale	60K	1 / 32	Transaction log
Lettura sequenziale	512K	1 / 16	Table scan
Scrittura sequenziale	256K	1 / 16	Bulk load
Lettura random	32K	# cores / 1	SSAS workload
Lettura sequenziale	1MB	1 / 32	Backup
Scrittura random	64K-256K	# cores / files	Checkpoint

 

Che cosa serve

Per prima cosa occorre scaricare il tool SQLIO dal sito Microsoft (https://www.microsoft.com/en-us/download/details.aspx?id=20163).

Il tool è veramente “leggero”: occupa solo 176 KB e funziona su tutte le versioni di Windows, anche se tra i prerequisiti l’elenco dei sistemi operativi supportati è fermo a Windows 2003.

SQLIO non ha un’interfaccia grafica, perciò per utilizzarlo occorre eseguire sqlio.exe dal prompt dei comandi, dopo essersi posizionati nella cartella di installazione (Per default: C:\Program Files (x86)\SQLIO\), oppure automatizzarne l’esecuzione attraverso comandi batch o utilizzando scripts Powershell.

Dopo aver installato SQLIO, occorre creare un file di test, di dimensioni sufficientemente grandi. Se il file è di piccole dimensioni, infatti, lo spostamento delle testine del disco è ridotto e provocherebbe la restituzione di numeri estremamente elevati nei test di IO random, ovviamente poco realistici.

Inoltre la dimensione del file dovrebbe essere maggiore della capacità della cache del controller, altrimenti si misurerebbero le prestazioni del controller e non del disco!

Il modo più veloce per creare il file di test consiste nell’utilizzare il comando FSUTIL.EXE, incluso in tutte le versioni di Windows, ed in particolare due dei comandi accettati: createnew e setvaliddata.

Un esempio pratico: se si desidera creare un file di 1TB nel drive E: occorre digitare, al prompt di Powershell:

PS C:\> FSUTIL.EXE file createnew E:\testfile.dat (1TB)

PS C:\> FSUTIL.EXE file setvaliddata E:\testfile.dat (1TB)

Perché eseguirlo dal prompt di Powershell? Perché in questo modo possiamo usare la comoda forma “(1TB)” invece di dover indicare la dimensione in bytes come richiesto dal comando FSUTIL. Inoltre, il comando setvaliddata consente di “marcare” la fine del file alla dimensione specificata, senza dover attendere l’inizializzazione del file e quindi molto più velocemente rispetto ad altre tecniche.

Una volta creato il file, possiamo finalmente eseguire i test, indicando i parametri necessari.

Nella tabella sottostante sono elencati i parametri principalmente utilizzati:

Parametro	Significato
-kW o –kR	Specifica il tipo di operazione da eseguire: W(rite) o R(ead)
-frandom o –fsequential	Indica se l’operazione di I/O deve essere random o sequenziale
-t	Numero di threads in esecuzione contemporaneamente
-o	Numero di richieste contemporanee
-s	Durata, in secondi, del test
-b	Dimensione, in KB, del blocco di dati usato per leggere o scrivere
-LS	Indica a SQLIO di catturare i tempi di latenza per i dischi
-BN	Indica a SQLIO di non utilizzare il buffering

Vediamo un esempio pratico: facciamo un test di lettura random, per una durata di 10 secondi, utilizzando blocchi di 8KB, sfruttando 8 thread ed 8 richieste contemporanee.

Poiché il numero di I/O contemporanei è determinato dal prodotto del numero di thread per il numero di richieste contemporanee, chiederemo al sistema di effettuare 64 I/O.

Il comando da eseguire sarà:

C:\Program Files (x86)\SQLIO> sqlio.exe –s10 –kR –frandom –b8 –t8 –o16 –LS –BN E:\testfile.dat

Questo il risultato del test: nella prima parte vengono riportati i parametri di esecuzione, segue una sezione CUMULATIVE DATA contenente i risultati del test e per finire un istogramma che rappresenta, in forma testuale, la distribuzione dei valori percentuali dei campioni raccolti per i valori di tempo che vanno da 0 a 24 millisecondi.

Ma come si interpretano queste informazioni?

Ci sono tre valori che ci indicano quanto è performante il nostro storage:

- IOs/sec (i famosi IOPS – numero di operazioni di I/O al secondo), che in questo test sono pari a 23345.00 IOPS

- MBs/sec, che qui sono pari a 182.38 MB/sec

- Latenza min/media/massima, qui rispettivamente 0/4/14 ms.

L’istogramma indica come la maggior parte (18% x 5 valori = 90%) della durata delle operazioni di I/O è compresa tra i 3 ed i 7 ms.

La latenza ottimale è generalmente indicata in:

- 1-5 ms per il Transaction Log (valori ottimali = 1 ms per array con cache)

- 4-20 ms per i data files in un sistema OLTP (valori ottimali < 10 ms)

- 30 ms o meno per Data Warehouse

Bene, per ora ci fermiamo qui.

Nella prossima puntata vedremo come automatizzare l’esecuzione dei test utilizzando batch e Powershell.

Risorse

Di seguito alcuni link utili per approfondire la conoscenza di quanto descritto nel presente articolo:

§ SQLIO Disk Subsystem Benchmark Tool
https://www.microsoft.com/en-us/download/details.aspx?id=20163

§ Comando FSUTIL
https://technet.microsoft.com/en-us/library/cc753059(v=ws.10).aspx

§ SQL Server Best Practices
https://technet.microsoft.com/en-us/library/Cc966412

§ How it works: Bob Dorr’s SQL Server I/O presentation
Bob Dorr, Microsoft CSS Engineer
https://bit.ly/b7R1pX

§ SQLIO, PowerShell and storage performance: measuring IOPs, throughput and latency for both local disks and SMB file shares
Jose Barreto, Microsoft File Server Team member
https://bit.ly/14qKOzK

Comments

• Anonymous
  October 05, 2013
  Uno dei problemi che frequentemente si incontrano negli articoli tecnici è proprio quello di non avere un riscontro specifico a ciò che si è letto. Complimenti a Danilo Dominici per aver colto nel segno illustrando l'applicazione di una interessante utility.