C'è molto da fare qui, e la maggior parte è piuttosto ampia e vaga.
2008R2 RTM è uscito il 21 aprile 2010. È totalmente fuori supporto. Ti consigliamo di dare la priorità all'acquisto dell'ultimo Service Pack, uscito circa 3 anni fa. In questo modo sarai coperto se colpisci un bug strano o qualcosa del genere. Vai qui per capire cosa devi scaricare.
Poiché hai aggiunto vCPU (da 1 a 4) e non hai modificato alcuna impostazione, le tue query possono ora andare in parallelo. So che sembra che saranno tutti più veloci, ma aspetta!
Potresti aver aggiunto RAM, ma potresti non aver modificato Max Server Memory in modo che il tuo server possa trarne vantaggio.
Scopri cosa sta aspettando il tuo server. Un progetto open source su cui lavoro fornisce script gratuiti per aiutarti a misurare il tuo SQL Server. Vai qui se vuoi provarli.
Ti consigliamo di prendere sp_BlitzFirst per controllare le statistiche di attesa del tuo server. Puoi eseguirlo in un paio di modi.
Questo ti mostrerà ciò che il tuo server ha atteso da quando è stato avviato.
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
Questo ti mostrerà quali query sono in attesa ora, durante una finestra di 30 secondi.
EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;
Una volta che hai capito quali domande ti stanno aspettando (ci sono un sacco di cose scritte sulle statistiche di attesa là fuori), puoi iniziare a fare cambiamenti per tenere tutto sotto controllo.
Se li vedi in attesa CXPACKET
, ciò significa che le tue query stanno andando in parallelo e forse calpestando l'una sull'altra. Se colpisci questo, probabilmente vorrai considerare di aumentare la Soglia di costo per il parallelismo fino a 50 e forse di far scendere MAXDOP fino a 2.
Dopo questo passaggio è quando si desidera utilizzare qualcosa come sp_WhoIsActive o sp_BlitzWho (quest'ultimo si trova nel repository GitHub da prima) per avviare l'acquisizione dei piani di query. A parte le statistiche sull'attesa, sono una delle cose più importanti che puoi guardare per capire cosa non va.
Puoi anche consultare questo articolo di Jonathan Kehayias sui contatori VMWare da verificare in relazione a SQL Server.
Aggiornare
Revisionare le statistiche di attesa e ragazzo sono strani. C'è sicuramente qualcosa che non va nelle CPU. Il tuo server è per lo più annoiato, ma quando le cose si surriscaldano, le cose peggiorano. Proverò a scomporlo facilmente.
Stai colpendo un'attesa di veleno chiamata THREADPOOL
. Non ne hai molto, ma ha senso perché il tuo server non è terribilmente attivo. Spiegherò perché tra un minuto.
Hai attese medie molto lunghe su SOS_SCHEDULER_YIELD
e CXPACKET
. Sei su una macchina virtuale, quindi assicurati che SQL Server abbia delle prenotazioni o che la casella non sia eccessivamente sottoscritta. Un vicino rumoroso può davvero rovinare la tua giornata qui. Inoltre, vorrai assicurarti che il server / guest VM / host VM non siano in esecuzione in modalità di alimentazione bilanciata. Questo fa girare le CPU a velocità inutilmente basse e non tornano immediatamente alla massima velocità.
Come si legano? Con 4 CPU hai 512 thread di lavoro. Tieni presente che hai avuto lo stesso importo con una singola CPU, ma ora che le tue query possono andare in parallelo, possono consumare molti più thread di lavoro. Nel tuo caso 4 thread per ramo parallelo di una query parallela.
Cosa sta andando parallelo? Molto probabilmente tutto. La soglia di costo predefinita per il parallelismo è 5. Quel numero è stato impostato come predefinito alla fine degli anni '90 lavorando su un desktop che assomigliava a questo .
Certo, il tuo hardware è più piccolo della maggior parte dei laptop, ma sei ancora un po 'avanti rispetto a quello.
Quando vengono avviate molte query parallele, si stanno esaurendo i thread di lavoro. Quando ciò accade, le query rimangono semplicemente in attesa che i thread inizino. È anche qui che SOS_SCHEDULER_YIELD
entra in gioco. Le query stanno interrompendo le CPU e non si riaccendono per molto tempo. Non vedo alcuna attesa di blocco, quindi è molto probabile che tu sia solo pieno di attese di parallelismo intra-query.
Cosa sai fare?
- Assicurarsi che nulla sia in modalità di alimentazione bilanciata
- Cambia MAXDOP in 2
- Modifica la soglia di costo per il parallelismo su 50
- Segui l'articolo di Jon K. sopra per convalidare l'integrità della VM
- Utilizzare lo script chiamato
sp_BlitzIndex
per cercare eventuali richieste di indice mancanti.
Per una risoluzione dei problemi più approfondita, consulta il white paper che ho scritto per Google sul dimensionamento dell'hardware nel cloud.
Spero che sia di aiuto!