조회수: 0

리눅스 커널은 물리 메모리와 스왑 공간을 함께 사용해 프로세스를 관리한다. 이때 어떤 페이지를 먼저 내보내고 어떤 페이지를 끝까지 램에 유지할지는 페이지 리클레임 알고리즘이 담당한다.
vm swappiness는 이 알고리즘이 파일 캐시와 익명 메모리 페이지를 얼마나 공격적으로 스왑으로 내보낼지에 대한 선호도를 숫자로 표현한 값이다.

일반적으로 vm swappiness는 0에서 100 사이 값을 가지며, 값이 클수록 메모리가 여유 있을 때도 스왑을 좀 더 적극적으로 사용하는 경향을 보인다. 값이 작을수록 스왑 진입을 최대한 미루고 램을 끝까지 사용하려는 쪽으로 동작한다.

많은 배포판에서 기본값은 60으로 설정되어 있다. 이 값은 데스크톱과 서버를 모두 어느 정도 무난하게 커버할 수 있는 절충값이지만, 실제 환경에 따라 조정할 여지가 충분히 존재한다.

vm swappiness가 실제로 영향을 미치는 부분

파일 캐시와 익명 메모리의 균형

커널이 메모리를 회수해야 할 때 주로 두 가지를 놓고 저울질한다.

• 파일 캐시
• 프로세스의 익명 메모리 페이지

파일 캐시는 디스크에서 읽은 내용을 램에 유지해 재사용 속도를 높이는 역할을 하고, 익명 메모리는 힙이나 스택처럼 디스크에 직접 대응되는 파일이 없는 영역이다.

vm swappiness 값이 높으면 커널은 파일 캐시를 더 오래 보존하고 익명 메모리를 좀 더 빨리 스왑으로 내보내려는 경향을 보인다. 반대로 값이 낮으면 프로세스 메모리를 램에 더 오래 붙잡고, 파일 캐시를 먼저 줄이는 방향으로 움직인다.

이 차이가 가져오는 실제 효과는 워크로드에 따라 크게 달라진다. 디스크 기반 I O가 많은 서버라면 파일 캐시를 최대한 살려야 성능이 나오고, 여러 데스크톱 애플리케이션을 동시에 띄워두는 환경이라면 사용자 체감 지연을 줄이기 위해 익명 메모리를 램에 오래 두고 싶을 수 있다.

인터랙티브 지연과 체감 성능

데스크톱이나 개발용 워크스테이션에서 swappiness가 높은 경우, 한동안 사용하지 않은 애플리케이션의 메모리가 스왑으로 밀려나 있다가 다시 포그라운드로 가져올 때 눈에 띄는 지연이 발생할 수 있다.

예를 들어 브라우저와 IDE, 몇 개의 터미널을 동시에 열어 두고 메모리 사용량이 높은 작업을 돌리면, 잠시 사용하지 않던 브라우저 탭이 다시 활성화될 때 디스크에서 스왑 인 작업이 발생하면서 화면이 멈춘 듯 보이는 현상이 나타난다.

반대로 swappiness를 낮추면 이런 지연은 줄어드는 대신, 파일 캐시가 부족해져 디스크에서 자주 읽는 파일의 I O 지연이 늘어날 수 있다. 결국 어느 쪽 지연을 더 예민하게 느끼는 환경인지에 따라 적정값이 달라진다.

서버 환경에서의 영향

서버에서는 인터랙티브 응답성보다 전체 처리량과 안정성이 우선인 경우가 많다. 특히 다음과 같은 유형의 서버에서 swappiness 튜닝이 자주 논의된다.

• 데이터베이스 서버
• 웹 애플리케이션 서버
• 캐시 서버

데이터베이스의 경우 프로세스 메모리뿐 아니라 OS 파일 캐시도 성능에 크게 기여한다. 데이터베이스 자체가 버퍼 풀을 사용하더라도, WAL 로그나 기타 파일 접근은 여전히 파일 캐시의 영향을 받는다.
이 때문에 많은 운영 사례에서 swappiness를 기본값보다 낮추고, 아예 1 근처까지 줄여 스왑 사용을 최소화하는 선택을 하기도 한다.

다만 스왑을 완전히 배제하면 OOM 킬러가 더 자주 발동할 수 있다. 어느 정도의 스왑은 메모리 압박이 심해졌을 때 시스템이 바로 프로세스를 강제 종료하지 않고 완만하게 버틸 수 있는 완충 역할을 한다.

주요 설정 값별 경향 분석

vm swappiness 0에 가까운 설정

0 또는 1처럼 매우 낮은 값은 스왑 진입을 거의 허용하지 않겠다는 강한 의지를 반영한다. 이 경우 커널은 메모리 회수 시 파일 캐시를 우선적으로 줄이고, 익명 메모리는 가능한 한 램에 유지하려 한다.

장점

• 데스크톱에서 애플리케이션 전환 시 지연이 줄어드는 경향
• 장시간 백그라운드로 두었던 프로그램도 비교적 빠르게 다시 활성화

단점

• 파일 캐시가 자주 비워져 동일 파일 반복 접근 성능 저하 가능성
• 메모리 부족 상황에서 스왑이라는 완충 메뉴 없이 바로 OOM 상황에 가까워질 수 있음

특히 스왑 파티션은 있지만 실제로 사용되길 원치 않는 데스크톱 사용자들이 이 값을 선호하는 편이다. 서버에서도 메모리 여유가 넉넉하고 워크로드가 비교적 일정하다면 비슷한 접근을 취할 수 있다.

vm swappiness 60 기본값 주변

많은 배포판에서 사용하는 60은 어느 한쪽에 치우치지 않는 절충이다. 스왑을 적당히 활용해 파일 캐시를 일정 수준 유지하면서도, 인터랙티브 응답성을 완전히 포기하지 않는 중간 지점으로 볼 수 있다.

기본값의 의미를 이해하는 것은 중요하다. 이것은 최적값이라기보다 다양한 시스템을 무난하게 동작시키기 위한 범용값에 가깝다. 실제로는 모니터링을 통해 스왑 사용량, 페이지 폴트, I O 패턴을 관찰하면서 환경에 맞게 값 조정이 이루어지는 경우가 많다.

vm swappiness 100에 가까운 설정

값을 크게 올리면 커널이 스왑을 훨씬 적극적으로 사용한다. 어느 정도 메모리가 여유 있을 때도 덜 사용되는 익명 페이지를 미리 스왑으로 밀어내고 파일 캐시를 두텁게 유지하는 쪽으로 동작한다.

장점

• 디스크 기반 반복 I O 워크로드에서 파일 캐시가 두꺼워져 처리량이 좋아질 수 있음
• 메모리 사용 패턴이 예측 가능한 배치 작업이나 특정 서버에서 안정된 성능을 낼 수 있음

단점

• 데스크톱이나 터미널 환경에서 체감 지연이 늘기 쉽다
• 갑자기 사용자 활동 패턴이 바뀌면 스왑 인 비용이 크게 튄다

그래서 이 값은 일반적인 데스크톱보다는 특정 배치 서버나 캐시 위주의 워크로드에서 실험적으로 사용하는 경우가 많다.

vm swappiness 조정 방법과 테스트 전략

일시 조정과 영구 설정

실제 시스템에서 값을 확인하고 조정하는 기본적인 방법은 다음과 같다.

현재 값 확인

cat /proc/sys/vm/swappiness

일시 변경

sysctl vm.swappiness=10

재부팅 후에도 유지하려면 sysctl 설정 파일에 추가한다.

echo "vm.swappiness = 10" >> /etc/sysctl.d/99-custom.conf
sysctl -p /etc/sysctl.d/99-custom.conf

이렇게 하면 커널 파라미터가 시스템 전역에 적용된다. 서비스별로 swappiness를 따로 설정할 수는 없기 때문에, 핵심 워크로드 기준으로 값을 정하고 나머지 애플리케이션이 이를 함께 사용하는 구조가 된다.

실제 영향 평가를 위한 관찰 포인트

값을 조정했다면 다음과 같은 지표를 함께 살펴보면 좋다.

• free 명령 또는 vmstat을 이용한 스왑 사용량 변화
• iostat이나 sar 등을 통한 디스크 I O 패턴 변화
• top htop에서 프로세스별 메모리와 스왑 사용량
• 페이지 폴트 횟수와 커널 로그에서의 메모리 관련 메시지

데스크톱에서는 간단히 애플리케이션 전환 속도, IDE와 브라우저 재활성화 지연 시간만 관찰해도 체감 차이를 파악할 수 있다. 서버에서는 부하 테스트나 실제 트래픽 상황에서 응답 시간과 에러율을 함께 모니터링하면서 swappiness 변경 전후를 비교하는 방식이 일반적이다.

환경별 추천 전략과 실무적인 가이드

데스크톱과 개발용 워크스테이션

• 메모리가 넉넉하고 스왑이 거의 필요 없을 때
  • vm swappiness를 10 이하로 낮춰 인터랙티브 지연을 줄이는 선택이 자주 사용된다
• 메모리가 다소 부족하고 여러 애플리케이션을 동시에 띄우는 경우
  • 20에서 40 사이에서 조정하며 체감 속도와 디스크 I O 밸런스를 맞추는 전략이 유효하다

또한 브라우저 탭을 수십 개 열어두는 습관이 있다면, swappiness 값을 너무 낮추면 파일 캐시가 자주 줄어들어 전체 시스템이 버벅이는 경험을 할 수 있다. 실제 사용 패턴에 맞춰 값을 조금씩 조정해 보는 것이 좋다.

데이터베이스와 캐시 서버

• 데이터베이스 서버
  • 스왑 인이 발생하면 지연이 크게 튀기 때문에, 많은 운영 사례에서 swappiness를 1 또는 10 이하로 낮추는 편이다
  • 대신 충분한 물리 메모리 확보와 적절한 메모리 상한 설정이 전제되어야 한다
• 캐시 서버나 인메모리 데이터 스토어
  • 캐시 데이터가 스왑으로 밀려나면 의미가 줄어들기 때문에 역시 낮은 swappiness를 선호한다
  • 메모리 부족 시 캐시를 버리는 전략이 나은지, 스왑으로 넘겨 버티는 전략이 나은지 애플리케이션 특성에 따라 다르게 판단해야 한다

일반 웹 애플리케이션 서버

웹 서버와 애플리케이션 서버가 함께 동작하는 일반적인 환경에서는 다음과 같은 접근이 무난하다.

• 기본값 60에서 시작
• 스왑 사용량이 과도하게 늘고 응답 지연이 눈에 띄면 30 전후로 점진 조정
• 모니터링 결과 스왑이 거의 사용되지 않고 메모리 여유가 충분하다면 10 정도까지 낮추어 인터랙티브 응답성과 캐시 사이의 균형을 맞춘다

이 과정에서 중요한 것은 단일 숫자를 절대값으로 믿지 않고, 실제 워크로드와 모니터링 데이터를 기반으로 조정한다는 점이다.

마무리 정리

vm swappiness는 단순한 숫자 하나지만, 시스템이 메모리와 스왑을 어떻게 활용할지에 큰 영향을 준다. 값이 낮을수록 프로세스 메모리를 램에 오래 두어 인터랙티브 응답성을 높이고, 값이 높을수록 스왑을 적극 활용해 파일 캐시를 두텁게 유지하려는 경향을 보인다.

데스크톱인지, 데이터베이스 서버인지, 웹 애플리케이션 서버인지에 따라 최적값은 크게 달라진다. 기본값을 무조건 신뢰하기보다는, 현재 환경의 메모리 사용 패턴과 스왑 사용량, 디스크 I O 지표를 함께 관찰하며 값을 단계적으로 조정하는 접근이 가장 현실적이다.
궁극적으로 vm swappiness 튜닝의 목표는 스왑을 없애는 것이 아니라, 해당 시스템이 요구하는 응답성과 안정성 사이에서 가장 자연스러운 균형점을 찾는 데 있다.