L'obiettivo principale di questo sito di blog sono le prestazioni in un ambiente SQL Server. Si potrebbe obiettare che le prestazioni iniziano con la progettazione di database e applicazioni. Ma puoi anche sostenere che avere le giuste risorse a disposizione è essenziale per una buona prestazione. Per tutta la discussione sulle giuste risorse (quale modello di CPU, quanta memoria, che tipo di storage), a volte trascuriamo l'atto di pianificazione della capacità:utilizzando i dati che abbiamo per prendere decisioni informate su ciò di cui abbiamo bisogno . La pianificazione della capacità non consiste solo nel determinare la quantità di spazio su disco di cui abbiamo bisogno, ma riguarda anche le risorse che un'istanza di SQL Server deve avere a disposizione per gestire il carico di lavoro.
Nuovo o esistente?
La pianificazione della capacità per una nuova soluzione è davvero complicata. Devi elaborare stime sul carico di lavoro in base alle informazioni raccolte dall'azienda. Ciò significa che devi porre domande difficili su quanti dati si aspettano nel primo mese, nei primi sei mesi e nel primo anno. Quando arriva una nuova soluzione, questa è spesso l'ULTIMA cosa a cui l'azienda sta pensando, quindi molto spesso riceverai risposte vaghe. Nel caso di una nuova soluzione, devi davvero fare uno sforzo per indovinare. Non strapparti i capelli cercando di ottenere numeri esatti.
Se la soluzione proviene da un fornitore, è necessario chiedere al fornitore consigli sulla pianificazione sia sullo spazio necessario che sulle risorse necessarie. Lo ammetto, potrebbero non avere quei dati, ma non ottieni ciò che non chiedi. Non fa mai male provarci.
[Bonus:se il fornitore non ha alcuna informazione da fornire, non sarebbe utile se, dopo che il sistema è in funzione per alcuni mesi, gli invii i tuoi dati... come l'hardware che hai e che aspetto ha il carico di lavoro? Non è necessario che sia un articolo di 20 pagine, ma il feedback potrebbe spingerli nella direzione di essere più proattivi in futuro.]
In termini di una soluzione esistente, se hai problemi di prestazioni o stai cercando di aggiornare l'hardware, ti consigliamo di acquisire informazioni sull'ambiente attuale per pianificarne uno nuovo.
Stoccaggio
Pianificazione per l'importo di spazio di archiviazione necessario è abbastanza semplice, richiede solo una pianificazione anticipata. Nei miei articoli sul controllo dello stato proattivo di SQL Server discuto del monitoraggio dello spazio su disco e includo una query per acquisire informazioni sui file. Questa query acquisisce la dimensione dei file di database per l'istanza e lo spazio utilizzato. È imperativo analizzare questi dati nel tempo e ciò non significa alcune settimane. Stai cercando di vedere come cambiano i file nel corso di mesi, possibilmente per un massimo di uno o due anni, perché i modelli di utilizzo di un'applicazione possono cambiare. Queste informazioni sono facili da acquisire, richiedono poco spazio per l'archiviazione ed è inestimabile avere come riferimento quando si acquista spazio di archiviazione. Se puoi fornire dati quantitativi sulla crescita del sistema, hai molte più possibilità di ottenere lo spazio di cui hai bisogno in anticipo piuttosto che doverlo chiedere in seguito. E quando chiedi spazio, assicurati di includere tempdb nei tuoi calcoli.
Risorse hardware
CPU
L'ottimizzazione delle prestazioni della tua CPU non riguarda solo il numero di CPU che hai, devi anche considerare il modello e il carico di lavoro (ad es. data warehouse con query parallele di grandi dimensioni rispetto a OLTP con query seriali). Con queste informazioni e un piccolo aiuto da parte di Glenn, puoi determinare il miglior processore per il tuo server. Non dimenticare di considerare i costi e le limitazioni delle licenze in base alla tua edizione di SQL Server!
Memoria
La memoria è relativamente poco costosa ed è nostro consiglio acquistare sempre la quantità massima di memoria che un server può contenere. La lettura dei dati dalla memoria è significativamente più veloce rispetto alla lettura dal disco, quindi più dati si adattano alla memoria, meglio è. Nota che l'intero database non ha per entrare nella memoria. Hai solo bisogno del set di dati di lavoro per adattarsi alla memoria. Considera un database da 2 TB. È improbabile che, in uno scenario OLTP, si acceda a tutti i 2 TB ogni giorno. In genere si accede solo ai dati recenti, forse solo gli ultimi 30 o 60 giorni. Questi sono i dati che devono stare in memoria. Ma, naturalmente, raramente vediamo un ambiente OLTP puro, spesso è un ambiente misto perché agli utenti piace eseguire report su insiemi di dati di grandi dimensioni e non esiste un data warehouse o una copia di report del database, quindi hanno per eseguire i rapporti rispetto alla produzione. Questo complica il requisito di memoria. Ora, a volte hai bisogno di quei dati più vecchi in memoria, ma a volte no. È importante capire il carico di lavoro; quali tipi di query sono in esecuzione sul database?
Se stai utilizzando la Standard Edition, verifica di avere più memoria nel server rispetto alla memoria massima supportata. Ad esempio, con SQL Server 2014 e versioni successive, in Standard Edition la quantità massima di memoria che è possibile allocare al pool di buffer (tramite l'impostazione della memoria massima del server) è 128 GB. Pertanto, si desidera avere più memoria nel server (ad es. 160 GB) in modo da poter impostare la memoria massima del server sul valore più alto possibile di 128 GB e avere ancora memoria disponibile per il sistema operativo e altri processi di SQL Server. Inoltre, con SQL Server 2016 SP1 Standard Edition è possibile utilizzare OLTP in memoria, con un limite di 32 GB per database. Questo valore è superiore al valore massimo di memoria del server, quindi se prevedi di utilizzare questa funzione, acquista memoria di conseguenza.
Archiviazione
Quando si parla di requisiti di prestazioni per l'archiviazione, si sente spesso parlare di IOPS (operazioni di input/output al secondo). In effetti, questo articolo è stato ispirato da una domanda di uno spettatore che ha visto il mio corso Pluralsight su Benchmarking e Baselining. La domanda era:"Come si correlano i contatori di Performance Monitor per letture e scritture al secondo alle connessioni utente per stimare il numero di IO per utente?" Le letture e le scritture al secondo sono le operazioni di input/output, quindi abbiamo questi dati disponibili tramite PerfMon a livello di istanza e questo è ciò che usi per definire i requisiti IOPS per un'istanza.
Tuttavia, se sai legge e scrive e connessioni utente, quindi puoi fare un po 'di matematica e capire IOPS per utente. Questo è utile se hai intenzione di far crescere la soluzione e aggiungere più utenti. Vuoi assicurarti che la soluzione si ridimensionerà e un'opzione che hai è prendere gli IOPS calcolati per utente, in base al numero X di utenti, e quindi stimare gli IOPS dell'istanza per il numero Y di utenti. Ora, facciamo molte ipotesi con questo calcolo. Partiamo dal presupposto che il modo in cui le nuove connessioni utilizzano il sistema sia lo stesso di oggi:potrebbe essere o non essere il caso alla fine, non lo saprai finché il sistema non sarà a posto. Quando comprendi questo valore (letture + scritture / connessioni utente =IOPS medi per utente), allora sai come stimare IOPS per una soluzione basata sulle connessioni utente previste.
Quindi porti queste informazioni al tuo addetto all'archiviazione per discutere le potenziali configurazioni disponibili. È possibile calcolare l'IOPS massimo per una configurazione del disco, a condizione di disporre di informazioni sui dischi (ad es. il numero di dischi, la velocità, la dimensione e la configurazione RAID). È possibile testare il throughput IO per un'unità utilizzando CrystalDiskMark, anche se ciò potrebbe non essere possibile se lo spazio di archiviazione non è stato deciso. Una volta che è a posto, tuttavia, dovresti eseguire questo test per assicurarti che l'IOPS per una determinata unità possa soddisfare il carico di lavoro previsto.
Gli IOPS sono solo un modo per esaminare le prestazioni dello storage. Tieni presente che questi dati ti dicono quanto IO si sta verificando e, idealmente, se conosci IOPS e hai lo spazio di archiviazione per soddisfare i requisiti, la latenza dovrebbe essere minima. Ma la latenza è ciò che influisce sulle prestazioni. Per determinare quale latenza esiste, dovrai utilizzare uno strumento come DiskSpd per confrontare lo spazio di archiviazione. Glenn ha un ottimo articolo che spiega come analizzare le prestazioni IO e poi un altro articolo su come utilizzare DiskSpd per testarlo per comprendere la latenza. Consiglio vivamente di rivedere entrambi gli articoli se non hai mai esaminato lo spazio di archiviazione e le prestazioni in precedenza.
Conclusione
La pianificazione della capacità non è solo sapere quanto spazio è necessario per i file di database. È necessario comprendere il carico di lavoro e ciò che richiede in termini di CPU, memoria e risorse del disco. Per fare ciò, hai bisogno di dati... il che significa che hai bisogno di catturare le linee di base. La mia prima sessione nella comunità di SQL Server è stata nel dicembre del 2010 ed era sull'argomento delle linee di base. Sei anni dopo parlo ancora della loro importanza e sento ancora dalle persone che non hanno questi numeri. Se vuoi eseguire una pianificazione della capacità intelligente e mirata, devi raccogliere i dati appropriati... altrimenti stai solo supponendo.
