Swappiness 에 대해서 정확히 알고갑시다.

메모리의 사용량 그리고 메모리의 어느정도 사용시 Swap 이 발생하고

이 비율을 어떻게 조절하는지에 대한 인터넷사이트나 페이지, 문서는 상당히 많은데,

막상 다소 잘못된 내용들이 너무 넘쳐나는 것 같고, 제대로 짚어주는 사람은 아무도 없어

글을 급하게 쓰기 시작한다.

대부분 리눅스의 스왑을 사용하지 않게 하기 위해선 swappiness 를 0 으로 두고,

보다 Swap 영역을 적극적으로 쓰게 하기 위해서는 100에 가깝게 조절해준다고 알고 있다.

리눅스 디폴트는 60인것을 일단 깔고가자 (코드상에서).

하지만 Swappiness 는 당신이 알고 있듯이 그리 단순한 문제가 아니다.

한 고객이 문의를 한다.

Q. 저희는 스왑 안쓰고 전부 메모리에 올려 써야하는 고성능을 필요로하는 서비스라

vm.swappiness 를 0 으로 두면 Swap 사용할 일이 없어지겠죠?

나는 이렇게 답한다.

A. 흠.. 스왑을 아예 안쓰는것은 아니고 스왑 사용률을 최대한 줄이는것이긴 한데

커널이 필요로 하다고 판단할 경우에는 사용할 수 있을껄?

다시 되묻는다.

Q. 아니 그래서 swappiness 를 0 으로 두면 스왑 안쓰는거 맞아 안맞아?

살짝 짜증...(반복 개싫어함)

A. 기본적으로는 안쓰려고 노력하지만 커널이 필요로 하면 쓴다고!

그리곤 얼마 후 (실제로 거의 일년뒤) Swappiness 를 0 으로 두었는데도

왜 Swap 이 발생한건지 분석해달라고 sosreport 를 떡 하니 던진다...

왜 Swappiness 를 0 으로 두었음에도 불구하고 Swap 이 발생했을까?

정말 Swappiness 를 0 으로 두면 스왑을 막을 수 있을까 ?

백문이 불여일견 간단히 테스트 하도록 하자.

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690         152        3446          24          92        3397
Swap:          3071           0        3071

[root@Mirr-OL7 ~]# swapon -s
Filename                Type        Size    Used    Priority
/dev/dm-1                                  partition    3145724    0    -1

[root@Mirr-OL7 ~]# sysctl -w vm.swappiness=0
vm.swappiness = 0
[root@Mirr-OL7 ~]# sysctl -a | grep swappi
vm.swappiness = 0

테스트를 위한 VM 으로 Total memory 3690, used 142 MB, Swap 3071M 이다.

C 로 짜기 귀찮으니 Python 으로 간단히 메모리를 할당해 보자.

#!/usr/bin/env python

import sys
import os

if len(sys.argv) != 2:
    print "usage: %s <number-of-megabytes>" % sys.argv[0]
    sys.exit()

pid = os.getpid()
count = int(sys.argv[1])

megabyte = (0,) * (1024 * 1024 / 8)         # tuple 로 그냥 무식하게 할당.

data = megabyte * count

while True:
    pass

간단하게 메모리만 할당할거라 뭐라 하지 말자 ㅋㅋㅋ

[root@Mirr-OL7 ~]# python mem_usage.py 10
Allocated mem(26646) : 10M
^Z
[1]+  Stopped                 python mem_usage.py 10
[root@Mirr-OL7 ~]# pmap 26646 | grep anon
0000000001544000    832K rw---   [ anon ]
00007fca2e07a000  11272K rw---   [ anon ]               << 10M

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690         166        3432          24          92        3383
Swap:          3071           0        3071

[root@Mirr-OL7 ~]# python mem_usage.py 100
Allocated mem(26744) : 100M
^Z
[1]+  Stopped                 python mem_usage.py 100
[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690         252        3346          24          92        3297
Swap:          3071           0        3071

[root@Mirr-OL7 ~]# python mem_usage.py 3000
Allocated mem(26832) : 3000M
^Z
[1]+  Stopped                 python mem_usage.py 3000
[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3157         440          24          92         392
Swap:          3071           0        3071

[root@Mirr-OL7 ~]# python mem_usage.py 3600

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3524         132           2          33          65
Swap:          3071         332        2739

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3520         137           2          32          70
Swap:          3071         297        2774

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3533         123           2          33          57
Swap:          3071         413        2658

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3494         161           2          35          95
Swap:          3071         354        2717

마지막에 3.6 G 를 할당하자 Swap 과 Mem used 가 왔다갔다하면서

열심히 Reclaim 하느라 시스템 부하가 올라간다.

스왑 발생 후 리클레임 완료/할당완료 상태이다.

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3545         110           0          34          45
Swap:          3071         295        2776

해당 파일을 종료하는 순간 아래와 같이 스왑이 다시 사용된다

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3550         108           0          31          41
Swap:          3071         412        2659
[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3534         124           0          32          57
Swap:          3071         669        2402

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        3492         167           0          30          99
Swap:          3071        1260        1811

반환 완료시 상태이다.

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690          75        3583           0          31        3516
Swap:          3071          96        2975

vm.min_free_kbytes = 67584 였던 상태인데 800메가로 수정해 보고 테스트한다.

[root@Mirr-OL7 ~]# sysctl -w vm.min_free_kbytes=819200

[root@Mirr-OL7 ~]# python mem_usage.py 3000
Allocated mem(29479) : 3000M

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        2313        1339           0          37         358
Swap:          3071        1098        1973

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        2369        1289           0          31         304
Swap:          3071         950        2121

종료 후 :

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690          75        3572           0          42        2593
Swap:          3071          97        2974

root@Mirr-OL7 ~]# python mem_usage.py 2500
Allocated mem(29971) : 2500M

[root@Mirr-OL7 ~]# free -m
              total        used        free      shared  buff/cache   available
Mem:           3690        2584        1063           0          42          84
Swap:          3071          97        2974

!!!! 실제 테스트는 여기까지 마치도록 하고 왜 이런 현상이 발생하는지 찾아보자.

스왑이 발생하는 경우는 몇가지 복잡한 공식이 있으나 대략적인 내용은

아래와 같은 Swappniess 에 대한 설명에서 알 수 있다. (sysctl/vm.txt)

"This control is used to define how aggressive (sic) the kernel will swap memory pages. Higher values will increase aggressiveness, lower values decrease the amount of swap. A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.

즉, 0이 아닌경우 그의 값에 상응하는 적극성을 갖고 Swap 을 관리하겠다는 것이고,

0일 경우 file-backed page 가 high water mark 보다 낮을 때 까지 스왑을 보류하겠다는 것이다.

이 말은 결국 Swappiness 가 0 이라 할지라도 스왑이 발생할 수 있다는 점이다.

그럼 file-backed 에 대한 것이 무엇인가 ?

메모리에 대한 영역을 구분해 보자면,

크게 File-backed/Anonymous/Device-backed/Shared/COW 이렇게 나뉘어지는데

나머지들은 직접 찾아보고, 스왑은 당연히 앞에 두개만 영향을 준다고 생각하자.

file-backed 영역은 파일을 통해 메모리에 상주시킬 수 있는 모든 종류의 데이타를 의미한다.

Anonymous 는 Stack/Heap 등과 같이 파일로 부터 읽어오지 않은 직접 할당된

모든 데이타들을 총칭하는데, 이에 대한 Backend device 가 없기 때문에

저장을 하고자 한다면 Swap 이 필요하다. ( Disk-Memory sync )

그렇다면 Swappiness 는 file-backed 와 Anonymous 를 검사하는 알고리즘이 있다는 것인데,

kernel-source/mm/vmscan.c 의 get_scan_count 함수에 아래와 같이 나와있다.

/*
 * With swappiness at 100, anonymous and file have the same priority.
 * This scanning priority is essentially the inverse of IO cost.
*/
 anon_prio = swappiness;
 file_prio = 200 - anon_prio;

즉, Anon_prio 는 Swappiness 의 값과 같고, file_prio 는 200 - anon_prio 라는 것!

Swaippiness 가 100 일 경우에야 Anon/File 영역이 동일해지고, 그 외에는

무조건 File 영역이 우선순위를 갖게 된다는 것이다!

즉, Swappiness 가 0 이라 할 지라도, file 영역과 관련된 Swapping 은

무조건 발생 할 수 있다는 것을 역설한다.

Q. 그럼 스왑을 발생하지 않게 하려면 어떻게 해야한다는 말이냐 ?

A. 위에 Swappiness 이 설명에서 이미 되어 있는데 다시한번 정리를 해주자면,

Swappiness 를 0 으로 두면 우선적으로 anon data 에 대한 Swap 은 최대한 없앨 수 있다.

하지만 File 베이스는 여전히 발생한다.

따라서 해당 사용량을 완전히 없애는 방법은 없다는 것이다.

아주 빠르고 가볍게 File-base 로 동작하는 모든 작업들을
허용된 물리적 메모리 안에서 처리하고 재빠르게 폐기(Free) 되도록 만든뒤,
해당 작업에 대한 Overcost 역시 없앤다면 가능할 수 도 있다.

어플리케이션 잘 짜면 Swap 이 그럼 정말 멈추긴 하는거야? 라는 의문이 들 수 있다.

Swappiness 가 0 일 경우라면, 설명에서와 같이 high water mark 에 속하는 페이지의

Free 영역을 주의깊게 관리하면 되기 때문에 위와 같은 시나리오로 프로그램을 작성할 수 있다.
( 해당 페이지의 수는 /proc/zoninfo 에서 확인 할 수 있다. )

하지만 시스템전체적인 부하가 발생하여 시스템로드가 올라간다면

역시 시스템상에서 스왑이 발생할 수 있다.

Q. 그럼 Swappiness 는 어떻게 쓰는게 좋은가 ?

A. Swappiness 는 말 그대로 얼마나 Swap 을 어떻게 사용하겠냐를

- 결정하는 조건을 정해주는 것이므로, 메모리 상주를 위주로 하는 어플리케이션의 경우 Swappiness 가 0에 가까울 수록 스왑을 줄이고 메모리 자체를
직접적으로 사용하려는 시도를 우선하기 때문에 성능에 도움이 될 수 있다.

- Disk I/O 를 베이스로 하는 어플리케이션의 경우 빠른 Disk 속도에 의존해서
Swappiness 값을 0이 아닌 값으로 적절히 조절하여
보다 더 안정적인 시스템 성능을 낼 수 있다.

위와 같이 자신의 서비스에 적합한 스왑빈도를 테스트를 통해 찾아내는 것이 중요하다.

역시 스왑을 아예 없애는 것은 상당히 어려운 기법임을 알 수 있다.

운영체제의 안정성을 바탕으로, 어떤 운영체제라고 해도, 빠방한 메모리를 갖고 있다고 해도

완벽하게 스왑없이 운영하는 것은 불가능하다는 것을 의미한다.

결국 테스트 과정에서 부수적으로 확인된 것이긴 한데, 결국 시스템에서

사용가능한 메모리의 양은 Free 의 Available 영역으로 확인하는 것이

또한 가장 합리적이고 간단한 방법임을 확인할 수 있었다.

즉, Linux 메모리관리에 문제를 제기하지 말고 너의 몸에 달린 메모리나 관리 하도록 하자.

사람의 인체와 마찬가지로 컴퓨터의 CPU 와 메모리라는 것은 상당히 복잡한 영역이다.

따라서 단순한 계산으로 쉽게 계산할 수 있는 방법은 존재하지 않는다.

결국 그때 그때의 사용정도만 종합적으로 보여준는 것이 다들 알고 있는

Free, top, mpstat, vmstat 등 의 명령인 것이다.

그 값에 의심을 갖지 말고 그냥 좀 믿자 .. 뇌피셜이 많아질수록 꼰대가 된다..

다시한번 결론!

Swappiness 가 0 으로 설정되어 있다고 해서 스왑을 안쓴다는건 아니다. 명심하자.

* 읽으신분들이 쪼금 되서 급하게 추가 :
"Swappiness 를 그럼 언제 쓰란 말이냐"

** File-backed 관련 테스트를 위한 간단한 Python code.
( file 은 dd if=/dev/zero of={filename} bs=1024M count=XXX 로 생성 )

#!/usr/bin/env python

import sys
import os

if len(sys.argv) != 2:
    print "usage: %s <file-name>" % sys.argv[0]
    sys.exit()

pid = os.getpid()

f = open(sys.argv[1], "r")
size=f.read()

print ("File read test (%d) : %s read - %dM") % (pid, sys.argv[1], len(size)/1024**2)

while True:
    pass

테스트를 할때 여러조건으로 중복으로 실행하며 테스트 해보시면 좋다..
(난 귀찮아서 ㅠㅠ)

*** 관련 하여 회사 Mailing List 에서 커널개발팀 답변 :

Also we *very strongly recommend* not setting vm.swappiness=0. That can
result in some corner cases where the system has sputtering hang-ups
when it finally does have to swap for some reason.

Unless oswatcher is showing major %so/%si (swap-out/in) activity, it's
not having any impact on system performance, so if the underlying
question is about performance, you're probably looking at the wrong thing.

Swappiness 가 메모리를 더 적극적으로 활용하도록 하는 것은 맞지만,

Pinch 상황 즉, 시스템 부하가 높아지는 상황에서는 심각한 서비스 영속성 ( service continuty ) 을

손상시키는 결과를 불러올 수 있다는 점을 경고하고 있다.