swap 2GB 를 켰더니 일어난 변화

우리가 운영하는 서버 중 하나는 RAM이 2GB 뿐이다. 저렴한 클라우드 인스턴스이고, 작은 팀이 사이드 프로젝트 겸 놀이터로 쓰는 곳이라 사양을 올릴 이유가 크지 않았다. 문제는 Node.js 서버, Java 런타임, MySQL, Redis가 함께 떠 있을 때 가끔 OOM killer가 프로세스를 죽인다는 점이었다.

무엇을 했나

설정은 간단했다. 2GB 파일을 /swapfile로 만들고 vm.swappiness=10을 /etc/sysctl.d/에 추가했다.

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

swappiness=10은 “물리 메모리가 90% 찰 때까지 swap을 거의 건드리지 말라”는 뜻이다. 값을 0으로 설정하면 swap을 아예 안 쓰는 게 아니라 극단적으로 늦추는 것이라는 점도 이번에 다시 확인했다.

실제로 달라진 것

OOM kill 빈도가 눈에 띄게 줄었다. 이전에는 주 1~2회 정도 dmesg에 oom-kill 로그가 남았는데, swap 적용 후 2주 동안 한 번도 발생하지 않았다.

응답 지연은 swap이 실제로 사용될 때 눈에 띄었다. vmstat 1 로 모니터링하면 si/so 컬럼에 swap 입출력이 보이는 순간 응답 p99가 평소보다 3~5배 느려졌다. swap은 죽음을 막는 안전망이지 성능 해결책이 아니라는 걸 다시 확인했다.

메모리 구성을 다시 들여다보게 됐다. Java 프로세스의 -Xmx 값을 실제 필요량보다 넉넉하게 잡아두었던 게 문제였다. 상한을 실측치 기준으로 낮추니 swap 사용 자체가 거의 사라졌다.

정리

swap을 켜는 것 자체는 5분짜리 작업이다. 그런데 그게 계기가 되어 각 프로세스의 실제 메모리 사용량을 처음으로 꼼꼼히 들여다봤고, 불필요하게 잡아 둔 여유 메모리를 회수했다. 작은 서버일수록 리소스 경쟁이 선명하게 드러난다. swap은 그 경쟁을 가시화하는 좋은 도구였다.

서버 사양을 올리기 전에 현재 메모리가 어디로 가는지 먼저 확인하는 것, 우리가 이번에 배운 순서였다.

— by slecs