SQL Server tempdb sul disco RAM?


11

Il nostro database di applicazioni per i fornitori richiede molto TempDB.

Il server è virtuale (VMWare) con 40 core e 768 GB di RAM, con SQL 2012 Enterprise SP3.

Tutti i database, incluso TempDB, sono su SSD di livello 1 in SAN. Abbiamo 10 file di dati tempdb, ognuno pre-cresciuto a 1 GB e non si auto-crescono mai. Lo stesso con il file di registro da 70 GB. Le flag di traccia 1117 e 1118 sono già impostate.

sys.dm_io_virtual_file_stats mostra oltre 50 Terabyte letti / scritti su dati tempdb e file di registro nell'ultimo mese, con io_stall cumulativo di 250 ore o 10 giorni.

Abbiamo già messo a punto il codice del fornitore e gli SP negli ultimi 2 anni.

Ora, stiamo pensando di posizionare i file tempdb su RAM Drive poiché abbiamo un sacco di memoria. Poiché tempdb viene distrutto / ricreato al riavvio del server, è un candidato ideale da collocare nella memoria volatile che viene anche svuotata al riavvio del server.

Ho provato questo su un ambiente inferiore e ha portato a tempi di interrogazione più rapidi ma a un maggiore utilizzo della CPU, perché la CPU sta facendo più lavoro invece di aspettare su un'unità tempdb lenta.

Qualcun altro ha messo il proprio tempdb su RAM in sistemi di produzione ad alto oltp? C'è qualche grosso svantaggio? Ci sono venditori da scegliere o evitare in modo specifico?


Forse il tuo fornitore sta usando troppo tempDB?
paparazzo,

@Max, quella domanda risponde solo a una parte del problema 'se le scritture di tempdb vanno sul disco' .. non leggendo da tempdb
d -_- b

1
L'uso dell'SSD a livello SAN non sta effettivamente ottenendo molti vantaggi a causa della latenza della rete. Inserire un SSD NVMe in SQL Server ed eseguire tempdb su di esso.
Max Vernon,

ho appena cercato su google "nvme ssd vs ramdisk", e il primo risultato è un post reddit che afferma che quest'ultimo è ~ 3 volte più veloce. Inoltre è più semplice che guidare un datacenter e installarlo nel blade :)
d -_- b

2
Microsoft utilizza le schede PCI-E FusionIO in alcuni dei loro cluster (esiste una soluzione alternativa in cui è ancora possibile utilizzare tempdb con i dischi locali che utilizzano). L'interfaccia PCI-E come ha sottolineato Max è considerevolmente più veloce. Ti consigliamo di misurare gli interrupt della CPU al secondo per misurare se ricevi più richieste al secondo. Dovresti essere come la latenza del disco è una delle principali cause di richieste di interruzione basse (non ora SQL).
Ali Razeghi,

Risposte:


7

In primo luogo, patch: assicurati di essere sul Service Pack 1 Aggiornamento cumulativo 10 o più recente del 2012. In SQL 2014, Microsoft ha modificato TempDB in modo da renderlo meno desideroso di scrivere su disco , e lo ha incredibilmente portato indietro in CU10 SP1 2012 , in modo da poter alleviare la pressione di scrittura di TempDB.

In secondo luogo, ottieni numeri esatti sulla tua latenza. Controlla sys.dm_io_virtual_file_stats per vedere lo stallo di scrittura medio per i tuoi file TempDB. Il mio modo preferito per farlo è:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

Guarda la sezione delle statistiche dei file e concentrati sulle scritture fisiche. I dati SinceStartup possono essere un po 'fuorvianti poiché includono anche i periodi in cui CHECKDB è in esecuzione e ciò può davvero martellare il tuo TempDB.

Se la latenza di scrittura media è superiore a 3 ms, quindi sì, potresti avere memoria a stato solido nella tua SAN, ma non è ancora veloce.

Considerare prima gli SSD locali per TempDB. I buoni SSD locali (come le schede PCIe NVMe di Intel, che costano meno di $ 2k USD specialmente alle dimensioni che stai descrivendo) hanno una latenza estremamente bassa, inferiore a quella che puoi ottenere con l'archiviazione condivisa. Tuttavia, sotto la virtualizzazione, ciò presenta uno svantaggio: non è possibile vMotion il guest da un host all'altro per reagire al caricamento o a problemi hardware.

Prendi in considerazione un'unità RAM per ultima. Ci sono due grandi gotcha con questo approccio:

In primo luogo, se hai davvero un'attività di scrittura TempDB pesante, la velocità di modifica in memoria potrebbe essere così alta che non sarai in grado di vMotion l'ospite da un host all'altro senza che nessuno se ne accorga. Durante vMotion, è necessario copiare il contenuto della RAM da un host a un altro. Se sta davvero cambiando così velocemente, più velocemente di quanto tu possa copiarlo sulla tua rete vMotion, puoi incorrere in problemi (specialmente se questa casella è coinvolta con mirroring, AG o un cluster di failover).

In secondo luogo, le unità RAM sono software. Nei test di carico che ho fatto, non sono rimasto molto colpito dalla loro velocità con un'attività TempDB davvero pesante. Se è così pesante che un SSD di livello aziendale non riesce a tenere il passo, allora dovrai tassare anche il software dell'unità RAM. Avrai davvero voglia di caricare questo test pesantemente prima di andare in diretta - prova cose come molte ricostruzioni simultanee di indici su indici diversi, tutti usando sort-in-tempdb.


1

La creazione di un'unità RAM dovrebbe essere banale. Molte chiavette USB e unità ottiche avviabili creano un'unità RAM e memorizzano lì i file del sistema operativo. Il file system di root è quindi in memoria. In Windows, nel corso della giornata, un'unità RAM è stata caricata come driver di dispositivo in config.sys. Di solito il driver è stato caricato in memoria elevata. Secondo me, questa è una soluzione molto buona e semplice. Se ho creato la tua soluzione utilizzando un'unità RAM, ne vorrei sapere. Vorrei fare qualcosa di simile, ma vorrei scrivere nella memoria permanente e archiviare un db nella RAM. Nel mio caso abbiamo macchine che possono installare più RAM di quante ne possano usare il sistema operativo. La creazione di un disco RAM prima del caricamento del sistema operativo consentirà l'utilizzo della RAM che altrimenti il ​​sistema operativo non vedrebbe.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.