MySQL/MariaDB 서버 메모리가 계속 늘어난다면? (원인 분석부터 Swap 해결까지)
서버 운영 중 DB 메모리 점유율이 야금야금 올라가면 가슴이 철렁하곤 합니다. 오늘은 4GB RAM 환경에서 MySQL(MariaDB)과 Node.js를 운영하며 겪을 수 있는 메모리 이슈와 그 해결 과정을 완벽히 정리해 보겠습니다.
1. DB 메모리는 왜 계속 늘어날까?
MySQL과 MariaDB는 구조적으로 메모리를 캐시로 활용하도록 설계되어 있습니다.
- 정상적인 워밍업: DB가 켜진 직후보다 운영될수록 자주 조회되는 데이터를 메모리(InnoDB Buffer Pool)에 쌓아두기 때문에 점유율이 서서히 증가합니다.
- 범인은 누구?: 만약 DB 설정값(innodb_buffer_pool_size)이 고정되어 있는데도 메모리가 계속 오른다면, 함께 구동 중인 **Node.js 같은 어플리케이션의 메모리 누수(Leak)**를 의심해야 합니다.
2. 실전 조치 1: 부족한 메모리 보완 (Swap 설정)
메모리가 80%를 넘어가면 리눅스는 OOM(Out Of Memory) Killer를 작동시켜 DB를 강제 종료할 수 있습니다. 이를 방지하기 위한 **'안전벨트'**가 바로 Swap입니다.
[Swap 파일 2GB 생성 및 활성화 가이드]
# 1. 스왑 파일 생성
sudo fallocate -l 2G /swapfile
# 2. 권한 및 포맷 설정
sudo chmod 600 /swapfile
sudo mkswap /swapfile
# 3. 스왑 활성화
sudo swapon /swapfile
# 4. 부팅 시 자동 적용을 위해 /etc/fstab에 등록
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# 5. 활성화 확인
free -h
Tip: 스왑을 활성화하면 사용하지 않는 메모리를 디스크로 옮겨 실제 RAM 사용량을 낮추는 효과가 있습니다.
3. 실전 조치 2: MariaDB 성능 최적화
기본 설정값인 128MB는 4GB 서버에서 너무 작습니다. DB 성능을 위해 이를 512MB로 늘려주는 것이 좋습니다.
[설정 파일(my.cnf) 수정]
[mysqld]
# 128MB에서 512MB로 상향 (조회 성능 대폭 향상)
innodb_buffer_pool_size = 512M
- 이점: 디스크 I/O가 줄어들어 쿼리 속도가 빨라지고 CPU 부하가 감소합니다.
4. 운영이 너무 힘들다면? AWS RDS라는 대안
직접 서버를 관리하는 것이 부담스럽다면 AWS RDS(Managed 서비스)가 훌륭한 대안이 됩니다.
| 장점 | 설명 |
| 자동 관리 | 패치, 업데이트, 백업을 AWS가 알아서 처리 |
| 고가용성 | DB 장애 시 자동으로 복제본 DB로 전환 (Failover) |
| 편의성 | 인스턴스 사양 변경(RAM 증설)이 클릭 몇 번으로 가능 |
결론: 비용은 EC2 직접 설치보다 약 1.5~2배 비싸지만, 관리 포인트와 장애 복구 스트레스를 고려하면 상용 서비스에서는 RDS가 합리적입니다.
마치며
서버 점유율이 70~80%라고 해서 무조건 위험한 것은 아닙니다.
Swap이라는 안전장치를 마련하고, 어플리케이션(Node.js) 재시작 주기를 관리하며, DB 캐시 규모를 최적화한다면 저사양 서버에서도 충분히 안정적인 서비스를 운영할 수 있습니다.
반응형
'IT관련 > MariaDB' 카테고리의 다른 글
| [MySQL] DOUBLE vs DECIMAL 차이점 완벽 정리 (어떤 타입을 써야 할까?) (0) | 2026.01.21 |
|---|---|
| 외부에서는 ip로 연결이 되는데 자신의 서버에서 ip로 연결이 안될때. (0) | 2025.04.17 |