5

Używam profilera pamięci ANTS do diagnozowania wzrostu wycieku pamięci, który napotykam w jednej z moich aplikacji .NET 2.0. I trwało 7 migawek procesu w ciągu 7,5 godziny, a tu Tabelaryczne przedstawienie danych otrzymanych -. Wykorzystanie pamięci aplikacji .NET - wysoka nieużywana .NET i niezarządzana pamięć i fragmentacja

enter image description here

G1 reprsents generacji rozmiarze 1 i G2 generacja 2 wielkości. Z wyjątkiem niezarządzanej przestrzeni i prywatnych bajtów wszystkie pozostałe wartości są w MB.

Moje pytania są -

  1. Dlaczego istnieje takie wysokie niewykorzystana przestrzeń NET nawet gdy rozmiary sterty są niskie?

  2. Moja duża sterta obiektu osiąga maksymalnie około 2 MB, a podczas ostatnich 3 migawek pozostaje na poziomie 96 KB. Dlaczego więc istnieją tak duże fragmenty i czy są one odpowiedzialne za wysoką niewykorzystaną przestrzeń?

  3. Przestrzeń niezarządzana stale rośnie. Czy jest to odpowiedzialne za zwiększenie prywatnych bajtów w czasie?

Jestem po mojej stronie dowcipnej rozwiązać ten problem i przeprowadziłem kilka analiz, ale nie mogę znaleźć odpowiedniego rozwiązania tego problemu. Jestem gotów dostarczyć wszelkie inne potrzebne dane.

+0

To może być wynikiem pozostania obiektów w pamięci. Może powinieneś zweryfikować, czy wszystkie używane obiekty są dobrze rozmieszczone, ponieważ ciągłe ponowne instanowanie będzie wymagać przydzielenia większej ilości przestrzeni pamięci. Co może być przyczyną fragmentacji również –

+0

Istnieje bardzo mało obiektów na LOH. Profiler pokazuje tablicę, która pozostaje na nim od początku aplikacji, a inna tablica jest przydzielana i de-alokowana w regularnych odstępach czasu, co jest oczekiwane. – Cygnus

+0

Czy druga tablica jest prawidłowo umieszczona? GC w LOH jest bardzo rzadkim wydarzeniem.Możliwy scenariusz polega na tym, że twoja druga tablica zostaje przydzielona przed GC, więc możliwy scenariusz może wyglądać tak: [1,2] (początek aplikacji) [1,2,2] (druga tablica dostaje realokację) Gdy otrzymasz GC w LOH, twój LOH będzie wyglądał następująco: [1,0,0,0,0,2] następnie zaczniesz przydzielać drugą tablicę jeszcze raz i otrzymasz: [1, 2,0,0,0,2] Jeśli druga macierz nie ma stałej długości, rzeczy mogą być jeszcze gorsze. Pomysł polega na tym, że nie pozwala to na wiele realokacji w LOH. – Alex

Odpowiedz

2

Alex wskazał już bardzo ładne wyjaśnienie klasy problemem dużej fragmentacji sterty obiekt znajduje się tutaj:

https://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/

Problem jest dobrze znany w .NET FX Dev Team i został opracowany w sposób ciągły w. Istnieje duża szansa, że ​​objawy zanikną przy użyciu nowszych wersji FX.

Począwszy od .NET 4.5.1 nastąpi wywołanie metody GC nawet kompaktowy LOH: http://blogs.msdn.com/b/mariohewardt/archive/2013/06/26/no-more-memory-fragmentation-on-the-large-object-heap.aspx Jednak znalezienie przyczyną tej LOHF byłby sposób bardziej efektywny niż tylko wycierając ją sterty marnowania ton ms:

Daj mi znać, jeśli potrzebujesz dalszych szczegółów, jak wyizolować takie efekty.

Seb