Server del data warehouse. Come si calcolano le specifiche RAM / CPU?

Sto provando a scrivere una specifica per un server di data warehouse per l'aggiornamento pianificato del data warehouse.

Mentre eseguiamo server virtuali su host VMWare, abbiamo la possibilità di aggiungere o rimuovere risorse, se necessario. In passato abbiamo aggiunto in modo incrementale RAM e CPU come richiesto. Poiché le nostre richieste sono aumentate, abbiamo fatto pressioni per ulteriori risorse. (principalmente disco e RAM).

Chiediamo di più. Ci danno il meno possibile.

Tuttavia, di recente, ogni volta che parliamo di risorse, siamo criticati per non aver specificato la macchina in primo luogo, e ora mi viene detto che gli host di sviluppo sono al massimo, non c'è più RAM disponibile.

Siamo una piccola organizzazione del governo locale con circa 50 utenti regolari del DW. Nell'uso quotidiano normale funziona bene. Otteniamo buone prestazioni delle query mdx e i nostri report e dashboard sono veloci. Gli utenti sono felici

Tuttavia, i nostri processi ETL si svolgono per tutta la notte e stiamo iniziando a vedere prove della pressione della memoria durante l'elaborazione simultanea dei datamart. Ieri sera SSIS non è riuscito con avvisi relativi a un "errore di memoria insufficiente".

Il nostro server DW esistente è Win 2008 R2 con 4 CPU e 16 GB di RAM con SQL 2012 Std. Ho una memoria massima del server impostata su 12 GB, lasciando 4 GB per sistema operativo e servizi ecc. Il nostro DW esistente ha 3 datamarts / cubi OLAP e ne stiamo sviluppando altri 2.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Il nostro nuovo server dovrebbe essere Win 2012 con SQL 2016 Enterprise. Eseguirà SQL, SSIS, SSRS e SSAS. Lo storage non è un problema, ma non sono sicuro di RAM e CPU.

Secondo la Guida di riferimento del data warehouse di Fast Track per SQL Server 2012 , il minimo che dovrei avere è 128Gb per una macchina a 2 socket ... che sembra un po 'eccessivo. I requisiti hardware e software per l'installazione di SQL Server 2016 consigliano almeno 4 GB di RAM per SQL 2016. Questa è una differenza!

Quindi .. Qual è un buon punto di partenza? 32Gb? 64gb? Come posso giustificare la mia posizione di partenza (specifica) all'IT?

Ci sono delle buone guide su come calcolare le risorse del server?

Ci sono delle buone regole pratiche?

Quali sono gli ingredienti / le metriche chiave per il dimensionamento della RAM in un contesto DW?

• Il volume di dati?
• Il numero di cubi?
• Il tempo necessario per eseguire ETL o elaborare un cubo?
• Picco di carico di elaborazione durante la notte o prestazioni visto dagli utenti finali durante il giorno?

Ottima domanda, e qualche anno fa ho fatto una sessione al riguardo su TechEd, chiamata Building the Fastest SQL Server:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

In esso, spiego che per i data warehouse è necessario uno spazio di archiviazione in grado di fornire dati abbastanza velocemente da consentire a SQL Server di utilizzarli. Microsoft ha creato una grande serie di white paper chiamati Architettura di riferimento del data warehouse di Fast Track che include i dettagli hardware, ma l'idea di base è che lo storage deve essere in grado di fornire prestazioni di lettura sequenziale da 200-300 MB / sec, per core della CPU, in per tenere occupate le CPU.

Maggiore è il numero di dati che è possibile memorizzare nella memoria cache, maggiore è lo spazio di archiviazione che è possibile ottenere. Ma hai meno memoria del necessario per memorizzare nella cache le tabelle dei fatti con cui hai a che fare, quindi la velocità di archiviazione diventa molto importante.

Ecco i tuoi prossimi passi:

• Guarda quel video
• Metti alla prova la tua memoria con CrystalDiskMark ( Ecco come )
• Con 4 core, avrai bisogno di almeno 800 MB / sec di throughput in lettura sequenziale
• Se non lo hai, considera l'aggiunta di memoria fino a quando il dolore non scompare (e la memorizzazione nella cache dell'intero database nella RAM non è impensabile)

Supponi di avere un database da 200 GB con cui hai a che fare e che non puoi ottenere una velocità di archiviazione sufficiente per tenere occupati i core. Non è impensabile avere bisogno non solo di 200 GB di RAM, ma anche di più - perché dopo tutto, SSIS e SSAS vogliono davvero fare il loro lavoro in memoria, quindi devi avere i dati del motore disponibili, oltre allo spazio di lavoro per SSIS e SSAS.

Questo è anche il motivo per cui le persone cercano di separare SSIS e SSAS su macchine virtuali diverse: hanno tutti bisogno di memoria contemporaneamente.

La Guida di riferimento del data warehouse di Fast Track per SQL Server 2012 è in realtà un po 'obsoleta, soprattutto se ti stai trasferendo a SQL Server 2016 (davvero? Chiamami), non solo in termini di tempo, ma anche di funzionalità.

In SQL Server 2012, la versione su cui si basa il fast track, è possibile disporre solo di indici columnstore non cluster. Si tratta di strutture separate dalla tabella principale, quindi comportano un ulteriore sovraccarico di memoria e di elaborazione a causa delle copie compresse dei dati.

Da SQL Server 2014 in poi, è possibile disporre di indici columnstore cluster. Questi offrono una compressione massiccia e un potenziale aumento delle prestazioni per query aggregate / di riepilogo. Sono assolutamente appropriati per le tabelle dei fatti, quindi la tabella dei fatti da 32 GB potrebbe apparire più simile a ~ 8-12 GB. YMMV. Ciò cambia leggermente il paesaggio, no? Guardando il tuo tavolo (e il pollice in aria) potresti forse scappare con 32 GB ma sparerei per 64 GB (non è come se tu chiedessi 1 TB) e lascerei spazio per altri servizi e crescita, la giustificazione è che questo consente di tenere in memoria il tuo tavolo più grande, lasciare spazio alla crescita e spazio per altri servizi. Non devi dire loro della compressione. Una cosa che devi tenere a mente con il dimensionamento è che non stai solo dimensionando i tuoi dati ora, ma come saranno, diciamo tra un anno. Tuttavia, nota anche che le prestazioni per le ricerche puntuali possono essere orrende, ma mentre ti sposti a SQL Server 2016 puoi aggiungere altri indici o puoi sempre considerare gli indici Columnstore per Real-Time Operational Analytics anche se avrai bisogno di più memoria per quello :)

Come stai andando avanti con i CTP, attualmente in CTP3.3 ha la maggior parte delle funzionalità che potresti voler usare disponibili, quindi dici di non avere risorse per le prove, ma potresti ottenere una prova di Windows Azure , avviare una macchina virtuale, creare alcuni dati di esempio, testare la compressione, le prestazioni di funzionalità e query chiave ecc. gratuitamente. O se hai una licenza MSDN questa è integrata.

In sintesi, dimensioni per consentire alla tabella più grande di essere in memoria (oltre ad altre cose) o impostare una semplice prova (gratuitamente nel cloud) per ottenere le prove concrete che stai cercando. Ricordati di deallocare la VM al termine:)

Presumibilmente durante lo sviluppo e la manutenzione dei pacchetti ETL su macchine di sviluppo locale a volte utilizzi dati di test di scala simile o più ampia di quello che ti aspetti nella produzione e, in caso contrario, potresti prendere in considerazione la possibilità di farlo (dati reali anonimi o dati di test generati algoritmicamente, se i tuoi dati reali sono sensibili).

In questo caso, puoi eseguire il processo in varie condizioni di memoria e profilarlo, per vedere il punto in cui più RAM smette di fare una differenza enorme - utile come regole empiriche e congetture istruite, niente di benchmarking e profiling può fornire risposte molto più concrete e come bonus può evidenziare ovvi colli di bottiglia che potrebbero essere facili da ottimizzare. Ovviamente i tuoi ambienti di sviluppo / test potrebbero non corrispondere esattamente alla produzione, quindi potresti dover usare l'esperienza per interpretare come i risultati potrebbero cambiare.

Se si esegue SSIS sullo stesso computer dei database, è necessario assicurarsi che le istanze del motore di SQL Server siano impostate per non rivendicare mai tutta la memoria. La carenza di memoria non solo può causare errori OOM in SSIS, molto prima di quel momento può causare problemi significativi di prestazioni in quanto esegue lo spooling dei buffer su disco quando potrebbe altrimenti conservarli nella RAM. Quanto devi prenotare per SSIS e altre attività varierà notevolmente a seconda del processo, quindi di nuovo la profilazione è un buon modo per valutare questo. Si consiglia spesso di eseguire SSIS su un computer separato per semplificare la gestione, sebbene si possano considerare problemi di throughput di rete e licenze.

Aggiornare

Se, come da tuo commento, non ci sono risorse disponibili per eseguire benchmark realistici per valutare dove diminuiscono le prestazioni (e / e iniziano a verificarsi errori OOM e problemi correlati) se viene allocata una quantità di RAM insufficiente, le cose diventano notevolmente più ondulate senza una conoscenza approfondita del magazzino e dei processi ETL. Una regola empirica per il database del magazzino stesso: vuoi abbastanza RAM per essere in grado di contenere quindi tutti gli indici più comunemente usati, e poi alcuni per consentire i dati meno comunemente utilizzati e altro ancora per consentire la crescita prevista nel prossimo / medio futuro.

Il calcolo può essere errato: sp_spaceUsed non scompone le cose in base all'indice, quindi dovrai eseguire una query direttamente su sys.allocation_units e sugli amici. Ci sono alcuni esempi là fuori per iniziare, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 / sembra il migliore dei primi che sono venuti da una rapida ricerca.

Oltre alle esigenze di esecuzione del DB del magazzino stesso, ricordarsi di aggiungere i requisiti RAM per SSIS se deve essere in esecuzione sullo stesso computer e assicurarsi che SQL Server abbia i limiti di RAM in atto per garantire che questa memoria sia effettivamente disponibile per SSIS.

Dalle dimensioni complessive dei dati che elenchi, il mio istinto suggerisce che 32 GB sarebbe il minimo assoluto che consiglierei solo per il motore di database e SSIS, impostando le istanze di SQL da utilizzare al massimo 26 e mentre stai anche eseguendo SSRS e altri servizi sulla stessa macchina un minimo ragionevole con alcune prove future sarebbe 64 GB (i due terzi dei dati attuali dovrebbero adattarsi a quello dopo che altri servizi e prenotazioni sono stati tagliati). Ovviamente, citare il mio istinto non ti porterà molto lontano nelle discussioni con le persone della tua infrastruttura però ...