Udostępnij za pośrednictwem


Narzędzia do rozwiązywania problemów z pamięcią

Uwaga

Azure Spring Apps to nowa nazwa usługi Azure Spring Cloud. Mimo że usługa ma nową nazwę, stara nazwa będzie widoczna w niektórych miejscach przez pewien czas, ponieważ pracujemy nad aktualizowaniem zasobów, takich jak zrzuty ekranu, filmy wideo i diagramy.

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.

Screenshot of Azure portal showing Azure Spring Apps Resource Health page with OOM message highlighted.

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.

Screenshot of Azure portal showing Azure Spring Apps Diagnose and solve problems page with Memory Usage highlighted in drop-down menu.

Użycie pamięci zapewnia prostą diagnostykę użycia pamięci aplikacji, jak pokazano na poniższym zrzucie ekranu.

Screenshot of Azure portal showing Azure Spring Apps Memory Usage page.

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.used jest 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.used jest głównym odzwierciedleniem zmiany pamięci sterta, ponieważ była część permGen jest zwykle stabilna.

    Jeśli okaże jvm.memory.used się zbyt duży, rozważ ustawienie mniejszego maksymalnego rozmiaru pamięci sterty.

  • jvm.memory.committed to ilość pamięci zatwierdzonej dla maszyny JVM do użycia. Rozmiar jvm.memory.committed jest w zasadzie limitem użytecznej pamięci JVM.

  • jvm.memory.max to maksymalna ilość pamięci JVM, która nie jest mylona z rzeczywistą dostępną ilością.

    Wartość jvm.memory.max może czasami być myląca, ponieważ może być znacznie wyższa niż dostępna pamięć aplikacji. Aby wyjaśnić, jvm.memory.max jest 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.max jest 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.allocated jest 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.promoted to 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.

Screenshot of Azure portal showing Azure Spring Apps Metrics page.

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.

Screenshot of Azure portal showing app overview page with Troubleshooting button highlighted.

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 Ogólne Ustawienia zaktualizuj pole Opcje JVM, jak pokazano na poniższym zrzucie ekranu:

Screenshot of Azure portal showing app configuration page with JVM options highlighted.

Zobacz też