W3wp.exe utilizzando il 100% della CPU - da dove cominciare?
-
20-09-2019 - |
Domanda
Una web app ASP.NET in esecuzione su IIS6 spara periodicamente la CPU fino al 100%. E 'il W3WP che è responsabile di quasi tutti l'utilizzo della CPU durante questi episodi. La CPU rimane inchiodato al 100% da pochi minuti a più di un'ora.
Questo è su un server di gestione temporanea e il sito sta ottenendo solo il traffico molto leggero da tester a questo punto.
Abbiamo in esecuzione ANTS Profiler sul server, ma è stata unenlightening.
dove si può iniziare a trovare che cosa sta causando questi episodi e ciò che il codice è mantenere la CPU occupato durante tutto quel tempo?
Soluzione
- contatori delle prestazioni di Windows standard (cercare altra attività correlata, come molte richieste GET, di rete eccessivo o disco I / O, ecc); li si può leggere dal codice così come da Perfmon (per attivare la raccolta dei dati se l'utilizzo della CPU supera una soglia, per esempio)
- contatori delle prestazioni su misura (in particolare in volta per le richieste di off-box e altre chiamate in cui il tempo di esecuzione è incerta)
- test di carico, utilizzando strumenti come Visual Studio Team Test o WCAT
- Se è possibile testare o aggiornare a IIS 7, è possibile configurare traccia richieste non riuscite a generare una traccia, se le richieste di prendere più di un certo periodo di tempo
- Usa LogParser per vedere che le richieste è arrivato al momento del picco di CPU
- Le revisioni del codice / walk-through (in particolare, cercano i loop che non può terminare correttamente, ad esempio, se si verifica un errore, così come le serrature e potenziali problemi di threading, come l'uso della statica)
- CPU e memoria profiling (può essere difficile in un sistema di produzione)
- Process Explorer
- Monitoraggio risorse di Windows
- errore dettagliata di registrazione
- Registrazione personalizzata traccia, compresi i dettagli del tempo di esecuzione (forse condizionali, basata sulla CPU-uso perf contatore)
- sono gli errori che accadono quando l'AppPool ricicla? Se è così, potrebbe essere un indizio.
Altri suggerimenti
Non è molto di una risposta, ma potrebbe essere necessario andare vecchia scuola e catturare un'istantanea immagine del processo IIS ed eseguire il debug. Si potrebbe anche voler controllare Tess Ferrandez 's blog - lei è un calcio di un ** ingegnere escalation Microsoft e il suo blog si concentra sul debug di ASP.NET finestre, ma il blog è rilevante per le finestre di debug in generale. Se si seleziona il tag ASP.NET (che è quello che ho collegato a) poi vedrete diversi elementi che sono simili.
Se la CPU è chiodare al 100% e rimanere lì, è molto probabile che hai uno scenario di stallo o di un ciclo infinito. Un profiler sembra una buona scelta per la ricerca di un ciclo infinito. Deadlock sono molto più difficili da rintracciare, tuttavia.
Process Explorer è un ottimo strumento per la risoluzione dei problemi. Si può provare per trovare il problema di alta utilizzo della CPU . Ti dà un'idea del modo in cui funziona l'applicazione.
Si può anche provare ProcDump per scaricare il processo e analizzare ciò che è realmente accaduto sulla CPU.
Inoltre, guardare i vostri contatori Perfmon. Si può dire dove è stato speso un sacco di quel tempo di CPU. Ecco un link per i contatori più comuni da utilizzare:
Abbiamo avuto questo su una query ricorsive che stava facendo uscire le tonnellate di dati all'uscita -? Hai ricontrollato tutto fa uscire e non esistono cicli infiniti
potrebbe cercare di restringere il campo con una sola pagina - abbiamo trovato formiche per non essere di grande aiuto in questo stesso caso sia - quello che abbiamo finito per fare stava correndo il sito ha colpito una pagina di visualizzazione CPU - ha colpito la pagina successiva orologio CPU - molto metodico e che richiede tempo, ma se non potete trovare con un po 'di codice tracing si potrebbe essere fuori di fortuna -
Siamo stati in grado di utilizzare i file di log di IIS per monitorare ad una serie di pagine che erano sospetti -
Speranza che aiuta!
Questa è una supposizione nella migliore delle ipotesi, ma forse il team di sviluppo è la costruzione e la distribuzione l'applicazione in modalità di debug, al posto di modalità di rilascio. Questo farà sì che la presenza di file PDB. L'implicazione di questo è che l'applicazione avrà le risorse aggiuntive per la raccolta dello stato del sistema e le informazioni di debug durante l'esecuzione del sistema, causando più l'utilizzo del processore.
Quindi, sarebbe abbastanza semplice per garantire che essi stanno costruendo e la distribuzione in modalità di rilascio.
Questo è un post molto vecchio, lo so, ma questo è anche un problema comune. Tutti i metodi suggeriti sono molto bello, ma che sarà sempre puntare a un processo, e ci sono molte probabilità che già conosciamo che il nostro sito sta facendo problemi, ma vogliamo solo sapere cosa pagina specifica sta spendendo troppo tempo in lavorazione. Lo strumento più preciso e semplice a mio parere è IIS sé.
- Basta cliccare sul server nel riquadro sinistro di IIS.
- Fare clic su 'processi di lavoro' nel riquadro principale. già vedere cosa pool di applicazioni sta prendendo troppa CPU.
- Fare doppio clic su questa linea (eventualmente aggiornare facendo clic su 'Mostra tutto') per vedere quali pagine consumano tempo di CPU troppo ( 'Tempo trascorso' colonna) in questa piscina
Se si identifica una pagina che richiede tempo per caricare, utilizzare SharePoint di Developer Dashboard per vedere quale componente richiede tempo.