J'essaie de suivre pourquoi certains objets de mon application sont épinglés. Les objets que j'ai regardés jusqu'à présent sont des matrices d'objet! GCCroot montrent le tableau comme étant épinglé mais je ne sais pas comment comprendre pourquoi il est épinglé.
sortie: p> edit: Ajouté! Sortie EHEAAP -GC P> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x49a6f940
generation 1 starts at 0x49a0c8a8
generation 2 starts at 0x01301000
ephemeral segment allocation context: none
segment begin allocated size
01300000 01301000 022f05a0 0x00fef5a0(16709024)
0d0d0000 0d0d1000 0e0bb0cc 0x00fea0cc(16687308)
0e9e0000 0e9e1000 0f9de3e8 0x00ffd3e8(16765928)
11020000 11021000 12014808 0x00ff3808(16726024)
15020000 15021000 15ff3958 0x00fd2958(16591192)
139f0000 139f1000 1499f584 0x00fae584(16442756)
16020000 16021000 16fd7c30 0x00fb6c30(16477232)
19020000 19021000 1a013df4 0x00ff2df4(16723444)
17020000 17021000 17fcfe8c 0x00faee8c(16445068)
18020000 18021000 18fedb84 0x00fccb84(16567172)
1a020000 1a021000 1afc8814 0x00fa7814(16414740)
26010000 26011000 26f97d2c 0x00f86d2c(16280876)
2d010000 2d011000 2df97210 0x00f86210(16278032)
20010000 20011000 210028e0 0x00ff18e0(16718048)
21010000 21011000 220085d8 0x00ff75d8(16741848)
23810000 23811000 247acf60 0x00f9bf60(16367456)
28010000 28011000 28f84f80 0x00f73f80(16203648)
1c010000 1c011000 1cfba544 0x00fa9544(16422212)
1d010000 1d011000 1dfdcf64 0x00fcbf64(16564068)
32010000 32011000 32f9189c 0x00f8089c(16255132)
1e010000 1e011000 1eff9824 0x00fe8824(16680996)
2c010000 2c011000 2cfd4904 0x00fc3904(16529668)
300a0000 300a1000 3104a488 0x00fa9488(16422024)
24810000 24811000 2571bd20 0x00f0ad20(15772960)
36d10000 36d11000 37c982d4 0x00f872d4(16282324)
29010000 29011000 29fc96a0 0x00fb86a0(16484000)
27010000 27011000 27ee38bc 0x00ed28bc(15542460)
2a010000 2a011000 2afab094 0x00f9a094(16359572)
441c0000 441c1000 45149df0 0x00f88df0(16289264)
38d10000 38d11000 39ce4254 0x00fd3254(16593492)
3bd10000 3bd11000 3cc7a750 0x00f69750(16160592)
3ad10000 3ad11000 3bc8b878 0x00f7a878(16230520)
411c0000 411c1000 421655a0 0x00fa45a0(16401824)
2b010000 2b011000 2bfafae4 0x00f9eae4(16378596)
461c0000 461c1000 471a1bb0 0x00fe0bb0(16649136)
3e1c0000 3e1c1000 3f11151c 0x00f5051c(16057628)
34010000 34011000 35003ae4 0x00ff2ae4(16722660)
451c0000 451c1000 4609e680 0x00edd680(15586944)
4c1c0000 4c1c1000 4d105324 0x00f44324(16007972)
2f0a0000 2f0a1000 3007989c 0x00fd889c(16615580)
50e10000 50e11000 51cf17d8 0x00ee07d8(15599576)
33010000 33011000 34005d88 0x00ff4d88(16731528)
37d10000 37d11000 38cc6d7c 0x00fb5d7c(16473468)
481c0000 481c1000 4898a468 0x007c9468(8164456)
39d10000 39d11000 3acbe2d8 0x00fad2d8(16437976)
3f1c0000 3f1c1000 3fd1f378 0x00b5e378(11920248)
51e10000 51e11000 52e01018 0x00ff0018(16711704)
431c0000 431c1000 441805d8 0x00fbf5d8(16512472)
401c0000 401c1000 4116b2b0 0x00faa2b0(16425648)
421c0000 421c1000 430da254 0x00f19254(15831636)
491c0000 491c1000 49b98e0c 0x009d7e0c(10321420)
Large object heap starts at 0x02301000
segment begin allocated size
02300000 02301000 02f1bf20 0x00c1af20(12693280)
Total Size 0x31786160(829972832)
------------------------------
GC Heap Size 0x31786160(829972832)
4 Réponses :
Dans mon expérience, il est rarement utile de regarder Si vous essayez de déterminer pourquoi l'application utilise beaucoup de mémoire, essayez d'identifier d'autres types qui peuvent ou non encapsuler Si vous fournissez plus d'informations sur ce que vous essayez d'accomplir, je pourra peut-être fournir des conseils plus spécifiques.
Edit: La fragmentation n'est pas nécessairement aussi mauvaise que cela puisse sonner et 100 MB sans me frapper comme un nombre élevé alarmant. Avez-vous identifié si les blocs gratuits sont dans le tas de génération sur le gros tas d'objets?
Quelle est la sortie de objet [] car il s'agit du type sous-jacent de nombreux types, ce qui signifie que vous allez vous retrouver avec beaucoup d'entre eux sur le tas rendre plus difficile l'identification de la bonne. De plus, des structures internes telles que le Table à chaîne interne est également stocké comme un objet [] .
objet [] et découvrez ce que ces racines sont racines.
! eeeap -gc ?
Je cherche une éventuelle fragmentation de la mémoire pour les problèmes d'OOM que j'ai. En utilisant zhaun.net/post/... comme point de départ. Je vois très différent! Sortie GCROT dans la mémoire de mémoire, il y a 48093 objets libres consommant 112 Mo le fichier de vidage est de 1,2 Go. Courir A! GCROT prend environ 30 minutes pour que je ne puisse échantillonner que des objets aléatoires. Je ne pense pas que le type de l'objet est aussi important que quelque chose l'a épinglé. Ce n'est qu'une chose que nous examinons pour les problèmes d'OOM. Déjà eu une fuite d'événement de 300 Mo sur 10 heures
Dans le grand schéma des choses, 100 Mo n'est pas si grande, mais cela pourrait être encombrer les choses. Je crois que l'objet que je cherchais est dans Gen2, c'est une application de bureau afin que la plupart des choses se retrouvent dans Gen2. Le loh comme 60mb libèrent
Votre utilisation de tas est de 800 Mo et l'EHEAP montre que la majorité est sur le tas de Gen 2, alors que seul un peu est sur Loh. Si vous souhaitez identifier des blocs gratuits, vous pouvez faire un! Dumpheap -type gratuit
Suis-je correct dans ma compréhension que! Dumpheap -Type retourne libre espace qui n'a aucun objet, et est inutilisable? L'objet épinglé dans ma question est l'objet suivant après l'un des éléments libres. Je viens de choisir un couple au hasard de la liste de 48 0093, je pense que c'est une impasse.
Oui, les spots gratuits sont un espace libre sur le tas. S'ils sont situés à côté des objets épinglés, ils ne seront pas mis à disposition pendant le compactage. Cependant, ces objets ne doivent pas être épinglés pour toujours, ce qui finit donc que le compactage devrait pouvoir se débarrasser des morceaux libres.
Sauf si je fuit des objets épinglés.
GCROT ne vous dira généralement pas pourquoi quelque chose est épinglé. Beaucoup de tableaux d'objets que vous trouvez dans CLR sont utilisés pour des choses internes. Au lieu de cela, lisez votre commentaire sur l'autre réponse, pourrais-je suggérer que vous commenciez d'abord avec quelque chose de différent pour suivre votre fuite de mémoire?
Commencez par "! Dumpheap -stat" et regardez les plus gros utilisateurs de mémoire. Cependant, ignorer les types CLR de base tels que l'objet [], la chaîne, etc. trouvez lequel de vos objets (définis comme "non quelque chose dans mscorlib ou system.dll) qui sont là et découvrez quoi Racines celles-ci. C'est généralement plus facile à suivre une fuite de cette direction, même si elle s'avère que vous fuiez des types primitifs dans votre application.
C'est généralement comment je traque les fuites gérées dans CLR, et cela fonctionne assez bien pour la plupart des fuites.
Oui, c'est pourquoi je demande comment déterminer pourquoi un objet est épinglé. GCroot me dit simplement qu'un objet est épinglé.
Il n'y a pas de moyen de déterminer pourquoi un objet est épinglé autant que je sache. Encore une fois, remontant à cet exemple spécifique, une goupille vers un tableau d'objet est la manière dont nous stockons des variables statiques dans CLR. Donc, vous cherchez peut-être où nous domandons des variables statiques, mais je ne peux pas en être sûr. Certaines poignées épinglées vous pouvez indiquer pourquoi elles sont épinglées par le type (les poignées Refcnt, par exemple, sont uniquement utilisées dans Com-Interop). En général, vous ne pouvez pas déterminer pourquoi un objet est épinglé sans accès aux sources et aux symboles CLR.
La commande ! Findtrotes dans .NET 4's SOS (ou ! Refs dans Sosex ) Attend que le prochain GC (vous pouvez spécifier quelle génération) et vous indiquera ensuite quelles racines l'objet a.
Peut-être que cela aide
http://blogs.msdn.com/ B / DOUGSTE / Archive / 2005/11/25 / 497016.aspx
Link Seules les réponses sont découragées sur le débordement de la pile. Si le lien est brisé, l'information est presque inutile. Mieux inclure les parties pertinentes comme extrait de la réponse. Merci.