Il problema di una situazione del genere è che quando capita non si sa chi sia davvero il colpevole e spesso si arranca nel cercare all’interno del codice quell’ultimo commit che può aver determinato questo effetto in produzione.
Difficile a dirsi, molto spesso è una concausa di eventi e non sempre è dovuta a quanto abbiamo appena rilasciato. Proviamo a fare una lista minimale delle svariate origini scatenanti di questa condizione:
- un frammento di codice che fino a quel momento non è mai stato invocato in ambiente di produzione
- statistiche di una tabella non correttamente aggiornate, questo in genere porta a piani di esecuzione decisamente sfavorevoli
- scarsa manutenzione del database
- altro…?
Come detto prima, quando succede, inutile cercare il capro espiatorio senza alcun dato da analizzare, tanto vale affidarsi ad un qualcosa di certo che può davvero darci una mano a diagnosticare il problema.
La maniera più rapida e precisa per recuperare una lista di cosa viene eseguito in un dato momento sul nostro server è la sp_WhoIsActive; molto più dettagliata della classica sp_who/sp_who2 ci fornisce un dettaglio aggiuntivo dei consumi delle risorse dei processi attivi e tante altre informazioni a corredo.
In questi momenti installare una nuova procedura su un server particolarmente impegnato a fare altro potrebbe non essere la scelta ottimale, per questo immagino che in questo caso prevenire rendendo disponibile e pronta all’uso la procedura sia la migliore delle scelte.
Proviamo ora ad eseguire quest’istruzione:
exec sp_WhoIsActive
@sort_order='[CPU] desc',
@get_plans=1
Otteniamo una tabella risultante come quella raffigurata sopra (Figura 1).
L’istruzione ci permette di ordinare gli statements in esecuzione per tempo di CPU così da trovare in cima alla lista tutte quelle elaborazioni che stanno tenendo impegnata la nostra macchina.
Il parametro @get_plans invece chiede alla procedura di recuperare l’attuale piano di esecuzione utilizzato dall’engine se disponibile.
Il piano di esecuzione ci sarà utile per successive indagini.
Voi invece come diagnosticate picchi di utilizzo CPU anomali? Avete una procedura o un vademecum specifico da seguire in queste situazioni?