... speravo di poter ottenere ... una stima approssimativa di ciò che dovremmo eseguire.
Senza ulteriori informazioni su query e dimensioni dei dati, è davvero difficile fornire qualsiasi tipo di preventivo, per non parlare di un preventivo accurato.
Database: database aziendale sql server 2008 r2
Windows: Windows 2008 r2 Enterprise 64 bit, abbastanza sicuro in esecuzione su VMware.
Processore: CPU Intel (R) Xeon (R) E7-4860 a 2,27 GHz 2,26 GHz (2 processori)
Memoria installata: 4 GB
Due processori (suppongo che questo sia esposto nella VM come 2 core) possono o meno essere sottoposti a provisioning insufficiente. I core assegnati a una VM non sono necessariamente mappati direttamente sui core fisici (o addirittura non possono utilizzare il 100% di un singolo core quando è necessario!), Quindi potresti scoprire che questa è una risorsa più flessibile della memoria. Senza ulteriori informazioni sul carico di lavoro o sulla configurazione hardware / di virtualizzazione, direi che aumentarlo a 4 sarebbe utile.
Allocazione della memoria. Oh ragazzo. Questo è fortemente sotto-provisionato per il carico di lavoro. Windows stesso ha bisogno di un minimo di 2-3 GB per rimanere felice, e ciascuno dei 2 utenti che eseguono BIDS sulla scatola richiederà almeno 500 MB ciascuno. E con ciò, la scatola è già al massimo e non ho nemmeno iniziato a capire di quanto il database avrà bisogno.
La maggior parte degli utenti interagisce con il database tramite il sito Web asp.net e il sito Web del server di report.
Non hai detto, ma se questi sono in esecuzione sulla stessa scatola, è necessario prendere in considerazione anche i requisiti di memoria per essi.
Infine, abbiamo un'operazione di data warehousing abbastanza coinvolta che probabilmente porta 3 milioni di record al giorno tramite pacchetti SSIS che funzionano anche sul server.
Supponendo che questo funzioni di notte quando non ci sono utenti live sul sistema, non vedo questo come un problema a meno che non ci voglia troppo tempo per essere eseguito. Questa parte delle cose è l'ultima delle tue preoccupazioni; gli utenti live sono più importanti.
Le nostre precedenti richieste di memoria aggiuntiva sono state respinte con la risposta comune che è necessario eseguire ulteriori ottimizzazioni delle query.
Come ho dimostrato sopra, l'attuale quantità di memoria fornita è completamente inadeguata. Allo stesso tempo, tuttavia, all'altra estremità dello spettro, è estremamente improbabile che tu sia in grado di ottenere abbastanza memoria per poter mantenere l' intero database in memoria contemporaneamente.
Anche se hai ottenuto una risposta generale come quella (che, tra l'altro, probabilmente aveva più a che fare con quanto persuasiva fosse la tua giustificazione per le risorse aggiuntive e non l' effettivo utilizzo delle risorse stesse), è molto probabile che l'efficienza del database potrebbe essere migliorata. Eppure non esiste una quantità di messa a punto da sola che può risolvere i problemi che stai riscontrando ora; il suggerimento di ciò è per me un completo antipasto.
Adotterò l'approccio generale secondo cui la quantità di memoria attualmente fornita è inferiore al minimo richiesto (che dovrebbe essere corretto al più presto) e potrebbero essere necessarie risorse aggiuntive per migliorare l'esperienza dell'utente a un livello utilizzabile mentre vengono apportati miglioramenti per aumentare l'efficienza di i sistemi.
Ecco alcuni pensieri (in ordine di attacco):
Potrai vincere se si può dimostrare quanto le prestazioni migliorano ogni volta che si ottiene più risorse provisioning. Tieni traccia delle metriche delle prestazioni utilizzando la registrazione di Performance Monitor (nota: la parte relativa alla registrazione è molto importante), compresi i tempi di risposta del sito Web, se possibile. Inizia a farlo ora , prima di fare qualsiasi altra cosa. Quando finalmente raggiungi la quantità minima di memoria (non otterrai subito 32 GB), improvvisamente ora hai la prova che la memoria aggiunta ha migliorato le cose ... il che significa che aggiungere ancora di più probabilmente aiuterebbe anche! Se non raccogli una linea di base sulla configurazione corrente, perderai la barca quando le cose vengono portate al livello minimo raccomandato.
Analizza le statistiche di attesa del tuo server . Questo ti dirà qual è il più grande collo di bottiglia nel sistema. Probabilmente avrai PAGEIOLATCH_XXil tempo di attesa più comune / più alto, che indica che si sta eseguendo troppo I / O per recuperare le pagine dal disco. Questo può essere alleviato aggiungendo memoria, quindi gli I / O fisici diventano meno frequenti poiché i dati necessari sono già in memoria. Mentre questa analisi è praticamente una conclusione scontata, il fatto che tu abbia raccolto queste statistiche ti dà più munizioni quando giustifichi la necessità di risorse.
Come accennato in precedenza, non è stato soddisfatto il minimo requisito di memoria. Raccogli il set di requisiti hardware consigliati per tutto il software in esecuzione e magari cattura anche screenshot di Task Manager. Questo da solo dovrebbe essere sufficiente per giustificare almeno 4-8 GB in più, sul posto. Se continuano a rifiutare, prova a convincerli a permetterti di provarlo per una settimana e poi restituiscilo (stai raccogliendo statistiche sulle prestazioni, quindi non dovrai restituirlo perché a metà settimana " riuscirò a dimostrare quanto è migliorata la situazione). Se continuano a rifiutare, sei pronto per fallire; URLT .
Se è possibile scaricare parte del carico di lavoro (in particolare, evitare il remoting se possibile), ciò aumenterà la quantità di memoria disponibile per il database, il che è più critico.
Non sarai in grado di adattare l'intero database in memoria in una sola volta, il che significa che devi impostare le impostazioni di memoria massima di SQL Server con molta attenzione per evitare un sovraccarico della memoria , il che uccide le prestazioni come nient'altro . Il commit eccessivo in realtà è persino peggio del semplice non riuscire a contenere tutti i dati in memoria. È molto probabile che tu sia in questo scenario in questo momento semplicemente perché non c'è proprio memoria disponibile ed è probabile che l'impostazione della memoria massima sia impostata sul valore predefinito (illimitato).
Dal momento che stai eseguendo SQL Server Enterprise Edition e la memoria è un premio, prenderei in seria considerazione l'implementazione della compressione dei dati . Ciò compenserà un aumento dell'utilizzo della CPU per risparmiare spazio di memoria (e quindi ridurre gli accessi al disco, che sono relativamente molto lenti).
Ottimizza il database. È probabile che le strutture e le query possano utilizzare miglioramenti per quanto riguarda l'indicizzazione e i modelli di accesso. Inoltre, se molti dati vengono scansionati e aggregati frequentemente, può essere molto utile creare viste indicizzate, tabelle di riepilogo o report pre-calcolati.
Questo potrebbe essere un problema perché probabilmente significa più provisioning hardware, ma implementare una soluzione di memorizzazione nella cache. La query più veloce è quella che non fai mai .
Queste sono solo alcune idee. La linea di fondo è che il tuning da solo non risolverà i problemi qui, né l'hardware da solo, anche se quest'ultimo probabilmente allevierà la maggior parte dei problemi immediati. È davvero così: lancia l'hardware sul problema a breve termine per spegnere l'incendio e lancia l'ottimizzazione sul problema a lungo termine per correggere la causa principale nel miglior modo possibile.