Quelles demandes entraînent une croissance considérable du processus w3wp?

Question

Dans un environnement de production, comment savoir quelles requêtes HTTP Asp.Net, qu’elles soient aspx ou asmx ou personnalisées, entraînent le plus de pression mémoire au sein d’un processus w3wp.exe? Je ne parle pas de fuites de mémoire ici. C'est une bonne application saine qui élimine tous les objets. Le GC générationnel de Microsoft fonctionne bien. Certaines requêtes entraînent toutefois une augmentation considérable de l’empreinte mémoire du processus w3wp, mais uniquement pendant la durée de la requête.

Il s’agit simplement de la rentabilité et de l’évolutivité d’un environnement de production pour une application SAAS, afin de rendre compte régulièrement au service du développement de ses "pages" les plus mémorables en mémoire, afin de renvoyer cette pression (de la mémoire) là où elle se trouve. appartient, pour ainsi dire.

Il ne semble y avoir rien de tel que:
HttpContext.Request.PeakPrivateBytes ou .CurrentPrivateBytes

ou
Session.PeakPrivateBytes

Answer 1

Vous pouvez utiliser un outil tel que Analyseur de performances pour surveiller le "Processus \ Ensemble de travail". pour le processus W3WP.exe et enregistrez-le dans une base de données. Vous pourriez alors le corréler aux journaux HTTP du serveur IIS.

Il est utile d’écrire dans une base de données SQL les journaux de données Perfmon et HTTP. Ensuite, vous pouvez utiliser T-SQL pour afficher les pages demandées par date / heure autour de l'heure de la pression de mémoire observée. Utilisez la fonction DatePart pour créer une date / heure arrondie à la précision souhaitée en secondes ou en minutes, selon vos besoins.

J'espère que cela vous aidera.

Merci, -Glenn

Answer 2

Si vous utilisez l'état de session InProc , toutes vos données de session sont stockées dans la mémoire de w3wp et peuvent être à l'origine de sa croissance.

Answer 3

Je ne m'inquiéterais pas pour ça. Il se peut que le GC se produise pendant la demande et que le CLR alloue de la mémoire pour déplacer des éléments. Ou cela pourrait être une autre opération de maintenance périodique fournie avec ASPNET.

À moins que vous ne soyez prêt à faire de la spéléologie avec une analyse à la volée des événements de la génération 0,1, 2 GC, etc., je ne m'inquiéterais pas de la résolution de ce "problème".

Et il ne semble pas que ce soit un problème, mais une simple curiosité.