Comment détecter une fuite de mémoire?

Question

J'ai un grand site Web qui semble aspirer toute la mémoire qui est allouée. Il n'y a rien d'autre sur le serveur à côté de ce site. Dans une semaine, il ronge les 2 concerts et nécessite un redémarrage. Actuellement, il s'agit du serveur 2008 32 bits utilisant IIS 7. Nous réinstallons pour utiliser 64 bits et ajouter plus de mémoire. Ce serait bien de pouvoir localiser les fuites.

Alors, quelle est la meilleure pratique pour suivre les fuites de mémoire?

Answer 1

Exécutez un profileur sur votre code.

Voici deux bonnes options:

RedGate's memory profiler

Jetbrains dotTrace

Je crois que les deux produits ont un essai gratuit.

Answer 2

Vous pouvez essayer d'utiliser des profileurs tels que dotTrace - le définir dans une trace mémoire et exécuter votre application.

Cela devrait vous donner des indices sur les assemblages et les zones de l'application qui consomment trop de mémoire au démarrage.

Answer 3

Il s'agit probablement d'une prévention plutôt que d'une détection, mais au niveau du code C#, vous devez vérifier que toutes les classes utilisant de grandes ressources telles que des images et d'autres fichiers implémentent correctement the dispose pattern. Si nécessaire, vous devrez peut-être remplacer le finaliseur.

MSDN a de bonnes indications à ce sujet.

Si vous connaissez des classes de votre application qui utilisent des ressources volumineuses, ce sont les premières sources de problèmes de mémoire.

Answer 4

Faites-vous Office interop? Si c'est le cas, assurez-vous de nettoyer les objets de votre application. C'est un coupable possible.

Un autre est des objets globaux, tels que tout ce qui est statique.

Answer 5

Dans le moniteur de performances, ajoutez des compteurs pour Process/Private Bytes et .NET CLR Memory/# Octets dans tous les tas. Les octets privés sont tous de la mémoire et la mémoire CLR est juste gérée. Ainsi, si la mémoire CLR reste relativement stable mais que les octets privés continuent de croître avec le temps, cela signifie que la fuite est dans une ressource non gérée. Cela signifie généralement que vous ne disposez pas de ressources natives correctement. Une bonne chose à regarder est des choses comme COM ou IO (flux et fichiers). Assurez-vous que tous ces trucs soient éliminés quand vous en avez fini.

Answer 6

Avez-vous beaucoup de pages dynamiques sur votre site?

Vous pouvez également essayer IBM's Purify

Je vous suggère d'essayer avec un petit ensemble de pages dynamiques invalidantes tous les autres pour l'intervalle. Je déteste dire cela, mais il est très possible que IIS 7 ait aussi des fuites.

Answer 7

J'ai trouvé que le EQATEC Profiler est plutôt bon, et c'est gratuit!

Answer 8

Vérifiez les laboratoires fuite de mémoire et de la mémoire sur ce blog:

.NET Debugging Demos

Ils peuvent être d'une certaine aide. Fondamentalement, vous pouvez utiliser WinDBG pour analyser un vidage de la mémoire et aider à déterminer ce qui ronge toute votre mémoire.

Nous avons utilisé une approche similaire pour déterminer que Regex mastiquait toute notre mémoire, mais uniquement lorsque le produit était exécuté sur des machines 64 bits. La courbe d'apprentissage est plutôt abrupte, mais WinDBG est un outil très puissant.

Answer 9

Les fuites de mémoire dans .NET ne sont pas si courantes, mais lorsqu'elles surviennent, elles sont le plus souvent dues à des gestionnaires d'événements non attachés. Assurez-vous de détacher les gestionnaires, avant que les auditeurs ne soient hors de portée.

Une autre option est si vous oubliez d'appeler Dispose() sur IDisposable ressources. Cela peut empêcher le nettoyage des ressources non gérées (qui ne sont pas gérées par GC).

Et encore une autre raison possible est un finaliseur en interblocage. Cela empêchera la collecte de tous les objets restants dans la file d'attente du finaliseur. J'utilise WinDbg + Sos pour localiser les fuites. Les étapes sont les suivantes

• vider le tas et regarder des suspects
• Utilisez !gcroot pour savoir ce qui maintient les suspects vivants
• Répéter au besoin

Sachez que grande utilisation de la mémoire peut aussi être due à la fragmentation du tas. Les tas réguliers sont compactés, mais les objets épinglés peuvent provoquer une fragmentation. En outre, le LOH n'est pas compacté, donc la fragmentation n'est pas rare pour LOH.

excellents tutoriels sur WinDbg + sos ici: http://blogs.msdn.com/tess/

Answer 10

Run, ne marchent pas, plus de Tess le blog de Ferrandez, If broken it is, fix it you should, qui a bien laboratoires scriptées dédiés à l'apprentissage comment diagnostiquer et debug crash, se bloquer et des problèmes de mémoire avec le code. Elle a quelques-uns des meilleurs documents que j'ai trouvé à ce jour pour vous aider à démarrer.

profileurs de mémoire commerciaux tels que ANTS et SciTech sont d'excellentes ressources qui montrera quels objets sont dans le tas, et la façon dont ils sont enracinés. La plupart des profileurs de mémoire commerciaux ont la capacité de charger un «instantané» de la mémoire d'un processus (par exemple à partir de votre environnement de production).

Vous pouvez capturer un «snap» de mémoire (voir Snap v. Dump) en utilisant adplus.vbs ou DebugDiag. Adplus est disponible dans le cadre du Debugging Tools for Windows. DebugDiag aura aussi une analyse rudimentaire (mais semble plus fiable sur le code non managé) automagiquement.

Surveiller l'application
Pour avoir une idée sur ce qu'il faut surveiller, voir Improving .NET Performance and Scalability, plus précisément le chapitre 15.

Quant à la façon de surveiller, il existe des outils commerciaux disponibles pour cela aussi, cependant, tous les de Windows La machine est également fournie avec Perfmon.exe, qui peut être utilisé pour enregistrer les compteurs de performance pertinents.

Test de l'application
Pour avoir une idée sur la façon d'effectuer la charge ou le stress, les tests, consultez les modèles et pratiques Performance Testing Guidance for Web Applications.

débogage de l'application
Une fois que vous avez identifié vous avez un problème (suivi) et votre pouvoir reproduire le problème (test), vous pouvez obtenir jusqu'à débogage du problème. Voir les liens pour Tess - cette information vous portera un long chemin.

Puis rincez et répétez! :)

Bonne chance!
Z

Answer 11

Regardez this article on detecting .NET application memory leaks et articles connexes mentionnés au bas de la page et nous espérons que vous trouverez une solution ou au moins une idée de le résoudre.

Merci

Answer 12

Ce nouvel article de la mine peut-être utile: How to detect and avoid memory and resources leaks in .NET applications