Udostępnij za pośrednictwem

Problemy z ponownym uruchamianiem aplikacji spowodowane problemami braku pamięci

  • Artykuł

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 problemy z brakiem pamięci (OOM) dla aplikacji Java w usłudze Azure Spring Apps.

Typy problemów z brakiem pamięci

Istnieją dwa typy problemów z brakiem pamięci: OOM kontenera i OOM JVM.

  • Kontener OOM, nazywany również systemowym modelem OOM, występuje, gdy zabraknie dostępnej pamięci aplikacji. Problem z OOM kontenera powoduje, że zdarzenia ponownego uruchamiania aplikacji są zgłaszane w sekcji Resource Health w witrynie Azure Portal. Zwykle system OOM kontenera jest spowodowany nieprawidłowymi konfiguracjami rozmiaru pamięci.

  • OOM JVM występuje, gdy ilość używanej pamięci osiągnęła maksymalny rozmiar ustawiony w opcjach JVM. OOM maszyny JVM nie spowoduje ponownego uruchomienia aplikacji. Zwykle JVM OOM jest wynikiem nieprawidłowego kodu, który można znaleźć, wyszukując java.lang.OutOfMemoryError wyjątki w dzienniku aplikacji. OOM JVM ma negatywny wpływ na aplikacje i narzędzia profilowania Java, takie jak Java Flight Recorder.

W tym artykule opisano sposób rozwiązywania problemów z systemem OOM kontenera. Aby rozwiązać problemy z systemem OOM JVM, sprawdź narzędzia, takie jak zrzut stert, zrzut wątków i narzędzie Java Flight Recorder. 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.

Rozwiązywanie problemów z ponownym uruchamianiem aplikacji z powodu OOM

W poniższych sekcjach opisano narzędzia, metryki i opcje JVM, których można użyć do diagnozowania i rozwiązywania problemów z OOM kontenera.

Wyświetlanie alertów na stronie Kondycja zasobu

Na stronie Kondycja zasobu w witrynie Azure Portal są wyświetlane zdarzenia ponownego uruchamiania aplikacji spowodowane przez OOM kontenera, jak pokazano na poniższym zrzucie ekranu:

Zrzut ekranu witryny Azure Portal przedstawiający stronę usługi Azure Spring Apps Resource Health z wyróżnionym komunikatem OOM.

Konfigurowanie rozmiaru pamięci

Metryki Użycie pamięci aplikacji i jvm.memory.usedjvm.memory.committed zapewniają widok użycia pamięci. Aby uzyskać więcej informacji, zobacz sekcję Metryki narzędzia do rozwiązywania problemów z pamięcią. Skonfiguruj maksymalne rozmiary pamięci w opcjach JVM, aby upewnić się, że pamięć jest ograniczona.

Suma maksymalnego rozmiaru pamięci wszystkich części modelu pamięci Java powinna być mniejsza niż rzeczywista dostępna pamięć aplikacji. Aby ustawić maksymalne rozmiary pamięci, zobacz typowy układ pamięci opisany w sekcji Układ użycia pamięci w temacie Zarządzanie pamięcią w języku Java.

Znajdź saldo po ustawieniu maksymalnego rozmiaru pamięci. Po ustawieniu zbyt dużego rozmiaru pamięci istnieje ryzyko wystąpienia kontenera OOM. Po ustawieniu maksymalnego rozmiaru pamięci za mało wystąpi ryzyko wystąpienia OOM JVM, a odzyskiwanie pamięci będzie miało miejsce i spowolni aplikację.

Kontrolowanie pamięci stert

Maksymalny rozmiar sterty można ustawić przy użyciu -Xmsopcji , -Xmx, -XX:InitialRAMPercentagei -XX:MaxRAMPercentage JVM.

Może być konieczne dostosowanie ustawień maksymalnego rozmiaru sterty, gdy wartość jvm.memory.used jest zbyt wysoka w metrykach. Aby uzyskać więcej informacji, zobacz sekcję jvm.memory.used/committed/max w sekcji Narzędzia do rozwiązywania problemów z pamięcią.

Kontrolowanie pamięci bezpośredniej

Ważne jest, aby ustawić -XX:MaxDirectMemorySize opcję JVM z następujących powodów:

  • Nie można zauważyć, gdy struktury, takie jak nio i gzip, używają pamięci bezpośredniej.
  • Odzyskiwanie pamięci bezpośredniej jest obsługiwane tylko podczas pełnego odzyskiwania pamięci, a pełne odzyskiwanie pamięci odbywa się tylko wtedy, gdy sterta jest prawie pełna.

Zwykle można ustawić MaxDirectMemorySize wartość mniejszą niż rozmiar pamięci aplikacji pomniejszonej o pamięć sterty pomniejszoną o pamięć niezwiązaną z stertą.

Metaspace kontrolki

Maksymalny rozmiar przestrzeni metadanych można ustawić, ustawiając -XX:MaxMetaspaceSize opcję JVM. Opcja -XX:MetaspaceSize ustawia wartość progową w celu wyzwolenia pełnego odzyskiwania pamięci.

Pamięć w przestrzeni metadanych jest zwykle stabilna.

Zobacz też