DA0018: aplikacje 32-bitowe uruchomione w procesie zarządzane limity pamięci

Identyfikator reguły	DA0018
Kategoria	Użycie narzędzia profilowania
Metoda profilowania	Pobieranie próbek
Wiadomości	Zarządzane zbliża się domyślny limit dla 32-bitowego procesu alokacji pamięci.Aplikacja może być związany z pamięci.
Typ reguły	Ostrzeżenie

Gdy profil za pomocą pobierania próbek.NET pamięci lub zasobów metody rywalizacji, musi zebrać co najmniej 10 próbek, aby wyzwalać tę regułę.

Przyczyna

Wskazuje system danych zebranych podczas uruchomienia profilowania.NET Framework pamięci sterty zwrócił się maksymalny rozmiar, który zarządzanych stosach można osiągnąć w procesie 32-bitowych.Dopuszczalny rozmiar jest wartość domyślna.Jest on oparty na całkowitą ilość przestrzeni adresowej procesu, która może być alokowana dla bajtów prywatnych.Wartość zgłoszona, maksymalna obserwuje się wartość stert podczas procesu PROFILOWANEGO była aktywna.Należy wziąć pod uwagę profilowanie ponownie przy użyciu.NET pamięci profilowania metody i optymalizacji wykorzystania zasobów zarządzanych przez aplikację.

Gdy rozmiar zarządzanego podejścia stosach domyślny limit, proces kolekcji garbage automatyczne może być wywołany częściej.Zwiększa to obciążenie związane z zarządzania pamięcią.

Reguła uruchamiany tylko dla aplikacji 32-bitowych, działających na komputerach 32-bitowych.

Opis reguły

Microsoft.NETTO wspólnej języka run-time (CLR) udostępnia mechanizm zarządzania automatyczne pamięci, który używa garbage collector w celu odzyskania pamięci od obiektów, nie są już wykorzystywane przez aplikację.Garbage collector jest zorientowana na generowanie oparte na założeniu, że wiele przydziałów są krótkotrwałe.Na przykład, zmiennych lokalnych, powinny być krótkotrwałej.Nowo utworzone obiekty Uruchom w generacji 0 (gen 0), a następnie postępu one generation 1, gdy one przetrwać wyrzucania elementów bezużytecznych uruchomić, a na końcu przejścia do generacji 2 Jeśli aplikacja nadal wykorzystuje je.

Zarządzane obiekty, które są większe niż 85 KB są przydzielane na dużych sterty obiektu, gdy podlegają one mniej częste wyrzucania elementów bezużytecznych i kompaktowanie niż mniejszych obiektów.duże obiekty są zarządzane oddzielnie, ponieważ zakłada się, że są one bardziej trwałe i ponieważ mieszanie, trwałe i dużych obiektów z często przydzielonego mniejszych obiektów może wygenerować cast najgorszej fragmentacji sterty.

Jako całkowity rozmiar zarządzanego podejścia stosach domyślny limit, obciążenie związane z zarządzania pamięcią zazwyczaj zwiększa się do punktu, w którym można uruchomić na uderzenie, elastyczność i skalowalność aplikacji.

Jak do zbadania ostrzeżenie

Kliknij dwukrotnie wiadomość w oknie Lista błędów, aby przejść do znaki widok.Znajdź .NET CLR Memory\ bajtów we wszystkich stert i # Total Zadeklarowane bajty kolumny.Ustalić, czy poszczególnych faz wykonywania programu gdzie alokacji pamięci zarządzane jest cięższe niż inne faz.Porównać wartości z liczba bajtów w wszystkich stert kolumny do stawki wyrzucania elementów bezużytecznych zgłoszone w .NET CLR Memory\ # zbiorów Gen 0, .NET CLR Memory\ # zbiorów Gen 1, i .NET CLR Memory\ # Gen 2 zbiorów kolumny, aby określić, jeśli deseń alokacje zarządzanej pamięci ma wpływ na szybkość operacji wyrzucania elementów bezużytecznych.

W.NET Framework aplikacji, plików wykonywalnych języka wspólnego ogranicza całkowity rozmiar zarządzanego stosach do nieco mniej niż połowa maksymalnego rozmiaru obszaru prywatnych część przestrzeni adresowej procesu.Procesy 32-bitowe, uruchomione na komputerze 32-bitowy 2 GB reprezentuje górny limit prywatna część przestrzeni adresowej procesu.Całkowity rozmiar zarządzanego stert zaczyna podejścia jego domyślny limit, może zwiększyć obciążenie związane z zarządzaniem pamięci i może zmniejszyć wydajność aplikacji.

Jeżeli narzutów nadmiernego zarządzanej pamięci jest problem, należy rozważyć dowolnej z tych opcji:

• Optymalizowanie aplikacji Obciążenie zasobów zarządzanych pamięci

  - lub -

• podjęcie kroków do architektury ograniczenia na maksymalny rozmiar pamięci wirtualnej dla procesu 32-bitowe

Aby zoptymalizować użycie aplikacji zasobów zarządzanych pamięci, zbierania danych alokacji pamięci zarządzanych.Uruchom profilowania netto alokacji pamięci.Przegląd Narzędzia profilowania.Widoki danych pamięci netto raportów do zrozumienia struktury aplikacji alokacji pamięci.

Użyj Widok okres istnienia obiektu celem ustalenia, które dane programu obiekty są przeżywające do wytwarzania i następnie regeneracji stamtąd.

Użyj .Widok alokacji pamięci netto do określania ścieżki wykonanie, która spowodowała tych przydziałów.

Aby uzyskać więcej informacji na temat zwiększania wydajności kolekcji garbage Zobacz.NET Framework artykuł techniczny, podstawy Garbage Collector i wskazówki dotyczące wydajności w witrynie MSDN w sieci Web.

Uzyskanie architektury zwolnienia z ograniczeń rozmiaru pamięci wirtualnej prywatna część przestrzeni adresowej procesu, spróbuj uruchamianie tego procesu 32-bitowego na komputerze 64-bitowym.Proces 32-bitowego na komputerze 64-bitowe mogą uzyskiwać do 4 GB pamięci wirtualnej prywatnych.

Proces 64-bitowe uruchomione na komputerze 64-bitowych można nabyć maksymalnie 8 TB pamięci wirtualnej.Należy wziąć pod uwagę, wykonując ponowną kompilację aplikacji do wykonania w aplikacji macierzystej 64-bitowych.Ta reguła jest jedynie w celach informacyjnych i mogą nie wymagać działań naprawczych.