[리눅스 중급 #5] 스왑(Swap)의 늪에서 탈출하라: swappiness 조절을 통한 I/O 대기 시간(I/O Wait) 혁신 전략

English Abstract: Escaping the Swap Trap—Optimizing I/O Wait via swappiness Tuning

The fifth installment of the Linux Intermediate series addresses the critical balance between physical RAM and swap space. By default, the Linux kernel's vm.swappiness parameter is often set to a value (usually 60) that can trigger premature swapping, leading to significant "I/O Wait" and system latency in memory-intensive applications. This article provides a deep dive into the kernel's memory reclamation logic, comparing RAM to a high-speed executive desk and Swap to a distant warehouse. Through professional case studies in automated video processing, we explore how lowering the swappiness value can preserve the filesystem cache and enhance overall throughput. The post also features a technical "Mise-en-scène" analysis of memory telemetry and a unique UML mapping of the film 'Harbin' to memory management roles. This guide is a high-value resource for engineers aiming to eliminate performance bottlenecks and achieve architectural excellence.

1. 서론: 당신의 서버가 '느릿느릿' 걷는 이유, 범인은 스와핑(Swapping)

리눅스 서버를 운영하다 보면 분명 CPU 사용률은 낮은데 시스템 응답이 눈에 띄게 느려지는 현상을 겪곤 합니다. 이때 top이나 htop을 열어보면 어김없이 'wa(I/O Wait)' 수치가 치솟아 있는 것을 발견하게 되죠. 이는 프로세스가 연산을 처리하는 시간보다 데이터를 디스크에서 읽고 쓰는 데 더 많은 시간을 허비하고 있다는 뜻입니다.

오늘 우리가 다룰 **vm.swappiness**는 커널이 물리 메모리(RAM)가 부족할 때 얼마나 공격적으로 데이터를 디스크의 스왑 영역으로 옮길지를 결정하는 매개변수입니다. 비유하자면, 서류를 바로 볼 수 있는 **'책상(RAM)'**이 조금만 차올라도 중요도가 낮은 서류를 저 멀리 떨어진 **'창고(Swap)'**로 미리 옮겨버리는 관리자의 성향과 같습니다. 창고로 가는 길은 멀고 험하기에(Disk I/O), 이 빈도가 잦아지면 전체 업무 속도는 급격히 하락합니다.

2. 경험담: 렌더링 서버의 '동맥경화'와 아연 한 알의 위로

유튜브 쇼츠 자동화 시스템의 핵심인 영상 렌더링 서버는 엄청난 양의 RAM을 소모합니다. 어느 날, 32GB RAM이 장착된 서버에서 렌더링 작업이 90% 정도 진행되었을 때 갑자기 시스템 전체가 프리징에 가까운 상태가 되었습니다. 원인은 기본값인 60으로 설정된 swappiness였습니다. 커널은 여유 메모리가 아직 남아있음에도 불구하고, 나중을 대비해 파일 시스템 캐시를 지키고자 실행 중인 렌더링 프로세스의 데이터를 스왑으로 밀어내기 시작한 것입니다.

작업은 지연되었고 제 만성 위염은 다시 고개를 들었습니다. 타 들어가는 속을 달래려 아연과 마그네슘을 챙겨 먹으며 터미널 앞에 앉았을 때, 제 눈에 들어온 수만 줄의 I/O Wait 로그는 마치 정갈한 한정식 차림에 누군가 실수로 쏟아버린 단무지 국물처럼 불쾌한 불협화음이었습니다. 저는 즉시 swappiness를 10으로 낮추었습니다. 커널에게 "창고로 가지 말고, 최대한 책상 위에서 해결해!"라고 명령한 것이죠. 설정을 바꾸자마자 디스크 비명 소리가 멈추고 렌더링 속도가 2배 이상 빨라졌습니다.

3. '미장센'으로 분석한 메모리 텔레메트리의 기술적 분석

중급 엔지니어에게 모니터링 화면은 단순한 데이터의 나열이 아니라, 시스템의 심리 상태를 보여주는 **미장센(Mise-en-scène)**입니다.

1. 유동적 곡선과 수직적 바(Bar): 속도의 시각화

• 기술적 분석: btop이나 Grafana 대시보드에서 RAM 사용량은 부드러운 곡선을 그리며 상승하지만, 스왑이 시작되는 순간 I/O 차트에는 수직적인 **스파이크(Spike)**가 발생합니다. 이 부드러움과 날카로움의 대비는 시스템이 '순항' 중인지 '고전' 중인지 시각적으로 프레이밍(Framing)합니다. RAM의 밝은 시안(Cyan) 색상과 스왑의 어두운 마젠타(Magenta) 색상 대비는 데이터의 위치가 '생존의 영역'에 있는지 '지연의 늪'에 있는지 명확히 보여줍니다.

2. 여백의 미와 밀도의 공포: 캐시(Cache)의 구도

• 기술적 분석: 메모리 맵에서 Buff/Cache 영역이 넓게 차지하는 구도는 시스템이 안정적임을 시각화합니다. 반면, 이 영역이 좁아지고 Used 영역이 화면을 가득 채우는 밀집된 구도는 영화 '하빈'의 폐쇄된 공간이 주는 긴장감처럼 엔지니어에게 곧 닥칠 스와핑의 공포를 예고합니다.

4. Action: swappiness 최적화 및 영구 적용 (Intermediate Drill)

중급자라면 현재 상태를 확인하고, 서비스 중단 없이 값을 변경한 뒤 이를 영구화하는 일련의 과정을 능숙하게 처리해야 합니다.

1. 현재 값 확인 및 실시간 변경

리눅스 서버의 기본값은 보통 60입니다. 이를 10으로 낮추어 RAM 활용도를 극대화해 보겠습니다.

Bash

 

# 현재 swappiness 값 확인
cat /proc/sys/vm/swappiness
# 결과: 60

# 실시간으로 10으로 변경 (재부팅 전까지 유효)
sudo sysctl -w vm.swappiness=10

2. 영구 적용 (/etc/sysctl.conf)

재부팅 후에도 값이 유지되도록 설정 파일에 박제합니다.

Bash

 

echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
# 설정 즉시 반영
sudo sysctl -p

5. 영화 '하빈' 인물 관계의 IT적 재해석: UML 클래스 다이어그램

영화 **'하빈'**의 독립군들이 거사를 치르기 위해 자원을 배분하는 과정을 메모리 관리 아키텍처로 해석하여 UML 클래스 다이어그램으로 형상화했습니다.

• Strategist (안중근) 클래스: 커널 스케줄러와 메모리 관리자 역할을 수행합니다. swappiness 파라미터를 통해 자원 배치 전략을 결정합니다.
• RapidResource (독립군 동지들) 클래스: RAM을 상징합니다. 현장에서 즉각적으로 반응하며 속도가 매우 빠르지만, 용량(인원)에 한계가 있습니다.
• RemoteBase (해외 근거지) 클래스: Swap 영역을 상징합니다. 많은 물자를 보관할 수 있지만, 현장까지 전달되는 데 시간이 오래 걸립니다.
• Policy (swappiness) 인터페이스: Strategist가 RapidResource가 조금 부족해졌을 때, 즉시 RemoteBase를 호출할지 아니면 끝까지 현장에서 버틸지를 결정하는 수치화된 의지입니다.

6. After: 창고가 아닌 책상에서 끝내는 압도적 퍼포먼스

swappiness 조절 이후, 제 서버 인프라는 다음과 같은 극적인 변화를 맞이했습니다.

• I/O Wait의 소멸: 디스크가 쓸데없이 바빠지는 일이 사라지니 전체 시스템의 지연 시간(Latency)이 획기적으로 줄어들었습니다.
• 데이터베이스 성능 향상: 인메모리 DB나 캐시 서버들이 RAM을 온전히 점유하게 되어 쿼리 응답 속도가 일정하게 유지됩니다.
• 엔지니어의 평화: 시스템의 불확실성이 제거되니 위염 증세가 완화되었고, 더 이상 새벽에 스왑 경고 알람 때문에 깰 일이 없어졌습니다.

7. Swappiness 수치별 기술적 특징 비교

설정값	커널의 성향	적합한 환경	성능적 비유
0 ~ 1	거의 스왑을 쓰지 않음	고성능 DB 서버, 실시간 연산	"모든 서류는 책상 위에만 둬라"
10 ~ 20	중급 엔지니어 권장값	일반적인 웹/애플리케이션 서버	"정말 자리가 없을 때만 창고에 가라"
60	기본값 (데스크탑 위주)	일반 사무용 PC, 저사양 랩탑	"창고를 미리미리 활용해라"
100	매우 공격적인 스와핑	거의 사용되지 않음 (특수 목적)	"책상을 비우는 게 최우선이다"

8. 마치며: 커널의 '의지'를 조율하는 설계자가 되십시오

리눅스 중급 과정의 다섯 번째 단계를 마쳤습니다. swappiness를 이해한다는 것은 시스템의 하드웨어 한계를 소프트웨어적 지능으로 극복하는 법을 배웠음을 의미합니다. 무조건 RAM을 많이 증설하는 것이 능사는 아닙니다. 주어진 자원을 얼마나 영리하게 배분하느냐가 마스터의 실력을 증명합니다. 이제 여러분의 서버는 스왑의 늪에서 벗어나 더욱 가볍고 빠르게 달릴 준비가 되었습니다.

오늘의 중급 인사이트: "하드웨어는 몸이고, 커널 파라미터는 근육의 움직임을 조절하는 신경계다. 훌륭한 아키텍처는 신경계를 다스리는 데서 시작된다."

9. 출처 및 참고 자료 (Sources & References)

1. Linux Kernel Admin-Guide (vm/swappiness): https://www.kernel.org/doc/Documentation/sysctl/vm.txt
2. Red Hat Performance Tuning Guide: 리눅스 스왑 성능 최적화 사례 연구
3. Brendan Gregg's Blog (I/O Analysis): http://www.brendangregg.com/linuxperf.html
4. POSIX.1-2017 Memory Management Standards: 가상 메모리 관리 체계에 대한 표준 정의