Uno dei colli di bottiglia delle prestazioni più comuni che vedo come consulente è l'inadeguatezza delle prestazioni del sottosistema di archiviazione. Ci sono una serie di ragioni per le scarse prestazioni di archiviazione, ma misurarle e capire cosa deve essere misurato e monitorato è sempre un esercizio utile.
Ci sono in realtà tre parametri principali che sono più importanti quando si tratta di misurare le prestazioni del sottosistema di I/O:
Latenza
La prima metrica è la latenza, che è semplicemente il tempo necessario per completare un I/O. Questo è spesso chiamato tempo di risposta o tempo di servizio. La misurazione inizia quando il sistema operativo invia una richiesta all'unità (o al controller del disco) e termina quando l'unità termina l'elaborazione della richiesta. Le letture sono complete quando il sistema operativo riceve i dati, mentre le scritture sono complete quando l'unità informa il sistema operativo di aver ricevuto i dati.
Per le scritture, i dati potrebbero essere ancora in una cache DRAM sull'unità o sul controller del disco, a seconda della politica di memorizzazione nella cache e dell'hardware. La cache write-back è molto più veloce della cache write-through, ma richiede una batteria di backup per il controller del disco. Per l'utilizzo di SQL Server, assicurarsi di utilizzare la cache write-back anziché la cache write-through, se possibile. Vuoi anche assicurarti che la cache del disco hardware sia effettivamente abilitata, poiché alcuni strumenti di gestione del disco del fornitore la disabilitano per impostazione predefinita.
Operazioni di input/output al secondo (IOPS)
La seconda metrica è Input/Output Operations al Second (IOPS). Questa metrica è direttamente correlata alla latenza. Ad esempio, una latenza costante di 1 ms significa che un'unità può elaborare 1.000 IO al secondo con una profondità della coda di 1. Man mano che più IO vengono aggiunti alla coda, la latenza aumenterà. Uno dei principali vantaggi dell'archiviazione flash è che può leggere/scrivere in parallelo su più canali NAND, oltre al fatto che non ci sono parti mobili elettromeccaniche per rallentare l'accesso al disco. IOPS in realtà è uguale alla profondità della coda divisa per la latenza e IOPS di per sé non considera la dimensione del trasferimento per un singolo trasferimento su disco. Puoi convertire IOPS in MB/sec e MB/sec in latenza purché tu conosca la profondità della coda e la dimensione del trasferimento.
Produttività sequenziale
Il throughput sequenziale è la velocità con cui è possibile trasferire i dati, in genere misurata in megabyte al secondo (MB/sec) o gigabyte al secondo (GB/sec). La tua metrica di velocità effettiva sequenziale in MB/sec è uguale a IOPS moltiplicato per la dimensione del trasferimento. Ad esempio, 556 MB/sec equivalgono a 135.759 IOPS per una dimensione di trasferimento di 4096 byte, mentre 135.759 IOPS per una dimensione di trasferimento di 8192 byte sarebbero 1112 MB/sec di velocità effettiva sequenziale. Nonostante la sua importanza quotidiana per SQL Server, la velocità effettiva del disco sequenziale spesso viene ridotta in modo abbreviato nello storage aziendale, sia dai fornitori di storage che dagli amministratori dello storage. In realtà è anche abbastanza comune vedere i dischi magnetici effettivi in un contenitore DAS (Direct Attached Storage) o in un dispositivo SAN (Storage Area Network) essere così occupati da non essere in grado di fornire il loro throughput sequenziale completo.
La velocità effettiva sequenziale è fondamentale per molte attività comuni del server di database, inclusi backup e ripristini completi del database, creazione e ricostruzioni di indici e scansioni di lettura sequenziale di tipo data warehouse di grandi dimensioni (quando i dati non rientrano nel pool di buffer di SQL ServerSQL Server). Un obiettivo di prestazioni che mi piace puntare su nuove build di server di database è avere almeno 1 GB/sec di velocità effettiva sequenziale per ogni singola lettera di unità o punto di montaggio. Avere questo livello di prestazioni (o migliore) rende la tua vita molto più semplice come professionista di database. Rende molto più veloci molte delle tue attività di database comuni e ti dà anche la libertà di eseguire regolazioni dell'indice più frequenti quando puoi creare un indice su una tabella di grandi dimensioni in secondi o minuti anziché in ore.
Metriche del carico di lavoro di I/O di SQL Server
Quando si tratta di SQL Server e delle prestazioni di I/O, ci sono una serie di cose che dovresti misurare e monitorare nel tempo. Dovresti conoscere il rapporto di lettura e scrittura per il tuo carico di lavoro per tutti i file di database utente e per tempdb. I rapporti saranno diversi per i diversi tipi di file e carichi di lavoro di SQL Server. Puoi utilizzare le mie query diagnostiche DMV per determinarlo e puoi anche utilizzare la visualizzazione attività del disco in SQL Sentry Performance Advisor per ottenere facilmente una visione più completa dell'attività del disco, da un quadro generale di alto livello, fino in fondo ai singoli file:
Assistente prestazioni SQL Sentry:attività disco
È inoltre necessario misurare le velocità di I/O tipiche per IOPS e throughput sequenziale. In Windows Performance Monitor (PerfMon), letture/sec e scritture/sec mostrano IOPS, mentre i byte di lettura del disco/sec e i byte di scrittura del disco/sec rappresentano il throughput sequenziale. È necessario utilizzare PerfMon per misurare la media dei secondi/lettura del disco e la media dei secondi/scrittura del disco, ovvero la latenza di lettura e scrittura a livello del disco. Infine, puoi utilizzare le mie query diagnostiche DMV per misurare la latenza media di lettura e scrittura a livello di file per tutti i file di database utente e per tempdb.
Metodi per misurare le prestazioni di I/O
È possibile utilizzare la sezione Disco in Monitoraggio risorse di Windows per ottenere una visualizzazione rapida e in tempo reale di alcune metriche chiave del disco per tutti i file di database di SQL ServerSQL Server. Andando più in profondità, puoi utilizzare PerfMon per misurare e monitorare i contatori di prestazioni critici che ho menzionato in precedenza. Prima di avviare la produzione con un nuovo server di database, è necessario eseguire alcuni test di benchmark del disco per determinare il tipo di prestazioni effettivamente in grado di fornire il sottosistema di I/O. In realtà non è così difficile o dispendioso in termini di tempo (se utilizzi gli strumenti giusti), ma spesso viene dimenticato quando viene eseguito il provisioning e il test di un nuovo server di database.
Il primo benchmark del disco che dovresti sempre eseguire è CrystalDiskMark 4.0, che è stato recentemente riscritto per utilizzare il relativamente nuovo programma di benchmark del disco Microsoft DiskSpd. L'interfaccia utente CDM 4.0 consente di scegliere una gamma più ampia di dimensioni dei file di test e consente inoltre di scegliere la profondità della coda e il numero di thread per le esecuzioni di test. Ciò ti consente di ottenere un carico di lavoro I/O più simile a un server e ti consente anche di stressare in modo più appropriato i dispositivi di archiviazione flash NVMe più recenti in grado di gestire profondità di coda superiori a 32.
CrystalDiskMark 4.03 Risultati con QD =32 e thread =1
Figura 2:Risultati CrystalDiskMark 4.03 con QD =32 e thread =4
A differenza delle versioni precedenti di CDM, le due righe più rilevanti per l'utilizzo di SQL Server si trovano al centro della visualizzazione dei risultati. Sono le letture e scritture casuali 4K con un'elevata profondità della coda (32 per impostazione predefinita) e le letture e scritture sequenziali. Dopo aver eseguito alcuni test di benchmark di archiviazione con CrystalDiskMark 4.0, dovresti eseguire alcuni test più approfonditi con Microsoft DiskSpd. In un prossimo articolo, tratterò come utilizzare DiskSpd per eseguire test più completi per SQL Server.
