Oggi vedremo un caso di utilizzo del Debug Diagnostic Tool che è uno strumento molto utile per fare del debugging e del profiling sia in ambiente di Sviluppo ma sopratutto in ambiente di Produzione.
Il caso in particolare è andare ad analizzare una applicaizone ASP che in produzione, sotto stress quindi, ogni tanto manda il processore del server al 100%.
Come primo workaround si è subito messo in linea uno script di Power Shell che andasse a verificare lo stato del processore e nel caso fosse rimasto al 95% per più di 20sec, andasse a fare un IIS Reset.
Poi subito dopo seguendo questo articolo su Debuggin IIS High CPU siamo andati a impostare:
- Data Collection con il Performance Monitor
In particolar modo:- Richieste Correnti Totali (ASP .NET)
- Richieste in Coda (ASP .NET)
- Creazione di un Dump tramite Debug Diagnostic Tool 2 Collection
In particolare:- Se il processore rimaneva al 90% per più di 5 secondi
E siamo rimasti ad aspettare che nuovamente succedesse lo scenario incriminato.
Abbiamo lasciato in piedi la cosa per tutta la notte: il data collection continua finchè non lo si stoppa, mentre il dump è one-time (una volta scattato, va riattivato manualmente il trigger, altrimenti si ferma).
Nella notte abbiamo avuto ben 4 casi di processore al 100% e durante il primo caso si è generato il Dump e durante tutti i casi abbiamo collezionato i dati dei contatori per le Richieste Correnti e per le richieste in Coda.
Ecco come abbiamo poi analizzato la cosa.
Per quanto riguarda i dati collezionati dal Performance Monitor si è visto che le richieste correnti schizzavano in occorrenza dell’evento incriminato:
Andando ad analizzare anche le richieste in coda:
si evince che aumentano proporzionalmente alle richieste attive.
Questo ci fa sospettare che sia effettivamente un problema di performance e non un problema di “attacco” in quanto le richieste in coda ci sono solamente durante gli eventi incriminati e quindi IIS non riesce ad evadere le richieste perchè è impegnato nell’operazione che porta il processore al 100% e questo scenario è coerente con il fatto che facendo IIS Reset la situazione ritorno normale.
Andiamo quindi ora ad analizzare il dump con il Debug Diagnosti Tool 2 Analysis.
Vediamo subito che l’analisi del Dump conferma High CPU Usage.
Andando a vedere quindi i Topo 8 Thread scopriamo da dove parte il tutto:
Dalla pagina “RivestimentiDettagli” ed è scatenata dal metodo “.get_data()” (Tutto Codice Utente).
Andando quindi ad analizzare il codice si è scoperto che si era fatto un uso improprio di variabili statiche e quindi c’erano problemi di concorrenza che si vedevano solo in presenza di forte carico del server.