CI 빌드의 메모리 부족 문제를 RSS 모니터링으로 가시화해 Gradle 및 Kotlin 프로세스 메모리 분배를 최적화

Context

CI 에이전트에서 Gradle 힙 크기를 16GB로 설정해도 32GB 메모리 머신에서 OOM 에러가 발생하는 문제가 있었다. Gradle 힙 외에도 Metaspace, Code Cache, Thread Stacks, Direct Buffers, GC Native Memory 등이 RSS(Resident Set Size)에 포함되며, Kotlin Daemon, Test JVM, Lint, R8 등 여러 JVM 프로세스가 동시에 실행되어 총 메모리 압박을 유발한다. OOM 발생 시 Gradle 프로세스가 즉시 종료되어 진단 데이터를 수집할 수 없는 문제도 있었다.

Technical Solution

• RSS 모니터링 도구 구축: ps -o rss= -p "$PID"를 이용해 실시간으로 각 JVM 프로세스의 물리 메모리 사용량을 초 단위로 수집
• 별도 모니터링 프로세스 실행: Gradle 동작 중 힙 사용량, 힙 용량, RSS, 누적 GC 시간을 시간 경과에 따라 기록
• 원격 모니터링 모드 추가: Firebase 데이터베이스에 데이터를 실시간으로 발행해 빌드 실패 또는 중단 시에도 진단 데이터 보존
• 시각화 및 비교 기능 제공: GitHub Actions용 Process Watcher 액션 개발으로 RSS 그래프, 힙 사용 추이, GC 동작을 한눈에 비교 분석
• 메모리 분배 실험: 서로 다른 Gradle 및 Kotlin 프로세스 메모리 조합을 실행하고 RSS 압박 및 완료 여부를 비교해 안정적 구성 도출

Impact

• Kotlin 버전 미정렬 시나리오에서 첫 번째 Kotlin 프로세스가 429 MiB 힙 사용에도 8.4%의 총 RSS 메모리 차지
• 메모리 제한이 있는 GitHub Actions 무료 러너에서 해당 프로세스가 약 4%의 가용 메모리를 소비
• 타임아웃 시나리오에서 Kotlin 프로세스 피크 RSS가 6962.0 MB에 도달
• 최종 최적화된 구성: Gradle 7GB + Kotlin 3GB로 설정하면 이전의 OOM/타임아웃 발생 조합보다 안정적 실행 가능

Key Takeaway

CI 빌드의 메모리 문제 해결은 힙 크기 설정만으로 부족하며, RSS를 포함한 실시간 메모리 압박 추이를 시각화해야 정확한 진단과 설정이 가능하다. 특히 여러 JVM 프로세스가 협력하는 환경에서 각 프로세스의 메모리 분배 비율을 체계적으로 측정하고 비교하는 것이 타임아웃과 OOM을 예방하는 핵심이다.