Mam proces przechowywania 130 MB pamięci według Menedżera zadań, z tylko 11 MB żywych obiektów .NET zgodnie z dotTrace, więc zastanawiam się, co dzieje się z innymi 120MB?Narzędzia do analizy śladu pamięci natywnych bibliotek DLL i zespołów załadowanych w procesie?
Potrzebowałbym narzędzia do listy zestawów i natywnych bibliotek DLL załadowanych do procesu, pobrania rozmiaru obrazów w procesie, a dla każdego zespołu zmierzenie śladu pamięciowego metod JITed.
ListDlls z SysInternal wykonuje częściowo tę pracę. Ale nie mierzy rozmiaru kodu JITed i dostarcza tylko nieprzetworzonych danych. Idealnie chciałbym interfejsu użytkownika do analizy i podsumowania tych danych.
Niedawno zespół Visual Studio zgłosił, że wykonał taką analizę za pomocą narzędzia PerfView. Jest to określone w poście na blogu Visual Studio 11 Beta Performance Part #1, sekcja: Największy konsument VM - biblioteki DLL. Czy ktoś ma doświadczenie i opinie analizujące natywne ślady bibliotek Dll i złożeń za pomocą PerfView?
Z wyjątkiem ListDlls i PerfView, czy poleciłbyś inne narzędzie?
Ok, VMMAP poinformowani przez Simon MOURIER wydaje się być bardziej odpowiednie narzędzie do tego zadania. 
VMMAP pokazuje, że większość pamięci zestawu roboczego przechodzi do Zarządzanego stosu (113 MB w kolorze zielonym poniżej), więc problem jest bardziej związany z obiektami .NET niż pamięć niezarządzana. Zielona krzywa zębów piły jest jedynie linią czasową sesji ładowania/rozładowywania. Z jakichś powodów, moje pierwsze środki były całkiem źle:
- dotTrace mówi mi że mam 41MB .NET obiektów przydzielone
- WMMAP przedstawia zestaw roboczy 180MB (menedżer zadań pokazuje podobną liczbę)
- WMMAP pokazuje 113 MB zarządzanej sterty przydzielonej przez GC. 90MB to udało pamięci sterty jest w zestaw roboczy:
Więc mój plan:
- Zidentyfikuj dlaczego GC przydziela 113MB zarządzanej stercie do 41MB .NET obiektów? (czy takie liczby są normalne?) czy jest to spowodowane dużą fragmentacją?)
- Prace nad zmniejszeniem tego 41 MB zbioru obiektów .NET przydzielonych!
Witaj, mój przyjacielu Simon, spróbuję VMMAP, ponieważ rzeczywiście w blogu VS11 wspominają o tym, ale wspominają też, że zrobili narzędzie powyżej VMMAP, aby wykorzystać jego wyniki. Spróbuję również GDIView, o którym nie wiedziałem! Dzięki –
Dzięki Simonowi, VMMAP bardzo pomaga uzyskać pełny obraz. Moje dzisiejsze wyniki wydają się sugerować, że jest to bardziej problem z pamięcią GC/zarządzaną niż problem niezarządzany. Zobacz powyżej szczegóły. Czy jest jakiś pomysł, dlaczego GC ma 113 MB zarządzanej pamięci na 41 MB obiektów .NET? –
@PatrickfromNDependteam - Jeśli jest zarządzany, powinieneś zanurkować w usłudze SOS (http://msdn.microsoft.com/en-us/library/bb190764.aspx) przy użyciu Windbg lub Visual Studio (http://blogs.msdn.com /b/vancem/archive/2006/03/07/545596.aspx) i użyj znanego polecenia * objsize *. Zrzuci między innymi listę obiektów .NET. Process Explorer (najnowsze wersje) może wyświetlać statystyki GC. Prawdopodobnie chcesz również rzucić okiem na stertę dużych obiektów lub LOH (http://msdn.microsoft.com/en-us/magazine/cc534993.aspx), który jest bardzo specjalną stertą (nie można go zagęszczać) –