Windows 메모리 매니지먼트와 페이지 파일 교환을 통한 32비트 성능 고찰

⇒  News and Blogging, Posted 배우기(Mr.Learn) on 2009년 11월12일 PM 12:12

구독자 평가 : 10/10, 총 1 명이 참여하셨습니다.

 Windows를 사용하다 보면 가끔씩 Windows의 속 안이 궁금할 때가 있다. 이런 이유로 속 안을 들여다 보려고 시도를 하지만, 워낙 전문적이기면서도 방대하기 때문에 적지않은 어려움을 느끼게 된다. 그러나 어렵더라도 한 발 한 발 천천히 그리고 조금씩 다가가다 보면 평상시 궁금하던 점들이 풀리면서 뭔가모를 희열감이 느껴질 때가 있다. 지난 웹로그에서 이미 어느 정도 개념 정립을 했다고 하지만 복습차원에서 다시한번 메모리에 대한 것들을 정리하고 좀 더 Windows의 깊은 곳으로 내려가기를 시도한다.

 Windows 메커니즘을 살펴보면, Windows는 실제 메모리(RAM)와 페이지파일(HDD)을 이용한다는 것을 알 수 있었다. 그리고 실제 메모리를 많이 사용할 때가 하드디스크를 이용할 때 보다 Windows의 퍼포먼스가 좋아진다는 것도 알게 되었다. 즉, 32비트(x86)에서 실제 메모리가 512MB, 1GB, 2GB, 4GB를 장착을 할 경우 하드웨어 예약으로 소비되는 용량은 동일하게 적용이 되지만, 4GB를 장착을 했을 때 가장 많은 메모리의 가용 공간이 확보하게 되기 때문에 메모리의 가용 공간이 많으면 페이지 파일의 사용 빈도가 낮아지고, 이러한 실제 메모리 사용으로 인해서 Windows는 향상된 성능을 발휘하게 된다.

 하드웨어 예약 또는 시스템 예약으로 소비되는 공간은 하드웨어 마다 차이가 나는데, BOIS설정에 따른 변화 그리고 XP, Vista, Seven 각각의 운영체제에 따라 하드웨어 벤더에 의해 제공되는 최적설정이나 기술에 따라서도 차이는 날 수 있다. 그러나 분명한 것은 시스템 예약에서 가장 많은 실제 메모리를 소비하는 것이 그래픽카드이다. 특히 그래픽 카드의 전용 메모리가 128MB, 256MB, 512MB, 1GB 각각 다를 경우 시스템 예약으로 인한 실제 메모리의 소비는 300MB 미만에서 1GB 이상까지도 소비가 된다. 따라서 Windows 클라이언트 기준, 사용자가 32비트의 4GB램을 장착을 했을 경우 실제 메모리의 가용 공간은 대략 3GB에서 3.7GB까지 이용할 수 있다.

 실제 메모리에서 사용자들이 착각하기 쉬운 문제는 Windows는 2GB 혹은 3GB 밖에 인식을 못하므로 4GB램을 장착하면 낭비를 초래한다라는 것이고, 심지어는 4GB에서 1GB나 2GB를 램디스크로 활용을 한다라는 사용자들도 있다. 이러한 잘못된 인식이나 정보는 모두 Windows 내부 메커니즘의 몰이해라고 할 수 밖에 없다. 이미 윈앤위에서 배우기(Mr.Learn)와 함께 Windows 내부 메커니즘에 관심을 가졌던 사용자라면 32비트 시스템에서의 4GB 실제 메모리가 어떻게 사용되는지 재고하는 기회를 갖을 수 있었을 것이고, 불필요한 오해따위는 하지 않을 것이라 생각된다.

 실제 메모리의 가용 공간을 이해할 수 있다면, 이제 우리 사용자들은 또 다른 Windows의 기술적인 부분에 접근을 해야만 하는데, 그것이 바로 가상 주소 공간(Virtual Address SPace)이라는 것이다. 가상 주소 공간은 영문 약칭 VA 또는 VA space라고 사용이 되기도 하지만, Virtaul Memory(가상 메모리)라고도 칭해져서 HDD에 생성되는 pagefile.sys과 혼동될 소지가 있다. Windows의 VA라는 것은 실제 메모리의 용량이 많건 적건 4GB라는 가상 주소 공간이 사용된다. 그리고 이 4GB라는 VA는 각각 2GB씩 분리되어 2GB는 Windows라는 운영체제(커널)가 사용을 하고, 나머지 2GB가 응용 프로그램이 사용을 한다. 이러한 이유로 결국 32비트 시스템에서 응용 프로그램(각 프로세스 당)이 사용할 수 있는 공간은 최대 2GB 밖에 되지를 않는다.

 Windows에서 응용 프로그램을 만든 다는 것은 어린이들이 가지고 노는 레고(LEGO) 블럭처럼 특정 기능을 수행하는 블럭(또는 부속품)들을 짜 맞추는 작업과 매우 흡사하다. 그러나 레고 블럭은 눈으로 보고 직접 만질 수 있기 때문에 자신의 상상력을 발휘하기가 쉽지만, Windows의 블럭(APIs)들은 추상적 논리체계이기 때문에 레고 블럭처럼 쉽지가 않다. 어떤 블럭이 있는지, 어떤 기능을 하는지, 어떻게 사용하는지, 속성 또는 특성을 잘 알고 있어만 상상력을 발휘할 수 있다. 또한 단순한 블럭 개념과 함께 순차적 또는 구조적 프로그래밍 방식 보다는 확장 발전된 클래스(CLASS)와 OOP(Object Oriented Programming)라는 객체(개체) 지향 프로그래밍 기법이 사용된다. OOP에서는 블럭의 특성이나 속성, 상속 특성(property by inheritance)을 파악하고 Windows 내부의 블럭들의 족보도 알아야 한다. 그래야만 상상력대로 프로그밍을을 할 수 있는데, 이러한 모든 것들이 기본적으로 가상 주소 공간내의 유저 모드 2GB 공간내 작동되며, 응용 프로그램들은 Windows의 관리하에 작동이 된다.

 DOS라는 운영체제가 1MB미만의 메모리로 작동되었다는 점을 상기해 보면, 개인적으로 4GB라는 주소 공간은 실로 엄청나게 방대한 공간이라고 생각되는데, 그 만큼 우리 PC 사용자들의 환경이 발전된 것이 현실이다. DOS와 Windows의 큰 차이점 중에 하나는 바로 다중 처리 즉, 멀티 프로세싱(muti processing)이라는 것이다. 메모리는 것이 특정 용량만큼만 가용 공간으로써의 고정된 용량만을 가지고 있기 때문에 A, B, C 등 여러 프로그램들을 동시에 수용할 수 없는 노릇이다. 그래서 마치 책을 보는 현재 보이는 페이지를 위주로 하는 페이징 기법을 사용을 한다. 현재 보고 있는 페이지 외에 다른 페이지들은 감추어 놓는 페이징 기법을 사용하기 때문에 현재 사용자가 실제 작업하는 활성화(포커스가 되는)된 프로그램(프로세스)에는 실제 메모리를 위주로 실행이 가능하도록 하면서 나머지 비활성화된 프로그램은 하드 디스크에 임시적으로 보관을 한다. 실제 메모리가 많다면 굳이 하드디스크에 보관을 할 필요가 없겠지만, 더 많은 프로그램을 실행하면서 시간이 경과됨에 따라 점차적으로 실제 메모리는 고갈되고 하드 디스크의 페이지 파일의 크기는 증가하게 된다. 이러한 상태에서 사용자가 작업전환을 하게 되면 임시적으로 보관되었던 내용들을 다시 실제 메모리로 불리어 올려지고, 실제 메모리에 있던 것은 임시 메모리로 보관되는 페이지 교환이 일어나게 되는데, 결국은 이러한 페이지 교환으로 인해서 Windows의 성능은 현격하게 저하된다.

 Windows가 페이징 기법을 사용하게 됨으로써의 장점은 실제 메모리에 많은 비용을 들이지 않고도 여러 프로그램들을 실행시킬 수 있다는 것이지만, 감당할 수 없는 일정 한계를 넘어서게 되는 결국 Windows를 도저히 사용할 수 없는 지경에 까지도 이르게 된다. 따라서 비용이 들더라도 보다 많은 메모리를 장착을 하게 되면 Windows를 더 오랜시간 쾌적하게 사용할 수 있다.


 상단 이미지는 극단적인 비교이긴 하지만, 실제 메모리가 많음으로 인해서 Windows의 퍼포먼스 저하가 발생하지 않는 경우(상단 좌측)를 보여주는 것이며, 실제 메모리가 부족함으로 인해서 하드디스크로 임시 메모리가 사용되면서 실제 메모리와 하드 디스크 사이에서 스와핑이라는 페이지 교환이 일어나는 경우(상단 우측)을 나타내도록 그림으로 그려 본 것인다.

 사용자가 A, B, C, D라는 프로그램을 실행할 경우 실제 메모리가 많아서 이들 프로그램을 모두 수용을 할 경우는 페이지 교환이 일어나지 않아서 Windows 퍼포먼스 저하 없이 쾌적한 컴퓨팅 작업이 가능하다. 그러나 실제 메모리가 부족한 경우는 임시 메모리로 하드 디스크를 사용하게 되는데, 위의 이미지 처럼 A, B, C, D 4개의 프로그램만을 실행시킬 경우는 그리 큰 차이가 느껴지지 않을지 몰라도 Windows는 이보다 휠씬 많은 프로세스들이 실행이 된다. Windows XP는 적어도 최소한 20개 이상의 프로세스가 기본적으로 실행이 되며, VIsta나 Seven는 대략 30개 이상의 프로그세스가 실행 상태에 놓이게 된다. 백그라운드로 실행되는 프로세스들은 덩치도 작고 메모리 소비량이 비교적 작기 때문에 Windows 전체 퍼포먼스에 주는 영향이 미미하다고 할 수 있지만, 사용자가 실행시키는 포그라운드 프로그램들은 대부분 상당량의 실제 메모리를 필요로 하는 것이 대부분이기 때문에 위의 이미지 보다는 휠씬 많은 수의 프로그램들이 페이지 교환을 시키게 된다. 이렇게 여러 프로그램들을 실행함으로써 창과 창의 포커스의 이동시 갑자기 시스템이 느려지는 현상은 바로 페이지 교환작업으로 인한 성능 저하의 대표적인 경우라고 할 수 있는데, 이러한 현상을 줄이려면 되도록 많은 용량의 실제 메모리를 장착하는 것이 좋다. 그러나 애석하게도 32비트 Windows 클라이언트에서는 실제 메모리(램)가 4GB로 제한이 되어져 있다. 비록 4GB를 제한이 있을지라도 4GB를 장착했을 경우 시스템 예약을 제외한 가장 많은 가용 공간을 활용할 수 있으므로 4GB 램을 장착하는 것이 좋다.

 간혹 인터넷의 글들을 읽어 보면 특이한 사용자들의 글을 읽을 수 있다. 실제 메모리 4GB를 장착을 해서 2GB씩 분리를 해서 2GB나 1GB를 램디스크로 활용을 한다는 것인데, 비교적 작업 시간이 짧은 인터넷 서핑이나 간단한 작업들을 한다면 어느 정도는 효과를 느낄 수 있기는 하겠지만, 4GB를 반으로 줄이게 되면 Windows가 사용할 수 있는 실제 메모리의 가용 공간 역시 반으로 줄어 들어 그리 현명한 사용 방법은 아니다. 가용 공간을 줄인다는 것은 응용 프로그램이 사용할 수 있는 공간을 줄이기도 하지만 Windows가 자체적으로 퍼포먼스를 유지하기 위한 캐시의 활용도를 떨어뜨리기 때문에 좋은 방법은 아니다. 또 가용 공간이 모자르면 하드 디스크의 임시 파일을 자동적으로 만들게 되는데, 굳이 페이지 파일을 램디스크로 만들어 놓을 필요는 없지 않은가? 시스템이 오류를 일으키지 않고 비교적 안정적이라면 아예 pagefile.sys를 0MB(사용 안 함)로 설정을 하면 된다. 이렇게 해서 페이지 파일을 사용하지 않는다면 결국 응용 프로그램들은 실제 메모리로만 작동을 하기 때문에 불필요하게 램디스크와 같은 프로그램을 실행을 해서 메모리를 낭비할 필요는 없다. 따라서 Windows 메커니즘을 잘 아는 사용자라면 실제 메모리를 보다 현명하게 사용할 수 있다것이 된다. MS는 Windows 2000까지만 램디스크 유틸리티를 제공하면서 Windows 자체 캐시성능이 더 효율적이라고 하며, Vista나 Seven에 오면서 부터는 Windows 캐시 성능이 보다 발전을 했고, 추가적으로 슈퍼패치(Superfetch)나 레디부스트(readyboos)와 같은 캐시 기술이 제공된다.