perché io_stall_writes_ms è molto più alto per tempdb?

Abbiamo i file di dati utente e di sistema sulla stessa unità disco. (Io_stall_write_ms / (1.0 + num_of_writes)) è inferiore a 2 per i file utente, ma i file tempdb sono in genere superiori a 400. Vedo che su alcuni server e sono curioso se c'è un motivo per cui ci vuole più tempo per scrivere su tempdb di un normale file di dati del database.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Grazie,

Risposta breve: vedere bancarelle IO superiori può o meno essere un problema in sé. È necessario cercare ulteriori informazioni per scoprire se si riscontra un problema. Sembra un po 'alto, sì, ma stai soffrendo? In tal caso, probabilmente è perché o il tuo sistema IO non gestisce correttamente il carico (perché non può, perché hai tutto su un disco o qualche altro motivo) o stai facendo troppo in TempDB (cambiando il primo problema - le prestazioni IO - è probabilmente una soluzione più semplice ed efficiente, ma prima determina se hai un problema)

La discussione / risposta più lunga:

Qui ci sono due domande:

1.) Cosa devo fare quando vedo bancarelle IO alte?

Prima di tutto, "alto" è negli occhi di chi guarda. Se dovessi chiedere a 10 DBA cosa sia "troppo alto" per le bancarelle IO, probabilmente riceveresti 2-3 risposte diverse con numeri, 5-6 risposte "Dipende" e uno sguardo vuoto. La mia ipotesi è che una media di 400ms sia potenzialmente troppo alta qui, specialmente quando gli altri DB sono 2ms o meno per il tempo medio di stallo.

Indipendentemente da quale database sta vedendo le bancarelle alte, dovresti avvicinarti allo stesso modo. Uno stallo IO è quello che sembra ... Una richiesta IO che richiede più tempo del previsto ... Stallo. Questi accadono. Accadono continuamente in un sistema con risorse condivise e risorse limitate (in realtà tutti i nostri sistemi). Diventano un problema quando le bancarelle diventano problemi di prestazioni o portano a loro. Quindi confido che stai guardando qui come una parte proattiva del monitoraggio o perché hai riscontrato problemi di prestazioni che stai risolvendo. Inoltre, non vogliamo perdersi solo nelle bancarelle IO. Stiamo guardando un pezzo del puzzle e non il quadro generale. Può essere fastidioso guardare solo le statistiche di attesa o le statistiche dei file dall'ultimo riavvio di SQL perché si sta guardando in ogni momento e alcune finestre di manutenzione o finestre di carico pesante potrebbero inclinare i contatori. Quindi assicurati di guardare il quadro completo.

Ma quando sospetto di avere un problema di prestazioni del disco o vedere qualcosa in una query come questa, normalmente seguo un processo che assomiglia a:

1. Guarda le statistiche di attesa sul server. @swasheck ha condiviso un ottimo collegamento come commento in una risposta di seguito. Questo ti porta al post di Paul Randal su come guardare e analizzare le statistiche di attesa in SQL Server. Vai lì. Che tipo di attese stai vedendo? Vedete attese legate alla IO prestazioni ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, ecc?). Se lo fai, è un'altra indicazione che hai alcuni problemi di prestazioni relativi all'IO, proprio come le bancarelle di IO. Ma ti dà un'altra forma di accordo qui.
2. Guarda le prestazioni dell'IO. In particolare, guarda all'interno del perfmon i contatori Physical Disk:Avg Disk Sec/Reade Avg Sec Disk Sec/Write. Questi misurano la tua latenza. Guarda questi contatori per un periodo di tempo salvato in un file di registro delle prestazioni. Cosa hai visto per le medie? Se vedi numeri superiori a 0,020 secondi (20 ms) questo potrebbe essere un problema. Se vedi numeri superiori a 40-50 ms media o superiore è un'indicazione più ferma di un problema. Guarda anche i tuoi picchi? Quanto in alto vanno e quanto durano? Se vedi picchi nelle centinaia di ms e durano per decine o decine di secondi o più e / o si verificano frequentemente, è più probabile che tu abbia un problema con le tue prestazioni di I / O per il tuo carico di lavoro.
3. Guarda la tua configurazione IO. Che cos'è? Dischi locali? SAN? Array di archiviazione? Che tipo di IOP e di tutto ciò dovresti vedere da questo? È sufficiente per quello che stai cercando di fare? Potresti aver sottodimensionato il tuo IO per il tuo carico di lavoro. Non limitarti a guardare i tuoi mandrini fisici, le impostazioni RAID, ecc. Guarda i tuoi percorsi verso i tuoi dischi. Stai spingendo tutto attraverso un singolo link da 1 GB che condividi con un sacco di altro traffico? Puoi esaminare le metriche delle prestazioni del disco dal punto di vista dello storage.

( Nota: per questa analisi delle statistiche di attesa e dell'analisi del perfmon - guarda i vari periodi e tipi di utilizzo. Di notte hai statistiche di utilizzo diverse rispetto a quelle di giorno? Finestre di elaborazione batch? Finestre di manutenzione in cui ricostruisci molti indici? Guarda questi strumenti durante ciascuno di questi periodi e capisci cosa vedi per ciascuno)

Un'altra considerazione sulle prestazioni IO qui -

• Hai detto che i DB di sistema e i DB utente sono condivisi. Questa produzione è? In tal caso, non è sempre lo scenario migliore. Condividete anche file di registro e file di dati sulle stesse unità? Non è nemmeno lo scenario migliore. Cos'altro condivide questo spazio di archiviazione? In un mondo in cui ti preoccupi di mandrini, gruppi di incursioni e dischi e devi prendere decisioni su chi ottiene i dischi con le prestazioni migliori, tendo a (come regola generale ... che non sono grandiosi avere nel mondo DB ma questo tende a essere vero) vai con il mio più veloce e più dedicato a TempDB (più su quello sotto), quindi i file di registro, quindi i file di dati. In un mondo in cui hai una grande pila di dischi su un dispositivo come NetApp, Dell Equal Logic o EMC VNX, ecc.

2.) Quali sono alcuni dei motivi per cui TempDB potrebbe essere più alto?

Quindi TempDB è un database e può avere bancarelle IO come qualsiasi altro database come ho appena discusso. Ma quali sono alcuni dei motivi per cui TempDB può avere letture più elevate? (non esaustivo, accolgo con favore aggiunte o pensieri nelle modifiche, altre risposte o commenti) -

1. A causa del tuo codice: stai usando TempDB molto nel tuo codice di proposito? Molte tabelle temporanee e variabili di tabella create e distrutte? Fare molte cose in TempDB in questo modo? Non è necessariamente un male o un bene, ma potresti guardarlo e capire il tuo modello di utilizzo intenzionale di TempDB.
2. TempDB è un cavallo di lavoro condiviso - TempDB è un database utilizzato come spazio temporaneo per oggetti temporanei definiti dall'utente e varie tabelle di lavoro e operazioni utilizzate dall'intera istanza SQL. Quanti DB utente ci sono? Che tipo di carico di lavoro vedi in generale? TempDB è una risorsa per tutte le cose da condividere.
3. Query inefficienti e memoria insufficiente - Forse ci sono query che non usano gli indici abbastanza strettamente o che stanno eseguendo grandi operazioni di scansione e ordinamento. Operazioni di hash di grandi dimensioni e la memoria sul server non è sufficiente per queste. Queste operazioni "si riverseranno" su TempDB come tabelle di lavoro dietro le quinte. A volte questo può essere evitato osservando i piani di query e indicizzazione o ottimizzazione delle query. A volte succede (più che altro sui carichi di lavoro di magazzino, trovo). Se hai memoria sufficiente, questo può essere d'aiuto, ma a volte queste query possono ancora essere invase. Guarda anche questo.
4. Stai utilizzando il livello di isolamento dell'istantanea con commit della lettura con un discreto numero di aggiornamenti nel tuo sistema? Ciò può anche comportare un aumento dell'attività TempDB.

Il punto è che TempDB è usato in molti modi e non mi sorprende affatto vederlo come uno dei database più occupati, se non il più intenso. Inoltre non mi sorprende quando lo vedo come avere il numero più alto e la più alta media di tutte le basi di dati nel sito di un cliente. A volte è la natura del suo carico di lavoro. Guardare alcune delle cose che ho menzionato qui può sicuramente aiutarti a determinare se questi numeri indicano un problema e, in caso affermativo, come approfondire la risoluzione.

TempDB è condiviso tra tutti i database sull'istanza. Quindi a volte può esserci contesa all'interno di TempDB per alcune pagine: SGAM , GAM e PFS . In breve, queste pagine tengono traccia di ciò che è stato finora utilizzato in TempDB e di dove è disponibile spazio per un nuovo utilizzo.

In genere, ciò viene risolto aggiungendo più file di dati a TempDB. Esistono diverse filosofie sul numero corretto, ma tutti concordano sul fatto che dovresti averne più di una.

Ecco alcune query da eseguire ...

Questo ti mostrerà quanti file ha TempDB e dove si trovano.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Questo ti mostrerà quante CPU e core hai.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Questo ti mostrerà quanti nodi e core NUMA per nodo NUMA hai.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Questo ti mostrerà quali pagine stanno vivendo attese in TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Ecco un articolo che approfondisce un po 'il problema della contesa sulla pagina.

OK, quindi ora la parte della filosofia ... :-)

Per quanto mi riguarda, se mi trovo su un sistema SMP , voglio solo un numero di file pari alla metà dei core totali .

Se mi trovo su un sistema NUMA , allora voglio solo tanti file quanti core per nodo NUMA .

Tuttavia, raramente vedo qualche miglioramento per avere più di quattro file per TempDB. Quindi di solito inizio con quattro e controllo la contesa come spiegato nell'articolo a cui mi sono collegato.

Se continuo a riscontrare problemi, ne aggiungerei altri due. Controlla di nuovo, aggiungi altro e ripeti fino a quando la contesa scompare.