Causes de fuite de mémoire de service Web

Question

Nous avons un service Web qui utilise de plus en plus d'octets privés jusqu'à ce que l'application cesse de répondre. Le tas géré (principalement Gen2) affichera entre 200 et 250 Mo, tandis que les octets privés afficheront plus de 1 Go. Quelles sont les causes possibles d'une fuite de mémoire en dehors du tas géré?

Je l'ai déjà vérifié les points suivants:

1. ensembles dynamiques (Prolific de sérialisation Xml, regex, etc.)
2. état de session (DESACTIVEE)
3. System.Policy.Evidence fuite de mémoire (SP1 installé)
4. impasse Threading (pas d'utilisation de Join, verrouiller uniquement)
5. utilisation de SQLOLEDB (en utilisant SqlClient)

De quelles autres sources puis-je vérifier?

Answer 1

Assurez-vous que votre application est conforme en mode édition. Si vous compilez en mode débogage et que vous le déployez, il suffit d'instancier une classe dont un événement est défini (l'événement n'a même pas besoin d'être déclenché) provoquera la fuite d'une petite partie de la mémoire. Instancier assez de ces objets sur une période assez longue entraînera l'utilisation de toute la mémoire. J'ai vu des applications web qui utiliseraient toute la mémoire en quelques heures, simplement parce qu'une version de débogage a été utilisée. La compilation en tant que version de build a immédiatement et définitivement résolu le problème.

Answer 2

Regardez aussi pour:

• assemblées COM étant chargé
• DB Connections n'a pas été fermée
• Cache & Etat (session, demande)

Essayez de forcer le Garbage Collector (GC) pour exécuter (écrire une page qui le fait quand il charge) ou essayer l'instrumentation, mais c'est un peu hasardeux dans mon expérience. Une autre chose serait de le garder en marche et de voir s'il manque de mémoire.

Ce qui pourrait arriver est qu'il y a beaucoup de mémoire et Windows ne signale pas votre application pour nettoyer. Cela fait que l'application a l'air d'utiliser de plus en plus de mémoire parce qu'elle le peut, alors qu'en fait, le système peut récupérer la mémoire quand elle en a besoin. SQL Server et Exchange le font beaucoup. L'idée est pourquoi provoquer un nettoyage inutile quand il y a beaucoup de ressources.

Rob

Answer 3

Je vous recommande de voir des clichés de la pile à plusieurs reprises, et voir ce qui se sert de la mémoire. Si votre application utilise Java, alors jmap fonctionne très bien - vous lui donnez simplement le PID du processus Java.

Si vous utilisez autre chose, essayez Lambda Probe (http://www.lambdaprobe.org/d/index.htm). Il ne montre pas autant de détails, mais vous montrera au moins l'utilisation de la mémoire. J'ai eu une mauvaise fuite de mémoire dans mon code JDBC qui a fini par être lié à un changement dans la spécification JDBC il y a quelques années que j'ai manqué (en ce qui concerne les déclarations de clôture et autres). Il a fallu une combinaison de Lamdba Probe puis de jmap pour localiser suffisamment le problème pour le réparer.

Cheers,

R

Answer 4

collecte des ordures ne fonctionne pas jusqu'à ce qu'une demande de mémoire est refusé en raison d'un manque de mémoire disponible. Cela peut souvent faire ressembler les choses à une fuite de mémoire quand on n'est pas là.

Avez-vous des événements et des gestionnaires d'événements dans le service? Les services ont souvent des variables statiques, et si vous créez des gestionnaires d'événements à partir des instances statiques, connectés à un objet d'instance non statique, le statique contiendra une référence à l'instance pour toujours, ce qui l'empêchera de se libérer.

Answer 5

Vérifiez que la trace n'est pas activée. J'ai vu des instances de trace consommer lentement de la mémoire jusqu'à ce que l'application atteigne la limite de son pool d'applications.