Stima dei requisiti di I / O per l'uso bursty

Abbiamo un'applicazione che interroga periodicamente un database SQL durante il giorno. Vi sono periodi di zero o solo attività leggera, intervallati da richieste individuali per quantità relativamente elevate di dati. Quando arrivano queste richieste, l'obiettivo primario è quello di consegnare rapidamente i dati e l'obiettivo secondario è farlo in modo economico. A causa della natura dell'applicazione, è abbastanza improbabile che i dati / indici siano stati memorizzati nella cache nella RAM della query precedente (utenti diversi, lavorando su parti diverse dei dati).

Per un sistema che ha un utilizzo relativamente costante, ho sentito la regola empirica osservare la lunghezza della coda del disco e mantenere quel numero relativamente piccolo. Questo verrà eseguito specificamente in AWS, dove ho visto la regola empirica secondo cui una lunghezza della coda del disco di 1 per 100 IOPS è ragionevole.

Come posso stimare i requisiti di I / O per un tale sistema? La lunghezza della coda del disco è un indicatore affidabile quando si gestiscono query singole e sfocate? Ci sono altre metriche che dovrei considerare?

La metrica principale che ho sempre considerato per IO in SQL Server non è IOP o Lunghezza coda disco, ma throughput del disco (sec / read e sec / write). Nel complesso, i database non riguardano il numero di operazioni che è possibile eseguire su un disco, ma la velocità con cui tali operazioni vengono completate. La regola generale è di avere meno di 20 ms / operazione (anche se inferiore è sempre meglio). Maggiori dettagli possono essere trovati in questo articolo .

Lunghezza coda disco è una statistica fasulla e non più rilevante. Il problema è che il valore misura la coda per una singola unità, ma ora che viviamo in un'era di RAID, SAN e altri archivi distribuiti, non c'è modo di tradurre correttamente questo valore in un numero significativo. Un ottimo punto di partenza per le metriche delle prestazioni è questo poster di Quest / Dell che offre molte cose e spiegazioni sul perché o perché non sono importanti. Non devi usarli tutti, ma sono un inizio.

Per testare il tuo IO, devi capire il tuo carico di lavoro al suo apice. Quante transazioni e quanto viene memorizzato nella cache? A meno che tu non sappia e non abbia misurato questi, è davvero difficile giudicare. È possibile creare carichi di lavoro e utilizzare strumenti come SQLIO per testare l'archiviazione, ma per creare un test adeguato sono necessari schemi di carico di lavoro.

Infine, una nota su AWS: per quanto ne so, Amazon non garantirà le prestazioni di I / O in AWS. Ciò è principalmente dovuto al fatto che l'archiviazione è un'enorme risorsa condivisa ed è impossibile misurare i modelli di te e dei tuoi vicini su una particolare area di archiviazione (vedi il problema Noisy Neighbor ).

La mia raccomandazione sarebbe quella di allocare quanta più memoria possibile. SQL Server rimuoverà la memoria dalla memoria solo se è sotto pressione e spazio nel pool di buffer (basato su LRU-K). Pertanto, se il pool di buffer è in grado di memorizzare la maggior parte del database in memoria, è possibile mitigare alcune delle prestazioni bursty. Inoltre, considera le tattiche che possono mantenere "caldi" gli oggetti cache. Infine, tieni d'occhio SQL 2014 e la nuova funzionalità Hekaton .