Énorme salve de mémoire dans le service C#, quelle pourrait en être la cause?

Question

Je travaille sur une application de service C# et j'ai ce problème où hors de nulle part et pour aucune raison évidente, la mémoire pour le processus grimpera de 150mb à presque 2gb en environ 5 secondes, puis de retour à 150mb. Mais rien dans notre système ne devrait utiliser n'importe où près de cette quantité de mémoire (donc c'est probablement un bug quelque part). Il pourrait être une boucle serrée quelque part mais l'utilisation du processeur à l'époque était très faible, donc je pensais que je chercherais d'autres idées. Maintenant, le plus étrange est quand je compile le service pour 64 bits, la même rafale massive se produira, sauf qu'il a dépassé 10 Go de ram (paginer la plupart) et il a causé beaucoup de problèmes avec l'ordinateur et tout ce qui fonctionne . Après un certain temps, il se ferme, mais il semble que Windows est toujours prêt à lui donner plus de mémoire.

Auriez-vous des idées ou des outils que je peux utiliser pour trouver ceci? Oui, il y a beaucoup de journalisation, mais rien dans les journaux ne se distingue pour ce qui est en train de se produire.

Je peux exécuter le service en mode console, mon prochain test devait donc être exécuté dans le débogueur Visual Studio et voir si je peux trouver quelque chose.

Cela n'arrive que de temps en temps, mais généralement environ 10-20 minutes après le démarrage. En mode 32 bits, il nettoie et continue normalement. Mode 64 bits il se bloque après un certain temps et utilise des quantités stupides de mémoire. Mais je suis vraiment perplexe quant à la raison pour laquelle cela arrive !!!

EDIT: S'il vous plaît voir les Félicite au windbg poster

Answer 1

Vous faites beaucoup d'allocation qui vous relâchez. Votre mémoire s'accumule, jusqu'à ce que le GC entre et commence à nettoyer après vous. Sur les plateformes amd64, toutes les structures sont plus grandes puisque les pointeurs, les tables v et les autres structures ont intrinsèquement une taille double par rapport à x86.

La solution la plus simple est de lancer l'application sous le débogueur et d'attendre le renflement, puis de le congeler et de faire un vidage. Puis analysez la sauvegarde:

.loadby sos mscorwks 
!dumpheap -stat 

Votre type de fuite sera en haut de la liste, avec beaucoup d'allocations. C'est la même technique que vous utiliseriez pour analyser une fuite de mémoire, sauf que la mémoire n'est probablement pas divulguée, voir CLR Memory Leak.

Answer 2

Vous pouvez essayer un profileur, comme le CLRProfiler, a free download from MS (c'est plutôt cool). Il peut profiler les services. Lancez-le jusqu'à ce que vous voyiez le pic de mémoire, puis arrêtez-le et regardez le tas de mémoire.

Answer 3

Vous semblez faire une concaténation de chaînes au lieu d'utiliser StringBuilder?