리눅스 SWAP 확인부터 스왑 메모리 증설

리눅스 SWAP 확인부터 스왑 메모리 증설까지

서버에서 메모리가 부족해지면 커널이 디스크 기반의 SWAP을 사용하면서 응답이 급격히 느려질 수 있습니다.
이 문서는 현재 SWAP 상태 확인부터 원인 점검, 그리고 스왑 파일/스왑 파티션 증설 및 영구 적용까지 한 흐름으로 정리합니다.

개요

SWAP을 늘리는 건 “메모리 부족 상황에서 서버가 죽는 것”을 막는 완충 장치입니다.
다만 SWAP이 많다고 성능이 좋아지는 건 아니고, SWAP 사용이 잦다면 메모리 누수/캐시 정책/프로세스 튜닝이 우선입니다.
실제 사용 시에는 “증설”과 함께 “왜 스왑을 쓰는지”를 같이 잡아야 재발을 줄일 수 있습니다.

운영 환경에서는
스왑 작업은 I/O 부하와 리스크가 있으니, 변경 윈도우(점검 시간) 확보 후 진행하는 게 안전합니다.
특히 swapoff는 메모리 여유가 없으면 실패하거나 서버가 더 불안정해질 수 있습니다.

환경

• 대상 OS: Linux (RHEL/CentOS/Rocky/Alma/Ubuntu/Debian 계열 공통)
• 필요 권한: root 또는 sudo
• 필수 명령: free, swapon, vmstat, top/ps, df, fallocate/dd, mkswap

증상

• 서버가 갑자기 느려지고 load가 오르며 디스크 I/O가 증가함
• free에서 Swap 사용량이 꾸준히 증가하거나 이미 많이 사용 중
• OOM(Out Of Memory) 발생 또는 서비스 프로세스가 비정상 종료

1차 점검

1) SWAP 사용량 빠르게 확인

free -h

Swap의 used가 크고 지속적으로 늘면, 메모리 압박이 실제로 발생 중일 가능성이 높습니다.

2) SWAP 장치/파일 목록 확인

swapon --show

3) SWAP 인/아웃(활동) 확인

vmstat 1 5

해석 포인트
si(swap in), so(swap out)가 계속 0이 아니면 스왑이 “활발히” 사용 중입니다.
이 상태에서 체감 성능 저하가 같이 나오면, 스왑 증설만으로 해결되지 않을 수 있습니다.

4) 메모리 많이 쓰는 프로세스 확인

top

또는 RSS 기준으로 상위 프로세스를 뽑으면 빠릅니다.

ps aux --sort=-rss | head -n 15

5) 디스크 여유 확인(스왑 파일 방식이면 필수)

df -h

심화 분석

1) 스왑이 많은데 실제 메모리가 여유처럼 보일 때

가능한 원인
파일 캐시(페이지캐시)와 애플리케이션 메모리 사용이 섞여 보이는 케이스가 많습니다.
커널은 캐시를 “회수 가능”으로 보지만, 급격한 메모리 압박이 발생하면 스왑으로 밀어낼 수 있습니다.
따라서 단순 free 값만 보지 말고, vmstat와 프로세스 RSS 추이를 같이 보세요.

2) 스왑 사용이 늘어나는 패턴 점검

• 배치/스케줄러 시간대에만 증가하는지
• 특정 서비스 재기동 이후부터 꾸준히 증가하는지(메모리 누수 의심)
• 컨테이너/자바 프로세스 힙 설정이 과한지

3) 커널 스왑 성향(swappiness) 확인

cat /proc/sys/vm/swappiness

참고
값이 높을수록 스왑을 더 적극적으로 사용합니다.
“무작정 0으로”는 권장하지 않고, 운영 환경에서는 10~30 같은 보수적 값으로 조정하는 경우가 많습니다.

복구

스왑 증설은 크게 스왑 파일(swapfile) 방식과 스왑 파티션 방식이 있습니다.
빠르고 운영에 부담이 적은 건 대체로 스왑 파일 방식입니다.

방식	장점	주의
스왑 파일	생성/증설이 빠름, 재파티셔닝 불필요	디스크 여유 필요, 파일 권한/마운트 정책 확인
스왑 파티션	전통적 방식, 일관된 성능/관리	파티션 작업 리스크, 다운타임/재부팅 필요할 수 있음

A) 스왑 파일로 증설(권장 흐름)

예시: 8GB 스왑 파일 추가
경로는 관례적으로 /swapfile 또는 /swapfile2 등을 사용합니다.

1) 스왑 파일 생성

# fallocate 가능할 때(빠름)
sudo fallocate -l 8G /swapfile

# fallocate가 어렵거나 파일시스템 정책상 문제 시(dd)
# sudo dd if=/dev/zero of=/swapfile bs=1M count=8192 status=progress

2) 권한 설정(필수)

sudo chmod 600 /swapfile

3) 스왑 영역 생성

sudo mkswap /swapfile

4) 스왑 활성화

sudo swapon /swapfile

5) 적용 확인

swapon --show
free -h

6) 재부팅 후에도 유지(영구 적용)

# /etc/fstab에 한 줄 추가
# (편집 전 백업 권장)
sudo cp -a /etc/fstab /etc/fstab.bak

# 편집기로 열어서 아래 라인 추가
/swapfile none swap sw 0 0

# fstab 문법 점검 겸 마운트 시뮬레이션(시스템에 따라 지원)
sudo mount -a

운영 팁
fstab 오타는 부팅 장애로 이어질 수 있으니, 백업 후 적용하는 게 안전합니다.
스왑 파일 경로를 바꿨다면, fstab도 반드시 일치해야 합니다.

B) 기존 스왑 파일을 “늘리는” 대신 새 파일 추가를 권장하는 이유

실무 권장
기존 파일을 resize하는 것보다, 새 swapfile을 추가하는 방식이 변경 리스크가 낮습니다.
필요 시 swapoff/swapfile 제거도 더 단순해집니다.

C) 스왑 파티션 증설(가능할 때만)

파티션 증설은 서버 구성에 따라 절차가 크게 달라집니다(LVM 여부/남은 디스크/볼륨 구조).
아래는 “이미 스왑 파티션이 있고 교체/추가”하는 형태의 기본 흐름만 정리합니다.

1) 현재 스왑 파티션 확인

lsblk
swapon --show

2) (가능한 경우) 새 스왑 파티션/볼륨 생성 후 활성화

# 새 파티션(예: /dev/sdb2)이 준비되었다는 가정
sudo mkswap /dev/sdb2
sudo swapon /dev/sdb2

3) 영구 적용(/etc/fstab)

sudo cp -a /etc/fstab /etc/fstab.bak

# UUID 기반 권장
sudo blkid /dev/sdb2

# /etc/fstab 예시(blkid로 확인한 UUID 사용)
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx none swap sw 0 0

D) “스왑을 비우고 싶을 때” 주의

중요
swapoff는 스왑에 있는 데이터를 RAM으로 되돌려야 하므로, 메모리 여유가 없으면 실패하거나 위험합니다.
운영 환경에서는 서비스 영향도를 충분히 고려하세요.

# 여유가 확실할 때만(선택)
sudo swapoff -a
sudo swapon -a

재발 방지

1) 스왑 증설과 함께 “원인”을 같이 잡기

• 메모리 누수 의심 시: 프로세스 RSS 추이/로그/배포 변경 이력 확인
• 자바/런타임: 힙/GC 설정이 물리 메모리 대비 과하지 않은지 점검
• 배치 작업: 병렬도/동시 실행 제한, 작업 분리

2) swappiness 조정(정책 기반)

# 일시 적용(재부팅 시 원복)
sudo sysctl vm.swappiness=20

# 영구 적용(배포 정책에 맞춰 관리)
# /etc/sysctl.conf 또는 /etc/sysctl.d/*.conf에 추가
vm.swappiness=20

sudo sysctl -p

3) 모니터링 기준

• vmstat의 si/so가 지속 발생하면 알람
• Swap used가 일정 임계치 이상이면 알람(예: 30%/50%)
• OOM 로그(dmesg, /var/log/messages, journalctl) 주기 점검

4) 운영 체크리스트

• 증설 전: 디스크 여유(df -h), I/O 부하, 변경 윈도우 확인
• 증설 후: swapon --show, free -h, fstab 영구 적용 확인
• 사후: 메모리 상위 프로세스/배치 시간대 분석으로 재발 요인 제거