Quali richieste causano una crescita considerevole di un processo w3wp?

Question

In un ambiente di produzione, come si può scoprire quali richieste HTTP Asp.Net, aspx o asmx o personalizzate, stanno causando la maggiore pressione di memoria all'interno di un processo w3wp.exe? Non intendo perdite di memoria qui. È una buona applicazione salutare che dispone bene tutti gli oggetti. Il GC generazionale di Microsoft funziona bene. Alcune richieste, tuttavia, fanno sì che il processo di w3wp cresca considerevolmente il suo footprint di memoria, ma solo per la durata della richiesta.

È semplicemente una questione di efficienza in termini di costi e scalabilità di un ambiente di produzione per un'app SAAS, al fine di riferire regolarmente al dipartimento di sviluppo sulla maggior parte delle pagine di "memoria", per riportare quella pressione (di memoria) dove appartiene, per così dire.

Non sembra esserci niente del genere:
HttpContext.Request.PeakPrivateBytes o .CurrentPrivateBytes
o
Session.PeakPrivateBytes

Answer 1

Potresti voler utilizzare uno strumento come Performance Monitor per monitorare " Process \ Working Set " per il processo W3WP.exe e registrarlo in un database. È quindi possibile correlarlo ai registri HTTP per il server IIS.

Aiuta ad avere sia i dati Perfmon che i log HTTP che scrivono su un database SQL. Quindi è possibile utilizzare T-SQL per visualizzare le pagine richieste in base alla data / ora in base al tempo della pressione della memoria osservata. Utilizzare la funzione DatePart per creare una data / ora arrotondata alla precisione desiderata di Second o Minute in base alle esigenze.

Spero che questo aiuti.

Grazie, -Glenn

Answer 2

Se si utilizza lo stato della sessione InProc , tutti i dati della sessione vengono archiviati nella memoria di w3wp e potrebbe essere la causa della loro crescita.

Answer 3

Non me ne preoccuperei. È possibile che il GC si stia verificando durante la richiesta e che CLR stia allocando memoria per spostare le cose. O potrebbe essere qualche altra cosa di manutenzione periodica che accompagna ASPNET.

A meno che tu non sia disposto a dedicarti allo spelunking con l'analisi del contatore perf di eventi GC 0,1,2 di generazione, ecc., non mi preoccuperei di risolvere questo "problema".

E non sembra comunque che sia un problema - solo una cosa di curiosità.