윈도우를 사용할 때 32비트 버전의 윈도우에서는 4GB 이상의 램을 활용할 수 없다는 이야기를 많이 들어보셨을 겁니다. 이 때 32비트 윈도우란 우리가 흔히 사용하는 윈도우 XP, 윈도우 비스타, 윈도우 7, 윈도우 8 의 32비트 버전을 의미합니다. 참고로 이러한 윈도우들은 윈도우의 제품 분류상 클라이언트 윈도우라고 부르고 있습니다.
클라이언트 윈도우 : 윈도우 XP, 윈도우 비스타, 윈도우 7, 윈도우 8
서버 윈도우 : 윈도우 서버 2003, 윈도우 서버 2008, 윈도우 서버 2008 R2, 윈도우 서버 2012
서버 윈도우 : 윈도우 서버 2003, 윈도우 서버 2008, 윈도우 서버 2008 R2, 윈도우 서버 2012
오늘 이야기의 대상이 되는 것은 바로 이러한 클라이언트 그룹의 윈도우들입니다. 그럼 이러한 클라이언트 그룹의 32비트 윈도우들은 어찌하여 4GB 이상의 램을 활용할 수 없게 된 것일까요? 그것을 이야기해보도록 하죠.
※ 참고! 이하 글의 설명에서 따로 언급하지 않는 한 윈도우라 지칭함은 이야기의 대상인 클라이언트 윈도우를 의미하는 것입니다.
실제 주소 지도와 4GB 한계 - Physical Address Map(PAM)
1. 실제 주소 지도(Physical Address Map)의 이해
윈도우가 시스템에 장착된 메모리를 사용하기 위해선 모든 메모리 공간에 대한 주소 정보가 필요합니다. 정확한 주소가 있어야만 원하는 위치에 제대로 접근(Access)할 수 있을테니까요. 그래서 시스템은 처음에 시작될 때 시스템에 장착된 모든 메모리 공간의 주소 정보를 담은 지도를 만듭니다. 이 지도가 바로 Physical Address Map(이하 PAM) 입니다. 즉, [PAM = 실제(물리) 메모리 주소 정보] 입니다. 시스템은 이렇게 작성한 PAM 정보를 윈도우에게 넘겨줍니다. 그럼 윈도우는 이렇게 시스템으로부터 넘겨 받은 PAM 을 토대로 메모리를 인식하고 접근하는 것입니다.
그래서 윈도우는 PAM 에 그 주소가 할당된 메모리만을 사용할 수 있습니다. 만약 PAM 에 포함되지 못한 메모리 공간이 있다면, 해당 메모리 공간은 윈도우에서는 인식할 수도 없고, 결국 사용할 수도 없는 것이죠.
그런데 지금까지 시스템은 32비트 체계였습니다. 32비트 CPU 는 32비트 주소 지정 방식(32bit Addressing)을 사용하였고, 그래서 할당할 수 있는 전체 메모리 공간의 개수도 이에 맞춰 32비트 즉, 2^32 * Byte = 4GB 가 되었습니다. 고로 PAM 에 할당할 수 있는 전체 메모리 주소는 2^32 * Byte 해서 4GB 의 크기를 가지게 된 것입니다. 결국, 이러한 한계로 인해 32비트 시스템에서 인식하여 사용할 수 있는 전체 메모리의 용량은 4GB 가 되었습니다.
또한 이러한 메모리 정보를 넘겨 받아 이를 관리해야 하는 32비트 윈도우의 메모리 관리자 역시 동일하게 32비트 체계로 메모리를 관리하였기에, 마찬가지로 32비트 윈도우 자체도 4GB 의 메모리만을 관리할 수 있습니다. 즉, 시스템과 윈도우 모두 32비트 주소 체계로 메모리를 관리하는 구조적인 이유로 4GB 메모리 인식 한계란 녀석이 생겨난 것입니다. 그래서 시스템에 메모리를 아무리 많이 달아도 32비트 시스템과 32비트 윈도우에선 4GB 이상의 메모리는 사용할 수 없었습니다. [* PAE 제외]
2. 시스템에 장착된 4GB 의 램을 모두 활용하지 못하는 이유
일단 이것을 먼저 이야기해야겠네요. 우선 32비트 시스템에서 최대로 사용할 수 있는 메모리의 용량은 4GB 라는 것을 알았습니다. 그런데 여기에서 다시 아래와 같은 의문을 많이 접하게 됩니다.
"제 시스템엔 분명 4GB 의 램이 달려 있는데 어째서 시스템 등록 정보에선 3.xGB 만 표시되는 건가요? 4GB 까지 쓸 수 있는 것 아니었나요? 이건 뭔가요? 제가 사용하는 램에 무슨 문제가 발생한 건가요?"
아니 왜 4GB 가 아닌 그보다 작은 용량으로 인식이 될까?
바로 위와 같은 상황인 것이죠. 분명 4GB 이상의 램이 장착되어 있으니, 32비트 윈도우의 4GB 인식 한계에 맞춰 4GB 를 사용할 수 있어야 할텐데, 실제로는 그보다 적은 3.xGB 만 인식을 하니 어리둥절할 뿐이죠. 이건 왜 그럴까요?
사실 이건 매우 간단한 겁니다. 먼저 여러분이 한 가지 반드시 아셔야 할 것이 시스템이 관리하는 모든 메모리란 램 하나만을 의미하는 것이 아니란 것입니다. 다른 말로 여러분의 컴퓨터에 메모리는 램 하나만 있는 것이 아니라는 것이죠. 당장 흔히 아는 그래픽 카드에도 메모리가 달려 있죠? 이처럼 컴퓨터를 구성하는 거의 모든 장치들은 각자의 메모리를 가지고 있습니다. 사운드 카드, 랜 카드와 같은 장치에도 메모리가 달려있고, 심지어 메인보드의 바이오스 조차도 메모리이니까요. 이러한 모든 장치들의 메모리(Device Memory)도 시스템에서 인식을 하고 사용할 수 있으려면 램과 마찬가지로 모두 그 주소를 할당받고 PAM 에 등록이 되어야 합니다. 즉, PAM 에 등록되는 메모리 주소 정보는 정확하게 이야기하면 아래와 같은 겁니다.
PAM = 장치 메모리 주소 + 램 메모리 주소
그런데 이러한 장치 메모리들의 주소는 반드시 메모리 인식 한계인 4GB 안에서 할당받아야 합니다. 즉, 시스템에 4GB 를 초과하는 메모리가 장착되어 있다면, 반드시 장치 메모리들의 주소를 4GB 안에서 우선 할당하는 것이죠. 왜 그럴까요?
간단하게 생각해보세요. 만약에 4GB 를 초과하는 메모리를 가진 시스템에서 이러한 장치 메모리들이 4GB 내에서 처리되지 못하고 램에게 밀려버려서 결국 주소를 할당받지 못한다면 어떻게 될까요? 예로 그래픽 카드의 메모리가 주소를 할당받지 못해서 그래픽 메모리를 사용할 수 없게 된다면요? 그러면 우리는 모니터로 출력되는 이 화면을 볼 수 없게 됩니다. 즉, 컴퓨터가 정상적으로 작동하는데 꼭 필요한 장치들을 사용할 수 없는 사태가 발생하는 것이죠. 그래서 PAM 에 각 메모리들의 주소를 등록할 때는 이러한 장치 메모리들을 램보다 우선하여 4GB 내에서 처리하는 것입니다. [실제론 중간에 치고 들어오지만요.]
이를 매우 단순화시켜서 정리하면 장치 메모리 주소는 램 메모리 주소보다 우선하여 할당된다. 라고 정리할 수 있습니다. 이 때문에 [장치 메모리 + 램 메모리] 가 4GB 를 초과하는 상황이 되면, 장치 메모리들의 주소를 먼저 할당하다보니 4GB 외의 영역으로 램 메모리 공간의 일부가 밀려나게 되고, 이렇게 밀려난 램 메모리 공간은 주소를 할당받지 못하여, 결국 해당 램 메모리 공간은 사용할 수 없게 되는 겁니다.
결론적으로 32비트 시스템에서 사용 가능한 램의 최대 용량은 4GB 가 아니라 [4GB - 장치 메모리의 총합]이 되는 것입니다. 그래서 장치 메모리의 용량이 늘어나면 사용 가능한 램 용량도 그만큼 줄어들게 되겠죠. 이게 바로 시스템 등록 정보에서 표시되는 3.xGB 의 정체입니다.
참고로 그래픽 카드 중에는 그래픽 메모리가 256MB 인 녀석도 있고, 512MB 인 녀석도 있고, 1GB 인 녀석도 있듯이, 장치 메모리는 각 장치들마다 모두 조금씩 다릅니다. 즉, 시스템마다 장치 메모리의 총합은 모두 다르고, 결국 4GB 이상의 램이 장착된 시스템이라면 사용할 수 있는 램의 용량도 모두 조금씩 달라지게 되는 겁니다. 그래서 제 시스템은 사용 가능한 램 용량이 3.48GB 이지만 여러분의 시스템은 3.7GB 가 될 수도 3.2GB 가 될 수도 있는 겁니다.
"앞으로 왜 제 시스템은 3.xGB 만 인식하나요? 하긔 있긔? 없긔????"
4GB 의 인식 한계를 극복하는 PAE 기능의 등장과 윈도우의 대응
1. PAE 기능의 등장과 윈도우의 대응
앞서 말했다시피 기존까지 CPU 는 32비트 주소 지정 방식을 사용했습니다. 그래서 시스템 차원에서 4GB 인식 한계 문제가 있었죠. 이렇게 되자 인텔은 기존까지의 32비트 주소 지정 방식을 보완하여 확장한 36비트 주소 지정 방식(32bit Addressing)을 CPU 에 새롭게 추가하게 됩니다. 그것이 바로 PAE(Physical Address Extention, 실제 주소 확장) 기능입니다. 이러한 PAE 는 36비트 주소 지정 방식을 사용하기 때문에 2^36 * Byte = 64GB 의 메모리를 인식할 수 있습니다. 하지만 당장 클라이언트 윈도우에서는 이러한 PAE 에 대한 지원이 이루어지지는 않았기에 여전히 우리가 사용하던 32비트 윈도우에서의 메모리 인식 한계는 4GB 가 되었습니다.
CPU 에 이러한 PAE 기능이 추가된 지 한참이 지난 후 슬슬 4GB 이상의 메모리를 지원하는 것에 대한 필요성이 대두되었고, 먼저 윈도우 서버 제품군에서 지원이 되었으며, 이후 클라이언트 윈도우에서도 DEP(Data Execution Prevention) 지원의 필요성으로 드디어 윈도우 XP 서비스 팩 2 에 이르러 이러한 PAE 기능을 지원하게 됩니다.
그렇다면 PAE 기능을 지원하는 CPU 와 칩셋을 사용하고, 이러한 시스템에 PAE 기능을 지원하는 32비트 윈도우를 사용한다면, 과연 32비트 윈도우에서도 기존까지의 4GB 인식 한계를 넘어선 메모리를 인식하는 게 가능할까요? 이건 일단은 맞습니다. 서버 제품군의 32비트 윈도우에서는 이렇게 사용하고 있으니까요.
사실 현재 시점의 컴퓨터들은 모두 PAE 기능을 지원하고 있고, 현재 사용되는 윈도우 XP 서비스 팩 3 나 윈도우 비스타, 윈도우 7, 윈도우 8 모두 PAE 기능을 지원하고 있으니, 사실 현재 여러분이 사용하는 32비트 윈도우들은 PAE 기능이 활성화되어 있는 상태라면 4GB 를 넘어서는 메모리를 모두 인식은 하고 있는 겁니다.
그런데 여기에는 한 가지 함정이 있습니다. 하드웨어에서 지원해도 윈도우가 이를 지원하지 않으면 안 되는 겁니다. 사실 클라이언트 버전의 32비트 윈도우에서 지원하는 PAE 기능은 반쪽 짜리라고 할 수 있습니다. PAE 가 활성화되어 있다면 32비트 윈도우에서도 4GB 를 넘어서는 메모리를 모두 "인식"하는 것은 가능하지만, 실제로는 (클라이언트) 32비트 윈도우 자체에서 이러한 메모리의 관리를 기존과 동일하게 4GB 로 제한하고 있기 때문에, 결국엔 여전히 사용하지 못하는 것입니다.
사실 윈도우 XP 서비스 팩 2 에서 PAE 기능을 지원하게 되면서 마이크로소프트사 내부적으로도 모든 클라이언트 32비트 윈도우 제품들의 메모리 관리를 그에 맞게 전환하는 것을 검토했었다고 합니다. 그런데 실제로 그것을 적용하려고 테스트를 하다 보니 문제가 생긴 겁니다. 원인은 지금까지 만들어진 장치 드라이버들이 이러한 PAE 의 36비트 주소 지정 방식의 사용을 고려하지 않고 설계가 되었던 것이죠. 즉, 기존의 드라이버들이 4GB 이상의 메모리를 사용하는 환경을 고려하지 못한 셈입니다. 그래서 내부적으로 테스트를 진행한 결과 일부 장치 드라이버들로 인해 블루 스크린이나 장치 인식 불능 등의 여러 가지 문제가 발생하였다고 합니다.
결국 마이크로소프트사는 클라이언트 제품군의 윈도우들은 DEP 기능을 위해서 PAE 기능을 지원은 하지만, 대신 메모리 관리는 기존대로 유지하는 선택을 합니다. 즉, 이는 4GB 이상의 메모리를 인식을 할 수는 있는데, 윈도우 스스로 메모리 관리의 한계를 기존대로 4GB 로 제한을 해버린 겁니다. [물론 그 때까지도 4GB 메모리 용량은 클라이언트 환경에서는 흔히 접할 수 없는 용량이긴 했습니다. 괜히 무리수를 두진 않은 것이겠죠.]
이러한 이유로 32비트 윈도우더라도 서버 제품군에선 4GB 를 넘어선 메모리를 사용할 수 있지만, 클라이언트 제품군에선 여전히 4GB 의 제한이 있는 것입니다. 이것이 글의 시작에 클라이언트 윈도우와 서버 윈도우를 분리하여 이야기한 이유입니다.
사담이지만 마이크로소프트사가 클라이언트 제품군에서 4GB 인식 한계 문제의 해결을 포기한 것에는 AMD 가 한몫을 하지 않았나 생각합니다. 2003년 12월 AMD 는 인텔을 다시 한 번 기습했죠. 바로 애슬론64 CPU 를 출시한 겁니다. 아직은 시기 상조라고 생각했던 64비트 CPU 를 데스크탑 시장에 툭 던져 버린 거죠. 게다가 인텔의 아이태니엄과 같은 순수 64비트 CPU 가 아닌 기존의 32비트 윈도우도 아무런 문제없이 실행할 수 있는 32비트 호환 64비트 CPU 를 출시한 겁니다. 한 마디로 이를 지원하는 64비트 윈도우만 출시되면 끝나는 상황이었죠. 그래서 마이크로소프트는 32비트 윈도우보다는 64비트 윈도우의 개발에 더욱 집중한 것이 아닐까 생각합니다. [그 땐 AMD 가 참 좋았는데 말이죠.]
참고로 윈도우에서 PAE 기능을 활성화하는 경우에는 아래에서 이야기할 가상 주소(Virtual Address)를 실제 주소(Physical Address)로 변환하는 CPU 의 주소 변환 단계가 2단계에서 3단계로 한 단계 더 추가되기 때문에, 약 8% 정도의 전체적인 성능 하락이 발생하게 됩니다. 일반적인 가정 사용자를 대상으로 하는 클라이언트 윈도우 제품군에서는 이래저래 참 그렇고 그런 상황이었다고 할 수 있겠네요.
2. 윈도우의 반쪽짜리 PAE 지원 후 나온 편법적인 운영들
다시 한 번 정리하자면 이야기한 것과 같이 클라이언트 제품군의 32비트 윈도우더라도 PAE 기능이 활성화되어 있으면, 시스템 자체에서는 4GB 를 넘어서는 메모리를 인식하는 것은 가능합니다. 하지만 이것을 정확하게 지원하려면 윈도우의 메모리 관리도 함께 손봐야 했고, 내부적인 테스트 결과 여러 가지 문제가 발생하자, 기존까지의 메모리 관리 체계를 계속 유지한 거죠. 그 결과 32비트 윈도우에서 4GB 를 초과하는 메모리 영역은 관리하지 않는 미할당 영역으로 남겨지게 되었습니다. 즉, 어찌보자면 애초에 PAE 기능을 지원하지 않았던 예전과는 다른 상황이라고 볼 수 있습니다.
그래서 이러한 상황에 맞춰 나온 한 가지 편법이 바로 '윈도우에게 버림받은 4GB 외의 나머지 미할당 램 공간' 을 활용하여 램 디스크를 만드는 것입니다. 즉, 어차피 인식은 되어 있는 상태이고, 단순히 미할당된 채 활용하지 않고 있는 것이니, 여러 써드 파티 램 디스크 프로그램에서 자체적으로 직접 해당 메모리 영역을 제어하여, 이를 램 디스크로 활용하는 방법이 나온 것입니다. 즉, 이러한 다소 편법적인 램 디스크의 활용은 PAE 지원을 기초로 한다고 할 수 있습니다. 그래서 PAE 가 활성화되어 있지 않다면 이러한 방법도 먹히질 않습니다. 혹시나 이 방법이 궁금하시다면 아래의 글들을 참고하세요.
또 이와는 다른 방법으로, 윈도우 비스타 이후부터는 어차피 서버 윈도우 제품군이나 클라이언트 윈도우 제품군이나 동일한 커널을 사용하지만, 단순히 클라이언트 윈도우에서 메모리를 제한하고 있는 것이기 때문에, 이러한 제한을 해제하도록 커널을 패치하고, 이에 맞춰 부팅 옵션을 수정하여 클라이언트 32비트 윈도우 제품군에서도 4GB 를 넘어서는 용량을 사용할 수 있도록 만드는 패치가 존재하기도 합니다. 즉, 윈도우에서 걸어 놓은 제한을 뚫는 방식인 것이죠. 이에 대한 내용은 스누피님께서 소개해주셨더군요.
한 가지 반드시 명심하셔야 할 것이 애초에 마이크로소프트에서 메모리 관리를 4GB 로 제한한 이유가, 위에서 이야기한 것과 같이 일종의 장치 드라이버들과의 호환성이었기 때문에, 이 커널 패치 방식을 사용하는 경우 해당 문제와 직면할 수 있다는 것입니다. 그래서 어떠한 시스템에서는 아무런 문제가 없을 수 있지만, 어떠한 시스템에서는 즉시 문제가 발생할 수도 있다는 것이죠. 어떠한 장치에서 그러한 문제가 발생할 지는 사실 아무도 모른다고 할 수 있습니다. 일종의 되면 쓰고 안 되면 안 되는 복불복이라고 할 수 있겠네요.
그리고 이건 커널을 패치하는 좀 위험한 작업에 속하기도 합니다. 앞서의 램 디스크와는 다르게 이 방법은 윈도우가 한 순간에 맛탱이가 갈 수 있습니다. 그래서 이러한 편법도 존재하고 있다는 차원에서 소개를 하는 것이지, 그것을 꼭 사용해보라고 권장하는 것은 아닙니다. 그것을 명심하세요. 그러니 만약에 자신도 한 번 이러한 커널 패치를 적용해보고자 한다면, 미리 윈도우를 백업하시길 바랍니다.
가상 주소 공간의 이해 - VAS 와 페이징 파일, 4GT 옵션
※ 참고! 지금부터 이야기하는 가상 주소 공간은(Virtual Address Space) 위에서 이야기한 PAE 와는 별개의 내용입니다.
윈도우는 메모리 관리에 지금까지 이야기한 실제 메모리 공간(실제 주소)을 바로 사용하는 것이 아닌, 중간에 가상 주소 공간을 두고, [가상 주소 공간 - 메모리 관리자 - 실제 메모리] 의 메모리 관리 구조를 가지고 있습니다. 그런데 실제 메모리는 4GB 의 인식 한계를 가지고 있죠? 그래서 32비트 윈도우의 가상 주소 공간도 이에 맞춰 4GB 크기를 가지도록 설계하였습니다.
그리고 이러한 4GB 의 가상 주소 공간은 다시 2GB 의 커널 모드 공간과 2GB 의 유저 모드 공간으로 나누어집니다. 이 때 커널 모드 공간은 윈도우가 사용하는 공간이고, 유저 모드 공간은 우리가 보통 사용하는 일반 응용 프로그램들이 사용하는 공간입니다.
간단하게 프로그램이 실행되려면 프로그램이 우선 적절한 메모리 공간을 할당받고 그곳에 적재되어야 합니다. 이 때 말했다시피 윈도우의 메모리 관리자는 실제 메모리 공간에 해당 프로그램이 사용할 공간을 바로 준비하여 직접 메모리 공간을 할당해주는 것이 아닙니다. 그럼 어떻게 하느냐?
프로그램에게 메모리 요청이 오면 우선 메모리 관리자는 프로그램이 사용할 수 있는 2GB 의 가상 주소 공간을 던져주고는 프로그램에게 그곳에서 작업을 하라고 합니다. 그럼 프로그램은 윈도우가 제공한 가상 주소 공간에서 작업을 진행하는 겁니다. "이럴수가! 이 많은 메모리 공간을 전부 나에게 주다니? 나 아무래도 사랑받는 듯! 히힛~ '-'*" 하면서 말이죠. 참고로 이 때 프로그램이 제공받은 2GB 의 가상 주소 공간은 유저 모드 공간을 의미합니다.
그런데 이 때 또 다른 프로그램에게 메모리 요청이 들어오면 어떻게 될까요? 이 때도 마찬가지로 메모리 관리자는 해당 프로그램이 사용할 수 있는 별개의 2GB 가상 주소 공간을 또 던져줍니다. 또 다른 프로그램이 메모리 요청을 하면? 또 2GB 짜리 가상 주소 공간을 해당 프로그램에게 던져주죠. 즉, 유저 모드 가상 주소 공간이라는 것은 이처럼 프로그램 모두에게 개별적으로 제공되는 공간인 것입니다. 그리고 그 크기는 항상 최대 크기로 해서 제공이 됩니다. 그럼 각각의 프로그램들은 이렇게 독립적으로 제공된 자신만의 가상 공간에서 작업을 하는 것이죠. [이와는 달리 커널 모드 공간은 단일 공간으로 커널 모드를 사용하는 모든 프로세스에서 공유됩니다.]
그런데 이렇게 프로그램이 사용하는 가상 주소 공간의 내용도 실행되려면 결국엔 실제 메모리로(실제 주소 공간으로) 옮겨져야 합니다. 이 또한 메모리 관리자가 담당하게 됩니다. 즉, 메모리 관리자는 프로그램들에게 가상 주소 공간을 제공해주고, 이러한 가상 주소 공간에서 프로그램들이 작업한 것들이 실제 메모리에 적재될 필요가 있다면, 이를 알아서 실제 메모리의 적절한 위치로 탑재를 하는 것이죠.
결론적으로 윈도우에서 응용 프로그램이 실행되는 구조를 정리하자면 ① 프로그램으로 부터 메모리 공간에 대한 요청이 들어오면 ② 메모리 관리자가 프로그램들에게 먼저 가상 주소 공간을 제공해주고 ③ 프로그램들은 자신에게 주어진 유저 모드의 2GB 가상 주소 공간에서 필요한 작업을 하고 ④ 이렇게 각각의 프로그램들이 가상 주소 공간에서 작업한 내용들은 다시 메모리 관리자가 바로 바로 실제 메모리 공간의 적절한 위치로 배치하는 것입니다. 간단하죠?
참고로 메모리 관리자가 가상 주소 공간을 프로그램 모두에게 동일하게 최대 용량으로 제공해줬죠. 그럼 프로그램들은 "아싸 넓직하니 좋구나!" 하면서 자신에게 주어진 작업 공간을 활용하고요. 즉, 이러한 구조로 프로그램들은 마치 모든 메모리 공간을 혼자 독점하여 최대로 사용하는 것과 같은 효과를 얻을 수 있습니다. 그리고 가상 공간에서 열심히 작업만 하면, 메모리 관리자가 알아서 실제 메모리로 탑재도 해줍니다. 고로 응용 프로그램 차원에서는 현재 시스템의 메모리 용량이 얼만지, 실제 메모리 공간의 가용 상태는 어떤지, 내가 작업할 공간은 있는지 등등등, 메모리의 운영에 대해서는 전혀 알 필요도 없고 걱정할 필요도 없는 것이죠. 뭐 그냥 그렇다는 이야기입니다. [대신 메모리 관리자는 죽어 나겠지...]
그런데 이렇게 프로그램들이 모두 각자의 가상 주소 공간에서 원없이 작업을 하고, 그러한 결과물들을 모아서 실제 메모리로 올리다보면 필연적으로 실제 메모리 공간이 부족해지는 상황이 발생할 수 있습니다. 그럴 때 사용되는 것이 바로 윈도우의 가상 메모리 즉, 페이징 파일(Pagefile.sys) 입니다.
실제 메모리 공간이 부족한 상황이 발생하게 되면, 메모리 관리자는 실제 메모리 공간에서 지금 당장 사용되지 않는 내용을 디스크의 페이징 파일로(Pagefile.sys) 옮김으로써 실제 메모리 공간을 확보합니다. 그리고 이렇게 페이징 파일로 옮겨진 내용을 다시 사용한다는 요청이 오면 페이지 파일에서 다시 실제 메모리로 옮기는 것이고요. 실제 메모리 공간이 부족할 때마다 이것을 계속 반복하는 것이죠. 즉, 이러한 실제 메모리와(RAM) 가상 메모리(Pagefile.sys) 사이의 페이지 스왑을 통해 실제 메모리 공간의 사용 가능한 용량을 조절하는 겁니다. 간단하게 이야기하면 윈도우 가상 메모리의 작동 방식은 이렇습니다. [간혹 가상 메모리가 실제 메모리를 연장하는 것으로 알고 계신분들이 있더군요. 설명과 같이 가상 메모리는 실제 메모리 공간이 부족할 때 임시로 실제 메모리의 내용을 보관해두기 위한 곳입니다.]
문제는 이러한 스왑 과정은 많은 단계가 필요하고, 결정적으로 디스크는 램과 비교해서 정말 느리다는 겁니다. 그래서 이러한 실제 메모리와 가상 메모리 사이에서 페이지 스왑이 자주 발생하게 되면 그만큼 시스템의 성능은 떨어지게 됩니다. 이러한 문제를 해결하는 가장 근본적인 방법은 되도록이면 페이지 스왑이 일어나지 않도록 사용할 수 있는 실제 메모리 공간 즉, 램의 용량을 늘리는 것입니다. 결국은 램을 많이 장착해야 하는 것이죠. 하지만 32비트 윈도우는 최대로 관리할 수 있는 실제 메모리의 용량이 4GB 뿐이고, 이마저도 앞서 이야기했듯이 장치 메모리에게 자리를 내주다보면 결국 32비트 윈도우가 사용할 수 있는 램 공간은 3.xGB 정도만이 주어질 뿐입니다.
프로그램들의 용량은 점점 거대해지고 그만큼 이전보다 더욱 많은 메모리 공간이 필요해진 시점에서 이러한 32비트 윈도우의 메모리 인식 한계는 점점 더 큰 단점으로 작용하고 있습니다. 결국 이것은 지원 가능한 메모리의 용량이 비약적으로 증가한 64비트 윈도우가 필요해진 이유가 된 것이죠. 참고로 현재 64비트 윈도우는 윈도우 버전에 따라 1TB~192GB 정도의 메모리 용량을 지원하고 있습니다. 32비트 윈도우와는 비교가 되지 않는 용량이죠. 뭐 그렇다는 겁니다.
그런데 32비트 윈도우의 이러한 4GB 로 설계된 가상 주소 공간으로 인해 한 가지 문제가 더 발생하게 됩니다. 말했다시피 4GB 의 가상 주소 공간 중 윈도우가 사용하는 2GB 의 커널 모드 공간을 제외하면, 실제로 응용 프로그램이 사용할 수 있는 가상 주소 공간은 2GB 의 유저 모드 공간이 그 한계라고 할 수 있습니다. 고로 32비트 윈도우에서 실행되는 모든 프로그램들은 이 2GB 의 유저 공간에서 모든 것을 처리해야 하는 것이죠. 즉, 이는 실제 메모리가 4GB 아니 400GB 가 있더라도, 가상 주소 공간의 근본적인 구조상 하나의 프로그램이 활용할 수 있는 메모리 공간은 최대 2GB 를 넘지 못한다는 겁니다. 물론 설계 당시에야 2GB 라는 용량은 꿈과도 같은 용량이었죠.
그러나 세상이란 게 언제나 늘 그렇듯이 설계 당시에는 설마 했던 일들이 기술의 발전과 함께 결국엔 실제로 닥친다는 게 항상 문제입니다. 그러니까 프로그램들이 점점 거대해지면서 실제로 이 2GB 를 넘어서는 메모리 공간을 사용하려는 프로그램들이 실제로 등장을 했다는 겁니다.
그래서 윈도우에서 이러한 문제를 해결하기 위해 사용한 방법이 바로 가상 주소 공간을 변형하는 4GT(4 Gigabyte Tuning) 옵션입니다. 흔히 /3GB 옵션으로 많이 알려져 있죠. 4GT 옵션이란 사실 매우 간단합니다. 가상 주소 공간의 비율을 [유저 공간 2 : 커널 공간 2] 에서 [유저 공간 3 : 커널 공간 1] 로 바꿔주는 겁니다. 즉, 윈도우에서 사용하는 커널 모드 공간을 1GB 로 줄이고, 이렇게 확보한 공간을 유저 모드 공간에 추가하여 응용 프로그램이 사용할 수 있는 유저 모드 공간의 크기를 3GB 로 늘린 것입니다. 매우 간단하죠?
그런데 이러한 4GT 옵션을 무작정 사용하기도 좀 그렇습니다. 우선 이렇게 유저 모드 공간을 늘리더라도 대부분의 프로그램들은 이렇게 늘어난 3GB 의 유저 모드 공간을 정상적으로 활용하지 못하고, 기존대로 2GB 의 공간만을 사용한다는 겁니다. 왜냐? 해당 프로그램들은 애초에 2GB 의 유저 모드 공간을 사용하도록 만들어졌기 때문이죠.
이렇게 늘어난 3GB 의 유저 모드 공간을 정상적으로 활용하기 위해선 해당 프로그램이 이러한 3GB 공간을 모두 사용할 수 있도록 만들어져야 합니다. 그렇기 때문에 4GT 옵션을 반드시 필요로 하는 프로그램(그것을 지원하도록 만들어진 프로그램)을 사용할 것이 아니라면 4GT 옵션은 적용하나 마나 아무런 필요가 없는 옵션이 되는 것이죠. 그래서 "오홋! 3GB 로 늘리면 응용 프로그램들이 그만큼 더 많은 공간을 사용할 수 있을테니 좋겠네? 나는 무조건 적용해야지!" 할 성질의 옵션은 아니라는 이야기입니다.
다음으로 문제가 되는 게 커널 모드 공간은 커널, 시스템 캐시, Paged Pool, Nonpaged Pool 등, 윈도우의 운영과 관리에 핵심적인 요소들이 사용하는 공간입니다. 4GT 옵션이란 게 이러한 커널 모드 공간을 쥐어짜서 줄여놓은 형태이죠. 그래서 결국 이는 윈도우 운영의 핵심 자원이 줄어든 것이고, 이것은 윈도우에 미처 생각치 못한 악영향을 미칠 수 있습니다. 즉, 응용 프로그램의 메모리 부족이 아닌 윈도우의 핵심적인 운영부에서 메모리 부족 현상이 발생할 수 있는 것이죠.
이러한 이유들로 4GT 옵션의 적용은 신중해야 합니다. 더욱이 만약 시스템의 전체 램 용량이 1~2GB 와 같이 작은 환경이라면 실질적인 효용 가치도 없는 옵션이라고 할 수 있습니다. 아무리 응용 프로그램이 사용하는 유저 모드 가상 주소 공간의 크기를 늘리더라도 실제 램에 이를 올릴 수 있는 공간이 준비되어 있지 않다면 말짱 도루묵일 뿐이기 때문이죠. 그러니 4GT 옵션은 램 용량이 충분한 상황에서(인식 한계까지 램이 장착된 상황에서) 프로그램이 꼭 필요로 할 때만 사용하는 것이 좋습니다.
대략적이었지만 가상 주소 공간에 대해서 정리를 해보았습니다. 어떻게 도움이 되었나 모르겠네요. 여담으로 가상 주소 공간과 가상 메모리(페이징 파일)은 전혀 다른 의미입니다. 헷갈리지 마세요. ^^ 그리고 지금 이야기한 4GT 옵션과 앞서 이야기한 PAE 기술은 전혀 별개의 내용입니다.
마치며...
지금까지 알아본 것과 같이 32비트 윈도우는 실제 메모리의 4GB 인식(관리) 제한에 더해 가상 주소 공간의 4GB 제한까지 있으니, 메모리의 관리에 있어서 만큼은 64비트 윈도우에 비해 확실하게 떨어진다고 할 수 있습니다. 이래저래 프로그램들은 점점 더 고사양화되어가고, 시스템에 장착되는 메모리의 용량은 자꾸 늘어가는 현재의 상황에서 32비트 윈도우가 설 자리는 점점 줄어들고 있는 것이죠.
참고로 위에서 미처 언급을 하지 못했는데요. 64비트 윈도우의 경우 유저 모드 가상 주소 공간의 크기는 무려 8TB 나 됩니다. 커널 모드 공간도 8TB 이고요. 스케일의 차이가 다르죠? 그런데 여기에서 한 가지 알아두셔야 할 것이 이것은 64비트 프로그램에게 주어지는 가상 주소 공간이라는 것입니다. 만약 64비트 윈도우에서 32비트 프로그램을 실행하는 경우에는 기존과 동일하게 2GB 의 유저 모드 공간을 제공해줍니다. 그래도 32비트 윈도우에 비해 더 나은 점이라면 앞서 말한 4GT 기술을 사용할 수 있도록 제작된 프로그램을 실행하는 경우엔 자동으로 4GB 의 유저 모드 공간을 제공해준다는 것입니다. 그래도 이건 나름 괜찮죠?
이러한 연유로 동일한 32비트 프로그램을 사용하더라도 64비트 윈도우가 32비트 윈도우에 비해 좀 더 나은 환경을 보장해준다고 말할 수도 있을 듯 합니다. 물론 가장 좋은 것은 64비트 윈도우에서 64비트 프로그램을 사용하는 것이겠지만요. ^^
어떻게 제가 정리한 내용이 여러분들께 도움이 되었을지 모르겠네요. 윈도우의 메모리 관리 부분이란 게 사실 깊이 들어가면 좀 너무 전문적이고 심란한 부분이 많습니다. 사실 저도 100% 아는 것은 아니고요. 그래도 오늘 글에서 이야기한 정도만 대략적으로라도 알고 계신다면 충분히 도움이 될 수 있을 거라고 생각합니다. 그런데 이러한 구조나 개념적인 부분에 대한 설명은 보다 정확하고 확실해야 하는데, 사실 제가 정리한 내용이 어찌보자면 너무 전문적인 부분인지라 그 의미들을 정확히 맞게 전달하고 있는지 다소 걱정이 되네요. 그래도 대략적인 큰 틀에서 보자면 많이 틀리진 않았으리라 생각됩니다. 그래도 혹시나 모르니 제 설명 중 잘못되었거나 오류가 있다면 알려주시길 바랍니다.
긴 글 읽어주셔서 감사하고요. 다른 글 정리하다가 어떻게 이게 튀어 나오게 되었는지 모르겠네요. 너무 장황하게 나온 듯 싶기도 하고요. 뭐 어쩔 수 없죠. 아무튼, 이번 글은 여기서 마치도록 하겠습니다. 감사합니다. ^^
"컴퓨터에 램이 4GB 이상 달려 있다면 그냥 64비트 윈도우를 설치해서 사용하세요. 그게 정신 건강에 좋습니다."
※ 참고 문서
Sankim's Blog :: 4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트
Sankim's Blog :: Windows 메모리 FAQ
Sankim's Blog :: Windows 메모리 FAQ, 2탄
Ask the Performance Team Blog :: Memory Management 101
Ask the Performance Team Blog :: Memory Management - x86 Virtual Address Space
Mark Russinovich's Blog :: Pushing the Limits of Windows: Physical Memory
Mark Russinovich's Blog :: Pushing the Limits of Windows: Virtual Memory
Microsoft Support :: RAM, 가상 메모리, 페이지 파일 및 Windows의 메모리 관리
Microsoft Support :: 응용 프로그램의 4GT RAM 조정 기능 사용에 대한 정보
Miracle :: Windows 서버 Tunning (Memory)
Microsoft MSDN :: 가상 주소 공간
Microsoft MSDN :: Memory Limits for Windows Releases
Microsoft Technet :: How 4GT Works
Microsoft Technet :: 메모리 바운드 문제 방지
KLDP :: 메모리 관리 (Memory Management)
Sankim's Blog :: 4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트
Sankim's Blog :: Windows 메모리 FAQ
Sankim's Blog :: Windows 메모리 FAQ, 2탄
Ask the Performance Team Blog :: Memory Management 101
Ask the Performance Team Blog :: Memory Management - x86 Virtual Address Space
Mark Russinovich's Blog :: Pushing the Limits of Windows: Physical Memory
Mark Russinovich's Blog :: Pushing the Limits of Windows: Virtual Memory
Microsoft Support :: RAM, 가상 메모리, 페이지 파일 및 Windows의 메모리 관리
Microsoft Support :: 응용 프로그램의 4GT RAM 조정 기능 사용에 대한 정보
Miracle :: Windows 서버 Tunning (Memory)
Microsoft MSDN :: 가상 주소 공간
Microsoft MSDN :: Memory Limits for Windows Releases
Microsoft Technet :: How 4GT Works
Microsoft Technet :: 메모리 바운드 문제 방지
KLDP :: 메모리 관리 (Memory Management)
