Utilisation élevée de la mémoire avec le pool d'applications w3wp IIS 7
J'ai une application de site Web exécutée dans son propre pool d'applications sur IIS 7.0. L'application est un site Web ASP.NET MVC 3.
J'ai remarqué l'utilisation de la mémoire pour ces applications correspondant à w3wp IIS est assez élevé (800 Mo, avec quelques fluctuations).
J'essaie de diagnostiquer le problème et j'ai essayé ce qui suit:
J'ai désactivé la mise en cache des pages de sortie pour le site Web au niveau IIS puis j'ai recyclé le pool d'applications. Cela provoque le redémarrage du processus w3wp. L'utilisation de la mémoire pour ce processus grimpe lentement jusqu'à environ 800 Mo , cela prend environ 30 secondes. Aucune demande de page n'est traitée pour le moment. Lorsque je redémarre le site Web à partir de IIS, la taille de la mémoire du processus ne change pas.
J'ai essayé d'exécuter une copie de débogage de l'application à partir de VS 2010, il n'y a aucun problème avec l'utilisation de la mémoire.
Certaines idées que j'ai/questions sont:
Ce problème est-il lié au code des sites Web? - Étant donné que la mémoire monte en flèche avant toute demande de page envoyée/traitée, je suppose que ce n'est PAS un problème de code?
L'application intégrée à MVC n'a aucun traitement de mise en cache écrit dedans.
Le site Web utilise l'affichage en temps réel des données, il utilise périodiquement les demandes ajax et est généralement laissé "ouvert" pendant de longues périodes.
Pourquoi l'utilisation de la mémoire augmente-t-elle une fois l'application recyclée et aucune demande utilisateur envoyée? Est-ce parce qu'il charge les anciennes informations de cache dans sa mémoire à partir du disque?
L'application ne plante PAS, je suis juste préoccupé par l'utilisation de la mémoire, ce n'est pas si grand qu'un site Web ...
Toute idée/aide pour aller au fond de ce problème serait appréciée.
Je regarde juste mon serveur et mes pools utilisent une mémoire de taille virtuelle de 900 à 1000 Mo et un ensemble de travail de 380 Mo. Mes sites fonctionnent sans problème depuis quelques années maintenant, et je les ai vérifiés de tous les côtés. Mon pool ne recycle jamais et le serveur fonctionne jusqu'à la prochaine mise à jour en continu avec 40% de mémoire physique libre stable.
Si votre mémoire ne continue pas de croître, alors cette mémoire est le code plus les données que vous définissez comme statique, const, la chaîne et le cache possible, à l'intérieur de votre application.
Vous pouvez utiliser processus Explorer pour voir la mémoire de taille de travail et virtuelle.
Vous pouvez également penser à exécuter un profil par rapport à votre code pour voir si vous avez une "fuite de mémoire" ou un autre problème. Trouvez-en un sur google: https://www.google.com/search?hl=en&q=asp.net+memory+profiler .
La meilleure chose à faire si vous pouvez vous permettre d'utiliser un débogueur est d'installer le Windows Debugging Tools et d'utiliser quelque chose comme WinDbg et SOS.dll pour comprendre exactement ce que c'est en mémoire.
une fois que vous avez installé les outils, vous pouvez:
- Lancez Windbg.exe en cours d'exécution élevé (en tant qu'administrateur)
- Utilisez "Fichier-> Attacher au processus" et choisissez w3wp.exe pour l'application que vous essayez de comprendre. Si vous en avez plusieurs, vous pouvez utiliser le Gestionnaire des tâches et ajouter la colonne de ligne de commande pour voir le PID ou utiliser IIS Manager-> Processus de travail pour le comprendre, puis choisissez ce processus dans WinDBG.
- courir:
- .loadby sos clr
- ! dumpheap -stat
À ce stade, vous devriez être en mesure de voir tous les types triés par la plus grande consommation de mémoire afin de pouvoir commencer par ceux du bas. (Je recommanderais d'exclure les chaînes et les objets car ce sont généralement des effets secondaires et non la cause). Utilisez "! Dumpheap -type type-here" pour trouver les instances et utilisez! Gcroot pour que celles-ci découvrent pourquoi elles sont en mémoire, peut-être en raison d'un champ statique ou d'une fuite d'un gestionnaire d'événements, de canaux WCF non supprimés ou de choses comme qui sont des sources courantes.
Cela ne s'applique probablement pas ici, mais j'ai pensé que je le jetterais pour faire bonne mesure. Récemment, j'ai eu un problème où ma mémoire montait et s'épuisait quand elle pouvait vraiment en nettoyer 80%. Problème: il pensait qu'il fallait environ 2 gig de plus qu'il ne le faisait réellement, donc le GC était assez paresseux. (C'était dû à un VM bug bug -windows rapportait 8 Gig mais physiquement il n'y en avait que 6,4). Voir blog . http://www.worthalook.net/2014/01/redonner-mémoire /
Quelque chose qui pourrait aider: si vous "réécrivez" (ouvrez/enregistrez) le web.config, alors votre application sera réinitialisée, vous devriez surveiller l'utilisation de la mémoire à partir de ce moment. S'il continue de croître pendant l'utilisation, cela pourrait signifier une fuite de mémoire ou une mise en cache folle. Vous pourrez peut-être identifier les actions sur votre site qui entraînent une augmentation de la mémoire. Pendant longtemps, l'utilisation de la mémoire d'une application doit être stable.