Linux zswap·zram·swapfile, 메모리 압박을 같은 문제로 보지 않는 법

Linux에서 메모리가 부족할 때 swap을 크게 늘리는 것부터 시작하면 원인을 놓치기 쉬워요. 디스크에 페이징이 몰린 상황, RAM 안에 압축된 페이지를 보관하는 상황, 일반 swap 장치로 내보내는 상황은 서로 다른 경로이기 때문이에요. zswap은 swap으로 나갈 페이지를 RAM 안에서 먼저 압축하는 캐시이고, zram은 압축된 RAM 기반 블록 장치를 만들어요.[1][2]

세 구성요소의 역할부터 나눠요

zswap은 압축된 페이지를 저장하는 풀이 한도에 도달하면 backing swap 장치로 밀어낼 수 있어요.[1] 그래서 zswap만 켜고 실제 swap 장치가 없다고 생각하면 안 됩니다. zram은 페이지를 RAM 안에서 압축해 보관하는 장치라서 디스크 I/O를 줄일 수 있지만, 압축률이 낮은 데이터가 많으면 기대한 만큼 공간이 줄지 않을 수 있어요.[2]

현재 상태를 바꾸지 않고 읽는 순서

free -h
swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
cat /proc/swaps
cat /sys/module/zswap/parameters/enabled
cat /sys/block/zram0/mm_stat 2>/dev/null
cat /proc/pressure/memory

free -h에서 swap 사용량이 보인다는 사실만으로 디스크 병목이라고 결론내리면 안 돼요. zswap이 중간에서 페이지를 잡고 있을 수 있고, zram이 활성화돼 있으면 swap 장치의 이름과 실제 저장 위치가 다를 수 있습니다. swapon --show로 장치·파일·우선순위를 먼저 확인한 뒤, 같은 시각에 메모리 압박과 저장장치 지연을 기록해야 해요.[1][3]

zswap을 고를 조건

이미 안정적인 swapfile이나 파티션이 있고, 갑작스러운 메모리 압박에서 디스크 왕복을 조금 줄이고 싶다면 zswap을 검토할 수 있어요. 커널 문서가 설명하듯 zswap은 CPU 계산량을 써서 swap I/O를 줄이는 방식이에요.[1] CPU 여유가 적은 서버에서 모든 워크로드에 이득이라고 말할 수는 없습니다.

활성화 전후에는 같은 부하를 재현하면서 압축 풀의 사용량, eviction, CPU 사용률, swap 장치의 실제 I/O를 함께 비교하세요. zswap을 끈 뒤에도 압축 풀에 있던 페이지가 즉시 모두 RAM으로 돌아오는 것은 아니며, 문서상 swapoff가 저장된 페이지를 fault back할 수 있는 동작으로 설명돼 있어요.[1] 운영 중 무심코 swapoff를 실행하지 말고 여유 메모리와 복구 방법을 먼저 확보해야 합니다.

zram을 고를 조건

저장장치 접근이 느리거나, 작은 장치에서 메모리 압박을 조금 더 견디게 하고 싶다면 zram이 맞을 수 있어요. 커널 문서는 zram을 RAM 기반 블록 장치로 설명하고, mkswap과 swapon으로 swap으로 사용하는 예시를 보여 줍니다.[2]

sudo modprobe zram
sudo zramctl --find --size 4G
# 반환된 장치를 확인한 뒤에만 다음 단계를 진행해요.
sudo mkswap /dev/zram0
sudo swapon --priority 100 /dev/zram0

위 명령을 운영 서버에 그대로 적용하기보다 배포판의 zram 관리 서비스와 현재 swap 우선순위를 먼저 확인하세요. zram 크기를 RAM 전체에 가깝게 잡는다고 항상 안전해지는 것도 아니에요. 압축용 RAM과 CPU를 함께 소모하므로, 실제 압축률과 시스템 응답시간을 보면서 한도를 정해야 합니다.[1][2]

swapfile을 다시 만들 때의 함정

일반 swapfile은 가장 단순해 보여도 파일시스템 조건을 확인해야 해요. swapon(8) 문서는 hole이 있는 파일이나 Btrfs 같은 copy-on-write 파일시스템의 파일이 swapfile 구현과 충돌할 수 있다고 설명합니다.[3] 파일을 만든 뒤 바로 swapon하는 대신, 파일시스템과 배포판의 권장 생성 절차를 확인하세요.

findmnt -no TARGET,FSTYPE,OPTIONS /
sudo swapon --show
sudo journalctl -k -b | grep -Ei 'swap|zswap|zram|oom'

선택 기준과 되돌리기

• 디스크 I/O가 병목이면 zswap 전후의 압축·eviction·I/O를 비교하기
• 저장장치 지연이 큰 소형 시스템이면 zram의 압축률과 CPU 사용률을 기록하기
• 일반 swapfile을 추가할 때 파일시스템이 hole·copy-on-write 조건에 걸리지 않는지 확인하기
• 변경 전 swapon --show와 커널 로그를 저장해 되돌릴 기준 만들기
• 문제가 생기면 새 설정을 더 얹지 말고 마지막으로 안정적이었던 swap 우선순위로 복귀하기

메모리 압박은 swap 하나로 해결하는 문제가 아니에요. 프로세스별 사용량, cgroup 제한, 파일 캐시, 저장장치 지연을 따로 기록해야 합니다. 압축 계층을 추가했는데도 응답시간이 나빠졌다면 “메모리가 늘었다”가 아니라 CPU 압박과 I/O 경로가 어떻게 바뀌었는지부터 다시 보세요.[1]

관찰값으로 원인을 좁히는 예시

예를 들어 swapon --show의 USED가 계속 늘면서 저장장치 대기시간도 함께 커진다면 backing swap이 실제로 병목인지 확인할 차례예요. 반대로 swap 사용량은 있는데 zswap의 압축 풀 사용량이 늘고 디스크 쓰기가 크게 늘지 않는다면, 압축 캐시가 디스크 왕복을 흡수하고 있을 수 있습니다.[1] 이때는 zswap을 끄는 것보다 CPU 사용률과 압축 풀 한도를 먼저 비교해야 해요.

zram을 올린 뒤 시스템이 더 느려졌다면 mm_stat의 원본 페이지 수와 압축 후 저장량을 함께 보세요. 압축률이 낮은 데이터가 대부분이면 RAM을 쓰면서 CPU만 추가로 소비할 수 있습니다.[2] 한 번의 명령 출력보다 5분 이상 같은 작업을 반복한 증가분이 판단에 더 유용해요.

자주 생기는 오해

zswap과 zram을 동시에 켜도 될까요?

가능한 조합이더라도 자동으로 더 좋아지는 것은 아니에요. 두 압축 계층이 어느 순서로 동작하는지와 backing swap의 우선순위를 먼저 확인하고, 한 계층씩 켠 결과를 기준으로 비교하세요. 같은 페이지를 여러 번 압축하는 구조가 되는지까지 배포판의 설정과 커널 버전에서 확인해야 합니다.[1][2]

swapfile을 크게 만들면 OOM이 사라질까요?

OOM 발생 시점이 늦춰질 수는 있지만, 메모리 누수나 무제한 작업이 해결되는 것은 아니에요. 프로세스가 계속 페이지를 내보내면 응답시간이 먼저 나빠질 수 있으므로 프로세스 제한, cgroup, 작업량 상한을 함께 검토해야 합니다. swapfile 생성 전에 hole과 copy-on-write 조건을 확인하는 이유도 여기에 있어요.[3]

Linux 운영 관련 글은 컴퓨팅 가이드 모음에서도 이어서 확인할 수 있어요.

Sources

1. Linux Kernel documentation, zswap
2. Linux Kernel documentation, zram
3. Linux manual page, swapon(8)