관련링크

OutOfMemory(OOM) 에러는 설정된 메모리보다 요청된 메모리가 많아서 JVM에서 발생하는 에러로 설정 오류, 사용량 초과 등 기본적인 예측 용량 산정이 잘못된 경우 발생합니다.

OOM 에러가 났을 때 어떻게 분석하고 대처할까요? 그리고 와탭으로 어떻게 OOM이 발생했는지 확인할 수 있을까요? 이번 내용에서는 애플리케이션에 의한 OOM을 어떻게 발견하고 대처할 것인지 알아보겠습니다.

프로그램(애플리케이션)이 잘못 작성된 경우, 어떤 애플리케이션 요청을 받으면 해당 애플리케이션 하나가 잘못되어서 메모리를 과도하게 사용하는 경우가 있습니다.

예를 들어, 수백만 이상의 DB에서 레코드를 줘야해서 메모리를 들고 있는 경우나, 파일 업로드를 하는데 업로드 파일을 후처리 하느라 메모리를 다 쓴 경우 순간적으로 OOM이 일어나기도 합니다.

Java Tomcat으로 간단한 애플리케이션을 작성하는 예시 코드

OOM이 일어나는 다른 경우는 아주 장시간에 걸쳐서 서서히 메모리가 잠식될 때가 있습니다. 이를 JAVA에서는 메모리 릭이라고 합니다. 힙 메모리 릭은 크게 두 가지로 캐시 릭(Cache Leak)과 풀 릭(Pool Leak)이 있습니다.

캐시는 어떤 데이터를 여러 스레드가 공유해서 사용하는 것을 의미하며, 대표적인 캐시로는 codeCache, DataCache로 많이 부릅니다. 풀은 데이터를 배타적으로 사용할 때 씁니다. 풀의 경우, OOM으로 가기 이전에 풀 부족 현상으로 2차 장애가 발생하는 경우가 많습니다. 그래서 캐시에서 OOM이 많이 발생하는데요, 힙 덤프 분석을 통해 OOM을 분석하고 해결해야 합니다.

OOM은 일반적으로 설정에 의한 문제점이 있습니다. 먼저 용량에 맞게 애플리케이션을 설정해야 합니다. 그 이후, 순간적으로 OOM을 일으키는 애플리케이션이 나타나거나 메모리 릭에 의해서 OOM이 발생할 수 있습니다.

OOM을 분석할 수 있는 eclipse analyzer

두 가지 경우 모두 힙 덤프를 통해 OOM을 분석해야 합니다. 요즘에는 힙 메모리를 4GB, 12GB 등으로 설정하고 쓰는 경우가 굉장히 많은데요. 이렇게 대용량 메모리를 사용하면서 힙 덤프를 분석하기 위해서는 이보다 훨씬 더 큰 사이즈의 컴퓨터가 필요합니다. 16GB 힙 메모리를 쓴다면, 30GB 이상의 컴퓨터가 필요할 정도로 고사양 컴퓨터가 필요합니다.

와탭 액티브 스택에서 OOM 에러 추적하기

다른 경우로, 힙 덤프를 뜰 여유조차 없이 OOM 에러가 발생하는 경우가 있습니다. 이처럼 사후 처리를 어렵게 하는 경우 와탭 모니터링에서는 [분석] → [스택] 메뉴 에서 확인 가능합니다. 와탭 액티브 스택에는 트랜잭션 경로와 중요 애플리케이션 URL을 스크린샷 형태로 보관하고 있습니다.

실제 OOM 에러를 발생시켜 와탭으로 어떻게 문제를 발견하고 해결했는지 궁금하시다면 아래
WhaTip 영상에서 확인하실 수 있습니다!😊😊

1. [WhaTip] 1탄: OOM 에러와 메모리 릭
2. [WhaTip] 2탄: OOM 에러 테스트
3. [WhaTip] 3탄: OOM 에러 원인 분석, 와탭으로 하는 방법
4. 이커머스 기업에서는 어떻게 OOM 원인 분석을 했을까?