서버에서 지속적인 OutOfMemory가 발생하는 문제 해결

현재 서버에 매번 OutOfMemory로 인해서 서버가 다운되거나 ‘내 주변 러닝 코스 조회’가 안되는 문제가 있다.
 

 
이때만 해도 예상하는 문제점은 ‘내 주변 러닝 코스 조회’ 시에 주어진 반경(m)에 많은 코스들이 존재하고 있어 이를 모두 읽어오기 때문이라고 생각했다. 물론 한 두명의 사용자가 요청했다면 문제없겠지만, 스레드 수가 많아지는 순간 모든 코스 조회와 비슷한 경우가 되어버려 OutOfMemory 예외가 발생하는 것 같다고 추측했다. 그래서 mongoDB에서 db.collections.stats().avgObjSize 명령어를 통해 코스 데이터가 평균적으로 얼마의 크기를 갖는지 조사해봤다.
 

 
바이트 단위로 출력되니 KB로 계산해보면, 약 117KB가 된다. 이들 중 일부를 자바 객체로 변환한다면 약 38개의 좌표가 있는 400m 러닝 코스는 2.82KB가 된다. 118개의 좌표가 있는 약 1KM 코스는 6.30KB이다. 대부분 데이터들이 5KM 이상인 러닝 코스가 많아 거리에 따라 많은 좌표가 들어가므로 이는 더욱 커질 것이다.
 

 
이제 이러한 메모리 문제가 정말 ‘내 주변 러닝 코스 조회’로 인해 발생한 것인지 알아보기 위해서 CloudWatch의 메모리 사용량 지표를 확인했다.
 

 
하지만 의외로 이유는 다른 곳에 있었다. 사진을 보면 특정 순간에 엄청나게 치솟는 메모리를 볼 수 있다. 시간을 보면 대략 새벽 2시에 갑자기 치솟기 시작하는데, 이를 계속 올라갔다 내려가며 유지하다가 어느순간 훅 떨어지는 비정상적인 그래프를 보여주고 있었다. 보통 이렇게 들쭉날쭉한 그래프는 메모리 누수가 가장 큰 이유이다. 그래서 새벽 2시에 진행하고 있는 Batch 작업에 뭔가 문제가 있을 것이라 생각했다.
 

 
하지만 코드 상으로 메모리 누수에 관해서는 큰 문제가 없었다. 예외가 던져질 때 InputStream이 닫혀지지 않는다는 점 밖에 없었다. 그래서 다른 방식으로 접근해보도록 했다. 바로 JVM 힙 메모리와 GC이다. 이렇게 접근을 하고자 했던 이유는 heap space에서 OutOfMemory 예외가 발생하고 있기 때문이다. 어떤 방식으로 힙 메모리가 할당되고, GC가 돌아가는지 파악하면 어느정도 해소될 것 같았다.
 
먼저 여기서 드는 의문점은 메모리 사용량이 물리 메모리 + Swap 메모리보다 적은데, 왜 OutOfMemory가 나는걸까? 현재 EC2의 스펙은 t4g.micro로 2코어 CPU, 1GB 메모리를 사용하고 있다. 그리고 Swap 메모리로는 8GB를 사용하고 있다. 그래서 Swap 메모리 + 물리 메모리 기준으로 메모리를 할당할 줄 알았다.
 
하지만 JVM은 힙 사이즈를 정할 때 물리적 메모리를 기준으로 결정한다. Java 8부터는 따로 JVM 힙 사이즈를 정해주지 않으면 기본 힙 사이즈는 시스템 물리적 메모리의 약 1/64로 설정되고, 최대 힙 사이즈는 약 1/4로 설정된다.
 

 
사진을 보면 현재 내 컴퓨터의 메모리 16GB에서 최대 힙 사이즈는 약 1/4인 4GB를 지정하고, 최소 힙은 약 1/64인 250MB를 할당한 것을 볼 수 있다. 그렇다면 서버가 실행되고 있는 EC2는 기본 메모리가 1GB이니 기본적으로 물리 메모리의 약 1/64인 16MB를 사용하고 있고, 최대 1/4인 256MB를 힙 메모리로 사용 중인 것이다.
 

 
더군다나 현재 메모리 사용량이 28.1%인데도 남은 메모리가 44.4MB밖에 안됐다. 그래서 Batch 작업을 돌면서 약 300MB까지 메모리 사용량이 확 늘어버리니 이를 감당하지 못해 계속 OutOfMemory가 뜨게 된 것 같다. 그래서 먼저 JVM의 기본 힙 사이즈를 늘려보려고 했다. Swap 메모리를 사용 중이기에 Swap 메모리를 기준으로 JVM 힙 사이즈 크기를 늘리려고 했으나 Swap 메모리를 기준으로 하면 생길 수 있는 문제가 상당히 많았다.
 
가장 크게 생각한 문제는 보조 메모리를 주 메모리처럼 사용한다는 점이다. 주 메모리보다 10배 이상 느리기 때문에 전체 요청-응답 과정에 문제가 생길 것 같았다. 그리고, Swap 메모리는 주 메모리에서 사용되지 않는 데이터를 일시적으로 저장하기 위한 것이기에 메모리가 부족한 경우에 활성된다. 그래서 JVM 힙 메모리 외에 다른 메모리 공간들이 언제 사용되지 않는지 또는 얼마나 사용되지 않는지 추측하기가 어려웠다. 그래서 당장 힙 메모리를 무작정 늘리는 것은 해결방안이 아니라 생각했다.
 

 
OutOfMemoryError는 단순히 메모리가 부족해서만 발생하는 것이 아니라, GC가 불필요한 객체를 회수하지 못한 상태에서 메모리 요청이 들어올 때 발생한다. 위의 사진 속 Batch 작업에서 보았듯이 지속적으로 메모리가 요동치는 모습을 볼 수 있다. 이러한 그래프가 4-5시간 가량 지속되는 것을 보면 GC의 동작에서도 힌트를 얻을 수 있을 것 같다. 그래서 운영 환경으로 구성하여 실험을 해보면 좋을 것 같다고 생각했다. 근데 아쉽게도 이미 서버의 프로세서를 업그레이드 한 상태였다.
 
처음엔 Test용 객체들을 만들어 EC2에 띄워보려고 했으나, 데이터베이스를 인 메모리로 하게 되면 해당 데이터베이스로 인해 정확한 측정이 불가했다. 데이터베이스를 그럼 분리한다고 해도 이를 위해 운영 서버 DB를 연결하기엔 너무 위험했다. 그래서 EC2와 동일한 환경에서 갑작스레 많은 데이터들이 들어오면 어떻게 되는지 정도만 분석해보기로 했다. 사용한 코드들은 다음과 같다.
 

public class BatchSimulator {
    public static void main(String[] args) throws Exception {
        List<int[]> allocations = new ArrayList<>();
        int counter = 0;
        while (true) {
            // 117KB 크기의 int 배열 계속 생성
            allocations.add(new int[29952]);
            counter++;

            if (counter % 50 == 0) {
                System.out.println("Allocated ~" + (counter) + " MB so far...");
            }
        }
    }
}

FROM openjdk:21-jdk

WORKDIR /app
COPY BatchSimulator.java .

RUN javac BatchSimulator.java

ENV JAVA_OPTS="-Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags"

# JVM 힙 제한: 실제 t4g.micro 기본값에 맞춤
CMD java $JAVA_OPTS BatchSimulator

#!/bin/bash
docker build -t oom-test .

docker run -it --rm \\
  --cpus="2" \\
  --memory="1g" \\
  --memory-swap="8g" \\
  -v ~/gc-logs:/logs \\
  oom-test

 
간단한 코드이다. 글의 상단에서 알게 된 MongoDB의 평균 코스 크기인 117KB 크기로 계속해서 데이터를 생성하여 리스트에 저장한다. 그리고 이를 실행하는 도커는 t4g.micro의 스펙과 똑같이 구성했다. 메모리는 1GB이며 스왑 메모리를 8GB로 설정했다. 그리고 CPU는 2코어만 사용한다.
 
해당 프로그램을 기반으로 실행해보면 초기 실행 직후 Young Generation에서의 Minor GC가 여러차례 발생한 것을 확인할 수 있었다. 이는 주로 Eden 영역에서 새로운 객체를 할당할 공간이 부족할 때 발생한다.
 

GC(0) Pause Young (Allocation Failure) 5M->5M(15M) 3.961ms
GC(1) Pause Young (Allocation Failure) 9M->9M(15M) 6.885ms
GC(2) Pause Young (Allocation Failure) 13M->13M(17M) 2.866ms

 
또한, 자바 코드를 보면 리스트가 계속해서 생성되는 객체를 참조하고 있기에 GC가 이를 정리하지 못하고 Eden과 Survivor 영역이 빠르게 차면서 Tenured 영역(Old Generation)으로 객체가 승격되는 과정이 반복되었다.
 

GC(1) Tenured: 4700K(10944K)->8956K(10944K)
GC(4) Tenured: 13237K(22064K)->20843K(22064K)

 
그 후 Minor GC가 계속 실패하자 JVM은 Full GC를 수행하며 Tenured 영역의 메모리를 회수하는 과정을 반복했다. 특히나 마지막 Full GC에서는 Tenured 영역이 거의 99% 사용됨과 동시에 Eden 공간 역시 가득찬 상태를 유지했다.
 

GC(3) Pause Full (Allocation Failure) 13M->13M(31M) 8.072ms
GC(6) Pause Full (Allocation Failure) 29M->29M(70M) 7.110ms
GC(12) Pause Full (Allocation Failure) 153M->153M(247M) 14.388ms

def new generation total 78656K, used 78611K
tenured generation total 174784K, used 174726K

 
종합적으로 정리하자면, 물리적으로 메모리가 부족한 상황이다. 물리 메모리의 크기가 작기 때문에 힙 사이즈의 크기도 작을 수 밖에 없었고 이를 늘려준다해도 남아있는 물리 메모리 공간이 거의 없기 때문에 늘리기 어려웠다. 게다가 지금의 예제처럼 코스 파일들을 계속해서 불러오는데, 힙 사이즈가 작다보니 Eden 영역과 Tenured 영역이 계속해서 가득찬다. 결국 이 때문에 Full GC가 반복 실행되면서 OutOfMemory가 지속적으로 발생하게 되었다는 점을 추측할 수 있을 것 같다.
 
그래서 우리 팀은 현재 EC2의 물리 메모리를 늘리기로 했다. 그래서 기존에 t4g.micro를 사용하고 있었지만, 이를 t4g.small로 증가했다. 물리 메모리는 2GB이기에 이제 힙 메모리는 기본적으로 32MB를 사용하고 최대 힙 메모리는 약 536MB가 되었다. 기존에 문제가 생기던 메모리 수준이 300MB인 점을 감안했을 때 따로 힙 사이즈를 조정하지 않아도 될거라 생각한다. 물론 사용자가 많아진다면 이를 다시 고려해볼 것이다.

+) 2025.10.24

해당 문제를 해소하고 Batch Job 코드를 다시 확인하면서, 메모리 누수의 문제는 없었지만 구글 드라이브에서 파일들을 읽어오는 과정이 문제점이 될 수 있는 것을 파악했다. 그 문제는 Batch Job에서 구글 드라이브로부터 코스 데이터를 읽어올 때, 모든 파일을 한 번에 메모리에 로드하는 방식을 사용하고 있던 것이다.

이 문제를 해결하기 위해 구글 드라이브 파일 읽기 로직에 페이징(paging)을 적용했다. 기존에는 모든 파일 목록을 한 번에 가져와서 처리했다면, 이제는 일정 개수(10개)씩 나누어서 순차적으로 읽어오도록 변경했다. 이를 통해 한 번에 메모리에 로드되는 데이터의 양을 제한할 수 있었다.

 

 

페이징 적용 후 배치 작업 중 메모리 사용량을 모니터링한 결과, 기존에 300MB 이상까지 치솟던 메모리 사용량이 120MB 내외로 안정화되는 것을 확인할 수 있었다. 또한 각 배치 처리가 끝나면 해당 객체들이 GC의 대상이 되어 메모리를 회수할 수 있는 여유가 생겼다. 그리고 Full GC의 발생 빈도도 크게 줄어들어 배치 작업의 전체 수행 시간도 개선되었다. 이러한 페이징 처리 방식은 인프라 스펙 업그레이드와 함께 시너지를 내어 OutOfMemory 문제를 상당 부분 해소할 수 있었다.