Narzędzia do rozwiązywania problemów z pamięcią
Uwaga
Plany Podstawowa, Standardowa i Enterprise zostaną wycofane od połowy marca 2025 r. z 3-letnim okresem emerytalnym. Zalecamy przejście do usługi Azure Container Apps. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu usługi Azure Spring Apps.
Zużycie standardowe i dedykowany plan zostaną wycofane od 30 września 2024 r. z całkowitym zamknięciem po sześciu miesiącach. Zalecamy przejście do usługi Azure Container Apps. Aby uzyskać więcej informacji, zobacz Migrowanie użycia usługi Azure Spring Apps w warstwie Standardowa i dedykowanego planu do usługi Azure Container Apps.
Ten artykuł dotyczy: ✔️ Podstawowa/Standardowa ✔️ Enterprise
W tym artykule opisano różne narzędzia przydatne do rozwiązywania problemów z pamięcią w języku Java. Te narzędzia można używać w wielu scenariuszach nie tylko do problemów z pamięcią, ale ten artykuł koncentruje się tylko na temacie pamięci.
Alerty i diagnostyka
W poniższych sekcjach opisano alerty dotyczące kondycji zasobów i diagnostykę dostępną za pośrednictwem witryny Azure Portal.
Kondycja zasobów
Zdarzenia cyklu życia aplikacji można monitorować i konfigurować alerty za pomocą dziennika aktywności platformy Azure i usługi Azure Service Health. Aby uzyskać więcej informacji, zobacz Monitorowanie zdarzeń cyklu życia aplikacji przy użyciu dziennika aktywności platformy Azure i usługi Azure Service Health.
Usługa Resource Health wysyła alerty dotyczące zdarzeń ponownego uruchamiania aplikacji z powodu problemów z brakiem pamięci (OOM). Aby uzyskać więcej informacji, zobacz Problemy z ponownym uruchamianiem aplikacji spowodowane problemami braku pamięci.
Poniższy zrzut ekranu przedstawia alert kondycji zasobów aplikacji wskazujący problem z rozwiązaniem OOM.
Diagnozowanie i rozwiązywanie problemów
Diagnostyka usługi Azure Spring Apps to interaktywne środowisko do rozwiązywania problemów z aplikacją bez konfiguracji. Aby uzyskać więcej informacji, zobacz Samodzielne diagnozowanie i rozwiązywanie problemów w usłudze Azure Spring Apps.
W witrynie Azure Portal możesz znaleźć użycie pamięci w obszarze Diagnozowanie i rozwiązywanie problemów, jak pokazano na poniższym zrzucie ekranu.
Użycie pamięci zapewnia prostą diagnostykę użycia pamięci aplikacji, jak pokazano na poniższym zrzucie ekranu.
Metryki
W poniższych sekcjach opisano metryki, które obejmują problemy, w tym wysokie użycie pamięci, pamięć stert, która jest zbyt duża, oraz nieprawidłowe odzyskiwanie pamięci (zbyt częste lub nie wystarczająco częste). Aby uzyskać więcej informacji, zobacz Szybki start: monitorowanie aplikacji platformy Azure Spring Apps przy użyciu dzienników, metryk i śledzenia.
Użycie pamięci aplikacji
Użycie pamięci aplikacji jest wartością procentową równą pamięci aplikacji używanej przez limit pamięci aplikacji. Ta wartość pokazuje całą pamięć aplikacji.
jvm.memory.used/committed/max
W przypadku pamięci JVM istnieją trzy metryki: jvm.memory.used, jvm.memory.committedi jvm.memory.max, które zostały opisane na poniższej liście.
"Pamięć JVM" nie jest jasno zdefiniowaną koncepcją. jvm.memory Oto suma pamięci sterta i byłej części pamięci stertowej nienależących do stert. Pamięć JVM nie obejmuje pamięci bezpośredniej ani innej pamięci, takiej jak stos wątków. Siłownik Spring Boot zbiera te trzy metryki i określa zakres elementu jvm.memory.
jvm.memory.usedjest ilością używanej pamięci JVM, w tym używanej pamięci stertowej i używanych byłych modułów permGen w pamięci niezwiązanej z stertą.jvm.memory.usedjest głównym odzwierciedleniem zmiany pamięci sterta, ponieważ była część permGen jest zwykle stabilna.Jeśli okaże
jvm.memory.usedsię zbyt duży, rozważ ustawienie mniejszego maksymalnego rozmiaru pamięci sterty.jvm.memory.committedto ilość pamięci zatwierdzonej dla maszyny JVM do użycia. Rozmiarjvm.memory.committedjest w zasadzie limitem użytecznej pamięci JVM.jvm.memory.maxto maksymalna ilość pamięci JVM, która nie jest mylona z rzeczywistą dostępną ilością.Wartość
jvm.memory.maxmoże czasami być myląca, ponieważ może być znacznie wyższa niż dostępna pamięć aplikacji. Aby wyjaśnić,jvm.memory.maxjest sumą wszystkich maksymalnych rozmiarów pamięci sterty i byłej części pamięci niezwiązanej z stertą, niezależnie od rzeczywistej dostępnej pamięci. Jeśli na przykład aplikacja jest ustawiona z 1 GB pamięci w portalu Azure Spring Apps, domyślny rozmiar pamięci sterty wynosi 0,5 GB. Aby uzyskać więcej informacji, zobacz sekcję Domyślny maksymalny rozmiar sterty zarządzania pamięcią w języku Java.Jeśli domyślny rozmiar skompresowanego miejsca w klasie wynosi 1 GB, wartość
jvm.memory.maxjest większa niż 1,5 GB niezależnie od tego, czy rozmiar pamięci aplikacji wynosi 1 GB. Aby uzyskać więcej informacji, zobacz Java Platform, Standard Edition HotSpot Virtual Machine Tuning Guide: Other Considerations in the Oracle documentation (Platforma Java, HotSpot Virtual Machine Virtual Machine Tuning Guide: Other Considerations in the Oracle documentation).
jvm.gc.memory.allocated/promowany
Te dwie metryki służą do obserwacji odzyskiwania pamięci w języku Java (GC). Aby uzyskać więcej informacji, zobacz sekcję Odzyskiwanie pamięci w języku Java w temacie Zarządzanie pamięcią w języku Java. Maksymalny rozmiar sterty ma wpływ na częstotliwość drobnych GC i pełne GC. Maksymalna przestrzeń metadanych i maksymalny rozmiar pamięci bezpośredniej mają wpływ na pełną GC. Jeśli chcesz dostosować częstotliwość odzyskiwania pamięci, rozważ zmodyfikowanie następujących maksymalnych rozmiarów pamięci.
jvm.gc.memory.allocatedjest to wielkość zwiększenia rozmiaru puli pamięci młodej generacji po jednym GC i przed następnym. Ta wartość odzwierciedla drobne GC.jvm.gc.memory.promotedto wielkość wzrostu rozmiaru puli pamięci starej generacji po GC. Ta wartość odzwierciedla pełną GC.
Tę funkcję można znaleźć w witrynie Azure Portal, jak pokazano na poniższym zrzucie ekranu. Możesz wybrać określone metryki i dodać filtry dla określonej aplikacji, wdrożenia lub wystąpienia. Można również zastosować dzielenie.
Dalsze debugowanie
W celu dalszego debugowania można ręcznie przechwytywać zrzuty sterty i zrzuty wątków oraz używać narzędzia Java Flight Recorder (JFR). Aby uzyskać więcej informacji, zobacz Przechwytywanie zrzutu sterty i zrzutu wątku ręcznie i używanie narzędzia Java Flight Recorder w usłudze Azure Spring Apps.
Zrzuty sterty rejestrują stan pamięci sterty Java. Zrzuty wątków rejestrują stosy wszystkich wątków na żywo. Te narzędzia są dostępne za pośrednictwem interfejsu wiersza polecenia platformy Azure i na stronie aplikacji witryny Azure Portal, jak pokazano na poniższym zrzucie ekranu.
Aby uzyskać więcej informacji, zobacz Przechwytywanie zrzutu sterty i zrzutu wątku ręcznie i używanie narzędzia Java Flight Recorder w usłudze Azure Spring Apps. Do analizowania zrzutów sterty można również użyć narzędzi innych firm, takich jak Analizator pamięci.
Modyfikowanie konfiguracji w celu rozwiązania problemów
Niektóre problemy, które można zidentyfikować, obejmują kontener OOM, pamięć sterty, która jest zbyt duża i nietypowe odzyskiwanie pamięci. W przypadku zidentyfikowania któregokolwiek z tych problemów może być konieczne skonfigurowanie maksymalnego rozmiaru pamięci w opcjach JVM. Aby uzyskać więcej informacji, zobacz sekcję Ważne opcje JVM zarządzania pamięcią w języku Java.
Opcje JVM można modyfikować przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.
W witrynie Azure Portal przejdź do aplikacji, a następnie wybierz pozycję Konfiguracja w sekcji Ustawienia menu nawigacji. Na karcie Ustawienia ogólne zaktualizuj pole Opcje JVM, jak pokazano na poniższym zrzucie ekranu:
