현재 위치

홈 ›› Forums ›› 이슈 ›› 토론, 토의

요즘도 swap partition 이 필요한가요?

Arcy의 이미지
글쓴이: Arcy / 작성시간: 수, 2009/01/21 - 2:01오전

90년대 초중반, 메모리가 워낙 비싸던 시기엔 HDD 에 swap 을 쓸 수 밖에 없었습니다.

하지만, DRAM 가격이 기가당 만원 남짓 떨어진 지금 시점, swap 이 유용한가요?

잘 아시다시피, swap은 physical memory가 전부 소진되면 fixed disk의 일부를 메모리처럼 사용하는 기법입니다.

메모리가 XXMB, XXXMB 정도 사용되던 시절엔 RAM의 두 배를 swap으로 잡으라고들 햇었죠.

하지만 RAM 에 비해 HDD의 엄청나게 느린 속도 때문에 swap이 사용되면 서버의 퍼포먼스는 급격하게 떨어집니다. 몇백이 넘는 로드도 쉽게 볼 수 있죠.

이러한 서버는 swap 공간을 빌어 겨우 살아는 있지만, 정상적인 작동은 하지 못하는 상태입니다. 이미 하드웨어 구성이 실패한 서버이고 이러한 로드가 지속되는 환경이라면 하드웨어의 보강 혹은 로드의 재분배가 취해야 할 처치죠. swap으로 서버의 uptime을 연명하는 정책은 도리어 적절한 관리를 위한 로그인조차 힘들게 만듭니다.

뭐 메모리가 워낙 싸죠, 서버의 필요 사양에 비해서. 메모리 모자라면 사다 꽂는게 요즘은 답일겁니다.

게다가 요즘 커널은 메모리가 가득 차게 되면 프로세스를 적절히 죽여 시스템을 유지합니다. 서비스는 중단되겠지만 swap이 가득차서 느려진 것 때문에 서비스가 중단되는 것과 별 차이는 없습니다. 물론 swap까지 가득차면 프로세스를 죽이는 것은 마찬가지입니다.

그렇다면 swap을 없애서 손해보는 것이 과연 있을까요? 여러분의 의견은 어떠신지요?

랩탑 등의 hibernation을 위한 swap space는 예외로 치겠습니다. ^^

Forums: 
토론, 토의
cogniti의 이미지

글쓴이: cogniti / 작성시간: 수, 2009/01/21 - 3:55오전

간혹 스왑을 없애자는 말들이 오고가는데, 메모리가 4GB인 개인 컴퓨터에서도 스왑은 필수입니다.
예를 들어, 프로그램에서 메모리를 4GB 다 쓰게 되면 스왑 파티션을 사용하는데...
그게 안 되면 시스템 멈춤니다. 메모리가 다 차면 kill 명령어도 안 먹힙니다.
스왑이 있으면 하드 버벅댈 때 스왑이 다 차려면 수분~수십분 걸리기 때문에,
kill로 프로세스를 죽을 수는 있습니다.
RAM은 소리없이, 십초 정도면 모두 소진되어 kill로 죽일 틈새가 없습니다.

궁금하시면 자바에서 배열 크기를 100000 정도 주고 gcj 로 컴파일해서 실행해보세요. 아니면 C로 malloc 해보세요.
아니면 오픈오피스로 100MB 크기 이상의 문서를 10개 정도 열어보세요.
또는 메모리 누수 버그가 있는 프로그램들(과거에 compiz, xorg)을 사용하다보면,
스왑이 왜 필요한지 답이 딱 나옵니다.

거꾸로 생각하면 오히려 하드 값이 싸기 때문에 스왑으로 20GB 줘도 아깝지가 않죠.

(추가) 이런;;; 아...서버에서 스왑을 말씀하셨군요. 제가 동문서답을 했군요. 죄송;;;

Arcy의 이미지

글쓴이: Arcy / 작성시간: 목, 2009/01/22 - 2:21오전

서버든 데탑이든 마찬가지입니다.

말씀하신대로 실험해 본 ubuntu 8.04 LTS, 기본 커널, 스왑은 없앤 노트북입니다.

$ free
             total       used       free     shared    buffers     cached
Mem:       1287484     468740     818744          0       7956     129536
-/+ buffers/cache:     331248     956236
Swap:            0          0          0

아래 URL의 두번째 코드로 실험해 보았습니다.

http://www.linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html

b.c

#include <stdio.h>
#include <stdlib.h>
 
#define MEGABYTE 1024*1024
 
int main(int argc, char *argv[])
{
        void *myblock = NULL;
        int count = 0;
 
        while(1)
        {
                myblock = (void *) malloc(MEGABYTE);
                if (!myblock) break;
                memset(myblock,1, MEGABYTE);
                printf("Currently allocating %d MB\n",++count);
        }
        exit(0);
 
}

oom-killer 가 이 b 프로그램을 죽입니다.

[  349.606588] cpufreqd invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
..중략..
[  349.619772] Out of memory: kill process 7165 (b) score 225523 or a child
[  349.619819] Killed process 7165 (b)

컨디션에 따라 다르지만, 메모리를 많이 먹는 프로세스를 죽이고 정상 상태로 돌아옵니다.

제 글의 요지는 out-of-memory 가 일어나지 않을 것이라는 이야기가 아닙니다.

1. OOM 발생시 swap이 있으면 말씀하신대로 swap 이 소진될때까지 시스템이 지연되죠. 예시를 드신 대로 20G swap을 잡았다면, 프로그램이 20G 의 fixed disk 기록을 끝낼때까지 시스템은 거의 먹통이 되겠죠. 커널은 끝없는 page-fault를 통해 HDD를 긁어댈 테니까요. 차라리 저렇게 oom-killer에 의해 문제되는 프로세스가 죽고 시스템이 복구 가능한 상태로 빨리 돌아가는 편이 유리합니다.

2. OOM 상태가 반복된다면 RAM을 늘려야 한다는겁니다.

cogniti의 이미지

글쓴이: cogniti / 작성시간: 목, 2009/01/22 - 9:26오후

오작동 하는 경우 있습니다.

JuEUS-U의 이미지

글쓴이: JuEUS-U / 작성시간: 금, 2009/01/23 - 9:15오전

프로세스를 죽이면 안되는 경우도 있습죠 = ω=)r;;
DB의 경우에는 적어도 백업뜰 시간은 있어야 하는거 아니겠습니까.
아예 안죽이는게 최선입지만요.

죽은 것과 다름 없는 것하고, 죽은 것하고는 엄연히 다릅니다.
죽지만 않으면 관리팀이 붙어서 어찌어찌 할 수 있지만,
죽으면 아무것도 아닙니다.

그리고 시스템 설계의 실패라고는 하지만,
비용/기술이 예측된 시스템을 구현할 만큼 충분하지 않았을 수도 있고
예측 자체가 잘못되었거나, 예측을 뛰어넘는 결과가 있을 수도 있습니다.

뭐 그런저런 이유로 UPS처럼 위험에 대비하는데에는 적당한 녀석입죠. = ω=)r

(듣기로는 서버 죽는거 막으려고 상시 대기 복구팀을 연봉 높이주고 쓰는 회사도 있습니다.)

Arcy의 이미지

글쓴이: Arcy / 작성시간: 토, 2009/01/24 - 12:18오전

죽이면 안되는 프로세스는 oom_adj 로 oom_score 를 변경해주면 됩니다.

-17 일 경우 oom_killer 한테 죽지 않지요.

JuEUS-U의 이미지

글쓴이: JuEUS-U / 작성시간: 화, 2009/01/27 - 4:07오전

죽이면 안되는게 메모리 초과의 주 원인인 경우도 있죠 = ω=)

저도 한때는 Swap따위 버리자는 생각으로 안잡았는데
어느날 DB가 램 2G 중에서 1.9기가 먹는 그 순간부터
등줄에 식은땀이 쫙 흐릅더랍니다... 죽을까봐 = _=);;;
그 때 WM을 Blackbox 안썼으면 죽었죠.
(빛을 보지못한 phpbb2drupal 컨버터 제작기)

kslee80의 이미지

글쓴이: kslee80 / 작성시간: 수, 2009/01/21 - 1:00오후

스왑 파티션의 존재의의에 대한 것은 UPS 의 존재의의와 비슷하다고 생각합니다.

playhop의 이미지

글쓴이: playhop / 작성시간: 수, 2009/01/21 - 2:20오후

가입 하셔야 읽을수 있을건데... 같은 리눅포럼이니까 가입하셔도 무방할듯..

제가 단 허접한 글도 한번 평가 부탁드립니다... 쿨럭
http://www.lug.or.kr/home/bbs/board.php?bo_table=lkin&wr_id=2078&sca=&sfl=wr_subject%7C%7Cwr_content&stx=swap&sop=and

또 밀어야 하나 아니 이제 인생 자체를 밀어야 한다..... IT 관두는 젖비린내 SE (/ㅡ_-)/~

sangwoo의 이미지

글쓴이: sangwoo / 작성시간: 목, 2009/01/22 - 5:25오전

충분한 메모리가 있다면 스왑이 있을 필요가 있나요? 말씀하신 대로 hibernation 같은 걸 제외한다면...
가령 4G 메모리가 불안정해서 8G의 스왑을 잡아야 하는 환경이라면, 12G의 메모리를 장착하는 편이 훨씬 낫죠.
----
Let's shut up and code.

----
Let's shut up and code.

ddoman의 이미지

글쓴이: ddoman / 작성시간: 화, 2009/01/27 - 9:09오전

32비트 OS에서는 한 프로세스당 가상메모리 영역이 4GB입니다.
그리고 2GB는 Kernel 이미지가 점유하고 있고요.

그래서 프로세스가 20개가 있다면 표현 가능한 가상메모리 영역은 80GB겠죠.

당연히, 그것은 가상메모리일 뿐이고, 모든 프로세스들이 자신의 모든 메모리 영역을
할당해서 사용하는것도 아니고요.

실제로 엄청나게 큰 메모리 영역을 할당하더라도 그것은 단지 프로세스 테이블의 가상메모리를 관리하는 테이블에
기록을 해놓는것 뿐입니다. 실제로 할당을 안할경우가 대부분이죠.

그리고, 대부분의 프로세스들이 공통적으로 쓰게 되는 libc나 기타 등등은 가상메모리 영역에서는 각자의 주소공간에 위치한것처럼
보이더라도, 실제 메모리상에서는 한개의 이미지만 로드 되고, 단지 각각의 프로세스 가상메모리 영역에 맵핑되어있습니다.

그래서 프로세스들간 context switching을 할때마다, 필요한 memory table을 로드하고, 실제로 access하는 메모리만 physical 메모리에 로드되는 경우가 대부분입니다.
그 외, 메모리 복사의 경우도 copy on write같은 꼼수(?)로 가상메모리 영역에서는 80GB의 메모리가 필요할지라도
물리영역에서는 최대한 효율적이게 메모리가 사용되게 하는것이 커널이 담당하는 영역 중 하나입니다.

더군다나 자주 쓰이지 않는 메모리 불럭이나( 프로세스입장에서는 사실 할당 되어있을지라도 ), 프로세스 같은 넘들은
swapping을 통해 swap partition에 저장해놓고, 그 자식들이 언젠가 필요할 때 까지는 그냥 하드디스크에 잠자고 있을런지도 모릅니다.

리눅스의 경우 lazy swapping을 하기 때문에, 굳이 최적화하려 애쓰지 않아도, 현재 메모리가 크게 모자르지 않으면, 가령 데스크탑 같은경우..
스와핑을 하지 않는 경우가 많습니다.

어쨋든, 스왑 파티션을 주는 이유는,
OS입장에서 자주 쓰이지도 않는 프로세스나 메모리 영역을 하드에 저장해둠으로써, 활발하게 움직이는 프로세스들에게
좀 더 원할하게 물리 메모리 영역을 배당해주기 위해서입니다.

swap partition을 주더라도, OS가 어짜피 효율적으로 사용하는 경우가 대부분이기 때문에 그냥 믿고 몇 GB정도는 주는게 나을런지도 모릅니다.

하지만, 데스크탑 level에서는 그닥 큰 차이가 없을꺼라고 개인적으로 생각합니다.

서버같이 프로세스나 쓰레드가 100개 이상될수도 있고, 또는 정말 활발하게 많은 메모리 operation들이 일어날 때,
커널의 가상메모리 <=> 물리메모리 스왑핑에 조금이나마 여유를 줄 수 있게 도와주려 할 때, swap partition이 의미가 클 것이라고 생각이 드네요.

kirrie의 이미지

글쓴이: kirrie / 작성시간: 수, 2009/01/28 - 2:36오후

자, 그럼 기가바이트급 램이 장착된 서버에서 스왑 파티션으로는 예전처럼 그냥 2배 정도를 주는게 좋을까요?

--->
데비안 & 우분투로 대동단결!

--->
데비안 & 우분투로 대동단결!

ienfant의 이미지

글쓴이: ienfant / 작성시간: 수, 2009/01/28 - 5:02오후

IBM 튜닝북에서 처음 본 듯 하고.. 언제가부터 별 생각없이, RHEL 문서에 있는 그대로를 따라합니다;;

M = Amount of RAM in GB, and S = Amount of swap in GB, then
 
If M < 2
	S = M *2
Else
	S = M + 2

Using this formula, a system with 2 GB of physical RAM would have 4 GB of swap, while one with 3 GB of physical RAM would have 5 GB of swap. Creating a large swap space partition can be especially helpful if you plan to upgrade your RAM at a later time.

For systems with really large amounts of RAM (more than 32 GB) you can likely get away with a smaller swap partition (around 1x, or less, of physical RAM)

http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch04s18s04s02.html

kirrie의 이미지

글쓴이: kirrie / 작성시간: 목, 2009/01/29 - 3:03오후

ㅎㅎㅎ 다른 것 신경 안써도 되니 좋네요. 소중한 정보 감사합니다. ^^
--->
데비안 & 우분투로 대동단결!

--->
데비안 & 우분투로 대동단결!

다즐링의 이미지

글쓴이: 다즐링 / 작성시간: 수, 2009/01/28 - 6:53오후

일단 저는 주로 서버시스템을 설정한다고 치면..

상황을 봐서..

512M 에서 2기가정도까지 줍니다.

일단 스왑인아웃의 횟수가 많아지면 당연히 느려질것이고..

서버시스템의 경우엔 느려지면 안되는 경우가 대부분이므로..

뭔가 버틴다는 개념보다는.. 널럴하게 안전하게 =) 를 위주로 생각하는 것이 좋을듯합니다.

물론 서버이므로 단일 서비스만 운영하니까 메모리라던가 그런것의 소모양이 대충은 눈에 보이니까요.

그런면에선 자바가 참 좋습니다 -_-;;; jvm 에 할당한 메모리만 쓰니까;;;

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

sephiron의 이미지

글쓴이: sephiron / 작성시간: 금, 2009/01/30 - 9:01오후

Quote:
하지만, DRAM 가격이 기가당 만원 남짓 떨어진 지금 시점, swap 이 유용한가요?

하드디스크의 용량당 가격은 훨씬 더 가파르게 떨어졌지요. 충분히 스왑을 잡아주는 것이 바람직할 듯 하네요.

둘러보기