DB 서버 메모리 부족 + Swap 사용: MariaDB 세션 누적 원인 분석

문제 인식

운영 중인 서비스의 DB 서버에서 메모리 사용량이 지속적으로 증가하고, Swap 메모리까지 사용하는 현상이 확인되었다.

Grafana 대시보드에서 메모리 사용량이 우상향하는 패턴이 관찰되었고, Swap 사용량도 함께 증가하고 있었다.

프로세스 분석

ps aux --sort=-%mem 명령어로 메모리 점유 프로세스를 확인한 결과, MariaDB 프로세스(mariadb -u root -p)가 20개 이상 실행 중이었다.

각 프로세스가 약 2.3~2.5%의 메모리를 점유하고 있었으며, 이들의 합산이 전체 메모리의 상당 부분을 차지하고 있었다.

DB 세션 확인

운영 DB

MariaDB [(none)]> SHOW PROCESSLIST;

운영 DB의 세션 수는 약 10개로, 모두 Sleep 상태였지만 정상 범위 내였다.

개발 DB

MariaDB [(none)]> SHOW FULL PROCESSLIST;

개발 DB의 세션 수는 40개 이상으로, 운영 대비 4배나 많았다. 대부분 Sleep 상태로 유휴 커넥션이 반환되지 않고 누적되어 있었다.

원인 분석: HikariCP 커넥션 풀 설정

애플리케이션의 DB 커넥션 풀 설정(HikariCP)을 확인했다.

hikari:
  pool-name: jpa-hikari-pool
  maximum-pool-size: 30
  minimum-idle: 10
  idle-timeout: 30000
  max-lifetime: 1800000
  connection-timeout: 30000
  auto-commit: false

운영 vs 개발 세션 수 차이 원인

• 운영: 트래픽이 일정하고, max-lifetime(30분) 경과 후 커넥션이 갱신되면서 minimum-idle(10개) 수준으로 유지
• 개발: 여러 개발자가 동시에 접속하거나 테스트를 반복하면서 커넥션이 maximum-pool-size(30개) 근처까지 생성되고, 유휴 상태로 누적

max-lifetime: 1800000(30분)이 지나면 커넥션이 갱신되면서 10개 수준으로 줄어드는 패턴이 확인되었다.

근본적 문제: 개발/운영 DB 동일 서버

포트를 분리하여 운영 DB와 개발 DB를 같은 서버에서 운영하고 있었지만, 개발 DB의 세션 누적이 운영 DB 서버의 메모리에 직접적인 영향을 주고 있었다.

이는 운영 안정성 관점에서 리스크가 큰 구조다.

대응 방향

1. 개발 DB 분리: 개발 DB를 별도 테스트 서버로 이전하여 운영 서버 메모리 영향 제거
2. 커넥션 풀 최적화: 개발 환경의 maximum-pool-size를 줄이고, idle-timeout을 더 짧게 설정
3. 모니터링 강화: DB 세션 수 추이를 지속적으로 모니터링하여 비정상 누적 조기 감지
4. Swap 사용량 알람: Swap 사용이 일정 수준을 넘으면 알람 발생하도록 설정

마무리

"메모리가 왜 차지?"에서 시작해 ps aux → SHOW PROCESSLIST → HikariCP 설정 확인 순서로 원인을 추적했다.

DB 서버의 메모리 문제는 단순히 쿼리 성능만의 문제가 아니라, 커넥션 풀 설정과 환경 분리 같은 인프라 구조적 요소에서 비롯될 수 있다는 점을 확인한 케이스였다.

배운 점

DB 서버의 메모리 문제를 쿼리 문제로만 보면 답이 안 나온다. 이번 원인은 애플리케이션의 커넥션 풀 설정이었고, 정작 증상은 DB 서버에서 나타났다. 원인과 증상이 다른 서버에 있는 경우를 그 뒤로 항상 염두에 두게 됐다.

추적 순서도 정리가 됐다. ps aux로 무엇이 메모리를 쓰는지, SHOW PROCESSLIST로 세션이 어디서 오는지, 마지막에 애플리케이션 설정을 본다. 이 순서는 EC2 메모리 사용률 지속 상승 분석에서도 거의 그대로 쓰였다.

Swap을 쓰기 시작하면 장애가 아니라 성능 저하로 먼저 나타나서 알아채기가 늦다. 그래서 Swap 사용량 자체를 알람 대상으로 올렸다.

이어 읽기

• EC2 메모리 사용률 82% → 86% 지속 상승, Java 프로세스 분석 및 대응: 같은 방식으로 추적한 애플리케이션 서버 사례
• Replica SQL 적용 밀릴 때: 병렬 복제 워커 큐 꽉 찬 문제 해결: 같은 DB 환경의 복제 병목