프로세스가 실행될때, 먼저 가상 공간을 확보후 (페이징파일과는 분명히 다릅니다.) 실제 메모리에 매핑을 하게되는 과정을 거칩니다.
작업관리자에 보면 메모리 사용량과 가상메모리 사용량이 나오는데, (디폴트는 아닙니다. 보기->칼럼선택 에서 선택해 줘야 나옵니다.) 페이징파일을 날렸는데 VM Size는 표시가 되지요. 어찌된 일일까요?
이는 그냥 프로세스에 할당된 가상 메모리 양에 불과합니다. 페이징파일과 아무런 관련이 없지요.
하지만 대부분의 사람들은 이를 페이징파일 사용량이라 착각하곤 합니다. 페이징파일과 가상메모리는 분명히 다르며, 가상메모리의 종류도 페이징파일만이 아닙니다.
결론부터 말씀드리자면 삭제하지 말기를 추천드립니다. 페이징파일을 날리면 메모리를 쓸데없는곳에 쓰게됩니다. 윈32에서 실제 메모리의 할당단위는 64K 입니다. 하지만 페이지의 단위는 플랫폼마다 다르지만 x86 환경에서는 4K입니다.
예를들어 4KB짜리 데이터 100개를 램상주시킨다 할때, 모두 실제메모리에 올린다면 최소단위가 64K므로 6.4M의 메모리가 나갑니다만, 페이징파일로 처리시는 400K면 끝납니다.
그리고 대부분 모르시는 이야기이지만, 가상 메모리에는 단순 페이징 파일 외에, 메모리 맵 파일(Memory-mapped file) 과 힙(Heap)이 존재합니다.
메모리 맵 파일은 윈32 메모리 관리 매커니즘의 꽃이지만, 가상이 아닌 실제 메모리 부분이므로 넘어가도록 하겠습니다. 파일을 메모리처럼 사용하는 기술이라 생각하시면 됩니다.
힙은 프로세스 내부적으로 이미 확보된 공간을 말합니다. 프로세스마다 디폴트로 1M가 확보되는데 이건 100% 페이징파일로 들어갑니다. 페이지가 4KB라는 장점을 극대화시키기 위한 메모리로, 작은 데이터를 처리할때 최고의 경쟁력과 경세성을 보장해줍니다. 다만 페이징파일이다보니 속도가 느린 단점은 존재하겠지만요...어쨌든 당연히 페이징파일의 삭제는 힙이라는 훌륭한 매커니즘을 포기한다는 이야기가 되는겁니다.
그 밖의 경우는 실제메모리로 올릴것인지, 페이징파일에 넣을지는 OS가 결정합니다. 사용빈도가 높다면 메모리에 올리고, 적다면 페이징파일에 심습니다. 알아서 최대의 효율을 낼수있도록 지속적으로 감시해주니,
이런 좋은 기능을 페이지파일 삭제로 없애버리는 오류는 만들지 마시길...
특별히 손을 안대도 큰파일은 메모리로 작은파일은 페이징파일로, 알아서 관리해 준답니다. (Q3에서 관련내용 이어집니다.)
그리고 대표적으로 토토샵같이 페이징파일을 반드시 이용하게끔 제작된 소프트웨어도 상당수 있다는걸 염두해두시길...(아마도 힙사용을 위해 프로그램상에서 미리 체크하는거라 생각됩니다.)
'지금 자신의 시스템이 얼마만큼의 페이징파일을 사용하는지 알고는 계십니까?'
사실 요즘같이 램이 빵빵환 환경에서는 페이징파일에 큰 데이터가 들어가지도 않습니다. 512M 시스템 기준으로 제가 측정해본 결과로는 간단한 업무등의 상황에서는 100M 미만, 풀작업환경시 (Eclipse, Toad..등 메모리사용량 536M 상황입니다.) 120~130M 사이를 왔다갔다했습니다.
512M 기준 윈도우에서 디폴트로 잡아주는값이 768M 이긴 합니다만. 게임등을 돌려서 오버헤드시라 해도 200~300M 이상 안나옵니다. 크게잡아 하드 400M정도를 낭비하는 셈이 되는거죠.
1.5배라는 속설은 메모리가 128, 256 하던 옛날 이야기입니다. 메모리가 1기가 이상라면 말할것도 없이 낭비율은 더 커질수밖에 없고요. 할당량 가변, 고정의 논쟁도 의미가 없습니다.
할당량 가변시 트레이에 가상메모리 부족이란 말풍선이 뜨면서 증가작업에 들어가는데, 최근에 이거 보신분이 솔직히 몇명이나 될런지 의문이 듭니다. 잘 일어나지도 않는 증가작업 걱정에 괜한 하드 낭비하시는거라 생각드네요.
그리고 솔직히 말풍선이 떠서 증가작업에 들어갔다 하더라도, 대부분 사용상의 부족이 아닌 특정 프로세스가 Hang이 걸려 무한루프에 빠지거나,메모리 누수가 발생한 경우가 대부분이지요.
제가 제안하는 최적의 세팅은, 자신의 가상메모리 사용량보다 살짝 위로해서 최저로 잡고, 최고치를 넉넉하게 잡아주는겁니다.
이렇게 사용시 부족메세지가 자주 보이면 최저를 올려줘야 한단 이야기가 되겠죠.
Q4. 메모리 1G->2G의 효용성은?
자신의 메모리 사용량을 안다면 답은 나옵니다. 2G만큼을 쓴다면 2G로 증설하면 됩니다. 당연히 2G만큼을 쓰지않으면서 증설하면 효과가 없겠죠. 참고로 일반적인 개인 컴퓨팅 환경에서 1G채울일도 거의 없습니다.
최근 고사양 게임에서나 1G 안팎으로 놀긴 하지만요.
Q5. 32비트 환경에서 4G의 메모리가 잡히지 않는 이유와 그 효용성은?
이부분은 좀 어려운 내용입니다. 윈32(9x 포함)에서의 메모리 관리는 다음과같은 영역으로 되어있습니다.
0x00000000~0x0000FFFF : 널포인터 할당영역 (에러보고를 위한 구간)
0x00001000~0x7FFEFFFF : 사용자 영역 (사용자가 사용할수 있는 공간)
0x7FFF0000~0x7FFFFFFF : 64K 오프리밋 (구간간 경계선)
0x80000000~0xFFFFFFFF : 커널 영역 (시스템이 사용할수 있는 구간)
사실 위는 NT고 윈9x에서는 16비트영역, 공유영역 다른구간이 있습니다만, 베이스는 동일하니 NT기반으로 설명합니다.
어쨌든 위와 같이 윈32의 사용자가 사용할수 있는 메모리 공간은 2G - 128K 입니다. 우리같은 사용자는 사용자 영역서만 작업이 가능하기 때문이죠. 그렇기 때문에 4G의 램을 붙여봐야 2G밖에 사용을 할수 없습니다.
과거에 커널영역도 사용자가 사용할 수 있는 OS가 있었습니다. 하지만, 커널영역에 접근한 사용자의 응용프로그램이 문제를 일으키면서, 물귀신처럼 커널영역에 올라간 시스템데이터를 망가트리는 경우가 많았죠.
결과는 바로 블루스크린이 뜨는거였고, 이 OS는 너무나도 유명한 윈9x 계열이랍니다.
그렇기때문에 현재의 NT기반 OS는 커널영역의 접근이 철저히 금지되어 있습니다. 하지만 요새 괴기스러운 팁이 나도는데, /PAE를 비롯한 각종 옵션으로, 메모리를 2G 넘어서까지 사용하게끔 해주는 팁이죠. 별 대단한것은 아닙니다. 메모리 영역이 다음과같이 변화됩니다.
0x00001000~0xBFFEFFFF : 사용자 영역 (사용자가 사용할수 있는 공간)
0xBFFF0000~0xBFFFFFFF : 64K 오프리밋 (구간간 경계선)
0xC0000000~0xFFFFFFFF : 커널 영역 (시스템이 사용할수 있는 구간)
즉 커널영역을 뺏어쓰는거밖에 안됩니다. 그리고 MS기술문서에는 커널영역의 감소로 인한 문제점 발생 경고를 하고 있습니다. 또한 대형서버급 몇몇 OS는 제외하고는 이 설정은, '모양만 똑같이 갖춰줄뿐 사용자 영역 메모리는 여전히 2G로 제한된다.' 라고 명시되어 있습니다. 개발자의 64비트 드라이버 개발 등을 비롯한 테스트 목적으로만 사용하라고 나와있죠.
즉, 64비트환경이 아니라면 4G램은 아무런 의미가 없습니다. 여전히 2G이상 사용 불가능입니다.
(참고 : http://support.microsoft.com/kb/291988)
보너스. NT(2000,XP..) 계열이 윈9x계열보다 메모리를 많이먹는 이유.
위에서 잠깐 언급만 했습니다만, 9x에서는 공유영역이란게 있습니다. kernel32.dll, user32.dll, gdi32.dll 등의 시스템 모듈들은 공유영역에 올라가게 되고, 응용프로그램들이 공유영역에 올라간 모듈들을 참조해서 사용하는데, 이건 결과론적으로 최악의 구성이 되어버렸습니다.
응용프로그램이 오류로 인해 죽을시 공유된 모듈을 함께 물고 죽인다는 치명적인 문제가 있었죠.
kernel32가 내려가버린 OS는 도대체 뭘까요? ㅎㅎ 바로 블루스크린 등장하시게 되는겁니다.
이때문에 NT계열에서는 공유영역이 사라지고, 공유영역에 올라가던 핵심 모듈들이, 프로세스의 수많큼 매번 로드되어 메모리에 적재됩니다. 때문에 프로세스 수만큼 메모리가 * 되어 사용되는 단점이 있지요.
반면, 오류 발생시 자신이 로드한 녀석만 죽기때문에, 전체 시스템은 원활하게 굴러가게 되는 구조가 되었습니다. 메모리의 낭비가 있긴 하지만, 아무래도 블루스크린없는 후자가 좋겠죠.
CreateRemoteThread.pdf
