메모리 문제를 해결하는 도구

이 문서는 기본/표준 ✅ 엔터프라이즈에✅ 적용됩니다.

이 문서에서는 Java 메모리 문제를 해결하는 데 유용한 다양한 도구에 대해 설명합니다. 메모리 문제에 국한되지 않는 많은 시나리오에서 이러한 도구를 사용할 수 있지만 이 문서에서는 메모리 항목에만 중점을 둡니다.

경고 및 진단

다음 섹션에서는 Azure Portal을 통해 사용할 수 있는 리소스 상태 경고 및 진단에 대해 설명합니다.

리소스 상태

앱 수명 주기 이벤트를 모니터링하고 Azure Activity 로그 및 Azure Service Health 통해 경고를 설정할 수 있습니다. 자세한 내용은 Azure 활동 로그 및 Azure Service Health를 사용하여 앱 수명 주기 이벤트 모니터링을 참조하세요.

리소스 상태는 OOM(컨테이너 메모리 부족) 문제로 인해 앱 다시 시작 이벤트에 대한 경고를 보냅니다. 자세한 내용은 메모리 부족 문제로 인한 앱 다시 시작 문제를 참조하세요.

다음 스크린샷은 OOM 문제를 나타내는 앱 리소스 상태 경고를 보여 줍니다.

문제 진단 및 해결

Azure Spring Apps 진단은 구성 없이 앱 문제를 해결하는 대화형 환경입니다. 자세한 내용은 Azure Spring Apps에서 자체 진단 및 문제 해결을 참조하세요.

Azure Portal에서 다음 스크린샷과 같이 문제 진단 및 해결에서 메모리 사용량을 확인할 수 있습니다.

메모리 사용량은 다음 스크린샷과 같이 앱 메모리 사용에 대한 간단한 진단을 제공합니다.

메트릭

다음 섹션에서는 높은 메모리 사용량, 너무 큰 힙 메모리, 비정상적인 가비지 수집 비정상(너무 자주 또는 충분히 자주 사용하지 않음) 등의 문제를 다루는 메트릭에 대해 설명합니다. 자세한 내용은 빠른 시작 - 로그, 메트릭, 추적을 사용하여 Azure Spring Apps 앱 모니터링을 참조하세요.

앱 메모리 사용량

앱 메모리 사용량은 앱 메모리 제한으로 나눈 사용된 앱 메모리에 대한 백분율입니다. 이 값은 전체 앱 메모리를 표시합니다.

jvm.memory.used/committed/max

JVM 메모리의 경우 다음 목록에 설명된 세 가지 메트릭인 jvm.memory.used, jvm.memory.committed, jvm.memory.max가 있습니다.

“JVM 메모리”는 명확하게 정의된 개념이 아닙니다. 여기서, jvm.memory는 힙 메모리와 비힙 메모리의 이전 permGen 부분의 합계입니다. JVM 메모리에는 직접 메모리 또는 스레드 스택과 같은 다른 메모리가 포함되지 않습니다. Spring Boot Actuator는 이러한 세 가지 메트릭을 수집하고 jvm.memory의 범위를 결정합니다.

• jvm.memory.used는 사용된 힙 메모리 및 비힙 메모리에서 사용된 이전 permGen을 포함하여 사용된 JVM 메모리의 양입니다.

  일반적으로 이전 permGen 부분은 안정적이므로 jvm.memory.used는 힙 메모리 변경을 대부분 반영합니다.

  jvm.memory.used가 너무 큰 경우 최대 힙 메모리 크기를 더 작게 설정하는 것이 좋습니다.

• jvm.memory.committed는 JVM에서 사용할 커밋된 메모리 양입니다. jvm.memory.committed의 크기는 기본적으로 사용 가능한 JVM 메모리의 제한입니다.

• jvm.memory.max는 JVM 메모리의 최대 양이며, 실제 사용 가능한 양과 혼동하지 않아야 합니다.

  jvm.memory.max의 값은 사용 가능한 앱 메모리보다 훨씬 높을 수 있으므로 혼동될 수 있습니다. 명확히 하기 위해 jvm.memory.max는 실제 사용 가능한 메모리에 관계없이 힙 메모리의 모든 최대 크기 및 비힙 메모리의 이전 permGen 부분의 합계입니다. 예를 들어 앱이 Azure Spring Apps 포털에서 1GB 메모리로 설정된 경우 기본 힙 메모리 크기는 0.5GB입니다. 자세한 내용은 Java 메모리 관리의 기본 최대 힙 크기 섹션을 참조하세요.

  기본 압축 클래스 공간 크기가 1GB인 경우 앱 메모리 크기가 1GB인지 여부에 관계없이 jvm.memory.max 값은 1.5GB보다 큽니다. 자세한 내용은 Oracle 설명서의 Java Platform, Standard Edition HotSpot Virtual Machine 가비지 수집 튜닝 가이드: 기타 고려 사항을 참조하세요.

jvm.gc.memory.allocated/promoted

이러한 두 메트릭은 GC(Java 가비지 수집)를 관찰하기 위한 것입니다. 자세한 내용은 Java 메모리 관리의 Java 가비지 수집 섹션을 참조하세요. 최대 힙 크기는 부 GC 및 전체 GC의 빈도에 영향을 줍니다. 최대 메타스페이스 및 최대 직접 메모리 크기는 전체 GC에 영향을 미칩니다. 가비지 수집 빈도를 조정하려면 다음 최대 메모리 크기를 수정하는 것이 좋습니다.

• jvm.gc.memory.allocated는 한 GC 이후부터 그 다음 GC 전까지 젊은 세대 메모리 풀의 크기가 증가한 양입니다. 이 값은 사소한 GC를 반영합니다.

• jvm.gc.memory.promoted는 GC 이후 이전 세대 메모리 풀의 크기가 증가한 양입니다. 이 값은 전체 GC를 반영합니다.

다음 스크린샷과 같이 Azure Portal에서 이 기능을 확인할 수 있습니다. 특정 메트릭을 선택하고 특정 앱, 배포 또는 인스턴스에 대한 필터를 추가할 수 있습니다. 분할을 적용할 수도 있습니다.

추가 디버깅

추가 디버깅을 위해 힙 덤프 및 스레드 덤프를 수동으로 캡처하고 JFR(Java Flight Recorder)을 사용할 수 있습니다. 자세한 내용은 Azure Spring Apps에서의 힙 덤프 및 스레드 덤프의 수동 캡처 및 Java Flight Recorder 사용을 참조하세요.

힙 덤프는 Java 힙 메모리의 상태를 기록합니다. 스레드 덤프는 모든 라이브 스레드의 스택을 기록합니다. 이러한 도구는 다음 스크린샷과 같이 Azure CLI 및 Azure Portal의 앱 페이지에서 사용할 수 있습니다.

자세한 내용은 Azure Spring Apps에서의 힙 덤프 및 스레드 덤프의 수동 캡처 및 Java Flight Recorder 사용을 참조하세요. 메모리 분석기와 같은 타사 도구를 사용하여 힙 덤프를 분석할 수도 있습니다.

문제를 해결하도록 구성 수정

식별할 수 있는 몇 가지 문제에는 컨테이너 OOM, 너무 큰 힙 메모리, 비정상적인 가비지 수집이 포함됩니다. 이러한 문제를 식별하는 경우 JVM 옵션에서 최대 메모리 크기를 구성해야 할 수 있습니다. 자세한 내용은 Java 메모리 관리의 중요한 JVM 옵션 섹션을 참조하세요.

Azure Portal 또는 Azure CLI를 사용하여 JVM 옵션을 수정할 수 있습니다.

az spring app update \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --app <app-name> \
    --deployment <deployment-name> \
    --jvm-options <jvm-options> \

참고 항목

• Java 메모리 관리
• 메모리 부족 문제로 인한 앱 다시 시작 문제