Metro 스타일 앱의 메모리 확보

아티클
04/23/2012

최신 운영 체제의 경우 시스템 리소스를 다른 시각에서 바라봅니다. OS는 폼 팩터와 상관없이 과거보다 더 효율적으로 리소스 사용을 관리하는 것이 중요합니다. 현재, 단일 프로세스에 가용 리소스(메모리, CPU, 디스크 I/O)가 특별한 제약 없이 너무 쉽게 할당되는 경향이 있습니다. 심지어 최종 사용자가 체감하는 전반적인 성능 향상의 효과가 미비한 경우에도 그렇습니다. OS의 역할은 리소스의 균형을 이루고 PC에서 수행하고자 하는 모든 작업을 완료할 수 있도록 하는 것입니다. 대부분의 OS 구현 방식에 존재하는 수동 제어의 경우 이 기능의 상당 부분은 잘못된 소프트웨어 즉, 리소스 소비에 제한을 두고 있지 않는 소프트웨어를 피하도록 설계되어 있습니다. 악성 소프트웨어가 아닌 대부분의 정상적인 소프트웨어의 경우에도 리소스 할당 API의 복잡성은 잘 작동하는 소프트웨어를 만드는 데 제약이 되어 왔습니다. WinRT의 최신 API 집합은 프로그래머들이 PC를 '장악'하지 않고도 작업을 수행하는 소프트웨어를 더욱 손쉽게 만들 수 있도록 설계되었습니다. 이는 모든 PC 폼 팩터와 소프트웨어를 개선할 수 있는 바탕이 됩니다.

이 글에서는 Fundamentals(기반 기술) 팀에서 근무하는 그룹 프로그램 관리자인 Bill Karagounis가 앱이 일시 중지되는 경우에도 메모리를 확보할 수 있도록 하기 위해 시도했던 여러 가지 작업에 대해 자세히 설명하고 개발자가 걱정하지 않아도 이러한 모든 것들을 실현할 수 있는 방법에 대해 이야기합니다.
- Steven

이전 블로그 글에서는 Windows 런타임을 사용하는 Metro 스타일 앱 모델에 대해 논의했습니다. 이 앱 모델의 중요한 특성은 앱이 사용자에게 보이지 않게 되면 일시 중지된다는 것입니다. 백그라운드에서 Metro 스타일 앱을 일시 중지하면 다른 앱을 위해 CPU를 절약하고, 백그라운드 앱이 리소스를 소비하는 작업을 하지 않도록 하여 배터리 수명이 증가하고 반응 속도가 향상됩니다. 이러한 내용은 Sharif Farag와 Ben Srour의 블로그 글인 응용 프로그램을 위한 전력 효율성 향상에 자세히 설명되어 있습니다.

하지만 이러한 앱이 일시 중지되었을 때 이 앱에 할당된 메모리는 어떻게 될까요? 이전에 언급한 바와 같이 실제로 OS가 이를 처리하게 되며, 일시 중지된 프로세스가 있기 때문에 다른 프로세스에서 메모리 부족을 느끼지 못하게 됩니다. 이것이 바로 우리가 중요하게 생각한 설계 방향이었습니다. 하지만 이 모든 것이 어떻게 작동하게 되는지에 대해 여전히 궁금해 하는 분들이 계신 줄 압니다.

Windows 8 Consumer Preview부터 Windows는 시스템의 메모리 부족을 감지할 때마다 일시 중지된 Metro 스타일 앱이 점유했던 거의 '모든' 메모리의 용도를 다시 설정하게 됩니다. Windows 8은 앱을 종료하지 않고도 이 메모리를 확보할 수 있습니다.

현재 브라우저에서는 이 HTML5 비디오가 지원되지 않습니다.

다른 미디어 플레이어로 보려면 이 비디오를 다운로드하십시오.
고화질 MP4 | 저화질 MP4

메모리, 반응 속도 그리고 Metro 스타일 앱

Windows는 모든 종류의 앱(Metro 스타일 또는 데스크톱)에 대해 앱에서 생성한 메모리 요청과 관계없이 해당 앱을 대신하여 실제 메모리 할당을 조정하려고 합니다. Windows는 항상 이러한 방식으로 작동하여 향후 앱 메모리가 필요한 경우를 위해 가용 메모리를 확보합니다. Windows는 앱이 이전에 메모리를 '할당'했더라도 이 앱이 메모리를 사용하려고 하면 실제로 필요한 메모리만 할당합니다. 또한 Windows는 메모리의 페이지가 오랫동안 사용되지 않았으면 앱에서 메모리 일부를 페이징하거나 용도를 변경합니다.

요청 프로세스에 대한 메모리 할당을 거부하는 것이 아니라 사용자가 해당 앱을 실제로 사용할 때까지 실제 메모리 할당을 가능한 한 지연하는 것이 목적임을 이해해야 합니다. 여러 리소스를 사용하면 소프트웨어에서 필요 이상으로 더 많은 메모리를 사용하려는 경향이 있기 때문입니다. OS는 이러한 모든 요청이 합쳐지는 장소이며, 충분한 예상 사용량을 요청하는 모든 경우를 충족시키게 되면 결국 모든 프로세스에 사용될 메모리가 고갈됨을 확인할 수 있는 정보를 갖고 있습니다. 정상적인 시스템 작동이 어렵게 되는 것은 물론이고 시스템이 결국 잠기게 됩니다. 이러한 현상은 RAM 부족 외에도 메모리가 가상인 경우에도 발생하며 사용자의 PC는 디스크 안팎의 페이지를 바꾸게 됩니다.

모든 프로세스에 제때 제공된 실제 메모리는 프로세스의 '작업 집합'으로 참조됩니다. '개별' 작업 집합은 프로세스에 '고유한' 실제 메모리를 의미합니다. 프로세스는 '공유'되는 실제 메모리의 다른 페이지도 사용하므로 일부 프로세스에서 참조할 수 있습니다. 작업 관리자의 프로세스 뷰에서 살펴보면 특정 프로세스의 메모리는 실제로 현재 '개별' 작업 집합입니다. 참고: 편의상 이 블로그에서 '작업 집합'으로 지칭하는 경우 '개별 작업 집합'을 의미합니다.

시스템이 가용 메모리가 부족한 상태로 시작되면 OS는 시스템의 다른 요청을 충족시키기 위해 용도를 변경할 수 있는 실제 메모리 페이지의 모든 프로세스를 살펴보며 필요한 경우 메모리를 페이징하기도 합니다. 데스크톱 앱의 경우 Windows는 앱의 작업 집합에서 가장 중요한(가장 자주 액세스되는) 메모리 페이지를 유지하려고 합니다. 데스크톱 앱은 백그라운드에서 실행되는 경우에도 언제든 코드를 실행할 수 있어야 하기 때문입니다. 이를 통해 적절한 균형을 유지하게 됩니다. 너무 많은 메모리 페이지가 데스크톱 앱에서 제거되면 추가 디스크 I/O로 인해(앱이 자동으로 디스크에 페이지된 메모리를 사용하려고 하기 때문에) 앱의 반응 속도에 영향을 줄 수 있습니다.

Windows 메모리 관리에 대한 자세한 내용은 Mark Russinovich의 "드러난 Windows 메모리 관리의 비밀" 강의: 1부 및 2부를 참조하십시오.

하지만 Metro 스타일 앱은 포그라운드에서 실행되지 않을 때마다 항상 일시 중지된다는 점에서 데스크톱 앱과 다릅니다. 앱이 일시 중지되면 어떤 메모리도 사용하지 않습니다.

이를 설명하기 위해 아래 스크린샷에 작업 집합에서 사용 중인 메모리가 있는 일시 중지된 Metro 스타일 앱 몇 가지를 강조 표시했습니다.

메모리를 사용 중인 일시 중지된 앱

참고: Consumer Preview 빌드에서 일시 중지된 상태는
기본적으로 작업 관리자의 프로세스 뷰에서 표시되지 않습니다. 이를 표시하려면
보기 메뉴의 옵션을 통해 표시하도록 선택해야 합니다.

시스템 메모리가 부족하지 않은 경우 일시 중지된 앱의 작업 집합에 메모리를 남겨 두면 되므로 가장 효율적입니다. 하지만 시스템 메모리가 부족한 경우 Metro 스타일 앱을 일시 중지하여 앱을 종료하지 않고도 이러한 작업 집합의 거의 모든 메모리를 다른 앱에서 사용할 수 있도록 전환할 수 있습니다.

일시 중지된 Metro 스타일 앱의 메모리 확보

Windows 8 Consumer Preview에서는 시스템에서 메모리 부족을 감지한 경우 추가 메모리를 확보하기 위해 일시 중지된 Metro 스타일 앱의 전체 (개별) 작업 집합을 디스크에 효율적으로 기록할 수 있습니다.

이러한 프로세스는 특정 앱을 최대 절전 모드로 전환한 다음 사용자가 다시 이 앱으로 전환하면 앱이 재개되는 것과 유사합니다. 우리는 Metro 스타일 앱의 일시 중지/재개 방식을 활용하여 앱의 작업 집합을 비우거나 다시 채우도록 하였습니다.

이벤트의 순서는 아래에 설명되어 있습니다.

1. PLM(프로세스 수명 관리자)는 시스템에서 메모리 부족을 감지하고, MM(메모리 관리자)에게 일시 중지된 Metro 스타일 앱에 대한 특정 프로세스의 작업 집합을 비우도록 요청합니다.

1. MM은 앱의 작업 집합에서 운영 체제의 수정된 페이지 목록(다시 사용하기 전에 디스크에 기록할 콘텐츠가 들어 있는 메모리 목록)으로 메모리 페이지를 이동합니다.

1. 수정된 페이지 목록의 작업 집합 페이지는 일반적인 MM 정책(백그라운드에서 우발적으로 기록되며 메모리 부족이 있는 경우 쓰기가 트리거됨)에 따라 비동기식으로 기록됩니다.

1. 일시 중지된 앱 작업 집합이 디스크에 기록된 후에도 프로세스에서 제거된 메모리 페이지는 운영 체제의 대기 목록에 그대로 남아 있습니다. 이는 필요한 경우 다른 앱을 위해 용도를 변경할 수 있는 메모리의 유용한 페이지 캐시입니다. 원래 프로세스에서 이러한 페이지를 바로 사용해야 하는 경우 원래 위치로 바로 이동됩니다.

작업 집합 페이지가 수정된 페이지 목록 또는 대기 목록의 실제 메모리에 있을 때 사용자가 앱으로 다시 전환하면 페이지가 다시 앱의 프로세스로 바로 추가됩니다. 더 이상 사용할 수 없는 경우 Windows는 디스크에서 앱의 작업 집합을 최적화된 방법으로 읽어 옵니다.

'메모리 확보' 수행

이 작업이 어떻게 수행되는지를 잘 알아보기 위해 실제 실행 코드를 예제로 사용하여 설명하겠습니다.

최초 상태는 위의 스크린샷에 나타난 것과 같습니다. RAM이 2GB인 PC에서 Metro 스타일 앱 몇 가지를 실행했습니다. Metro 스타일 앱은 백그라운드에 있으므로 Windows에서는 이 앱을 일시 중지합니다. 그런 다음 시스템에서 메모리 사용률을 올리고 새 기능을 수행하도록 하기 위해 더 많은 앱을 열었습니다.

아래의 스크린샷에서 추가적인 메모리 부족 현상을 유도하고 위에서 설명한 동작을 유발하기 위해 몇 가지 앱을 열어 놓았음을 확인할 수 있습니다. 보시는 바와 같이 Windows는 일시 중지된 Metro 스타일 앱의 작업 집합(강조 표시됨)을 비웠습니다.

Metro 스타일 앱의 작업 집합이 비워짐

원래 Metro 스타일 앱의 작업 집합에 대한 '이전' 상태와 '이후' 상태를 비교해 보겠습니다. 작업 관리자에 실행된 앱 27개를 모두 표시할 수 있는 공간이 모자라서 "이후" 상태가 보이지 않는 앱이 있을 수 있습니다.

Metro 스타일 앱	이전 작업 집합(MB)	이후 작업 집합(MB)
Flixster	23.5	0.5
Flow	15.2	0.6
Kindle	23.1	0.5
LiveComm	3.8	0.3
Lyrics	65.3	0.9
지도	28.1	0.8
원격 데스크톱	21.0	0.5
SkyDrive	23.1	0.5
스토어	26.9	0.6
날씨	42.0	0.8
Windows 뷰어	9.2	0.4

이 예제에서 일시 중지된 앱을 종료하지 않고도 다른 앱에서 사용할 수 있는 물리적 RAM을 250MB 이상 확보했습니다.

작업 집합을 다시 읽어 들일 때의 반응 속도

새로운 기능에 대한 테스트는 작업 집합 콘텐츠를 비운 후 앱으로 다시 전환하려는 경우 일시 중지된 앱이 얼마나 빠르게 반응하는지를 알아봅니다.

이 테스트를 실행하는 동안 응답 속도를 확인하기 위해 "Lyrics" 앱을 사용했습니다. Lyrics 앱은 뮤직 비디오를 재생할 뿐 아니라 노래 가사도 표시합니다. Lyrics 앱을 백그라운드로 전환하면 일시 정지되고 재생이 중지됩니다.

작업 집합이 비워지는 지점으로 메모리 사용을 유도한 후 다른 앱들을 추가로 열고 한동안 시스템을 사용하다가 Lyrics 앱으로 다시 전환하면 디스크에서 작업 집합을 읽도록 했습니다. 그런 다음 Lyrics 앱(아래)으로 다시 전환되도록 했습니다.

Lyrics 앱의 작업 집합이 다시 채워짐

제가 살펴보려고 했던 핵심 지표는 앱을 다시 전환하여 소리를 다시 들을 수 있는 지점까지 도달하는 데 걸리는 시간이었습니다. 메모리 부하가 높은 로엔드급 컴퓨터에서는 디스크에서 작업 집합을 읽어 오는 앱으로 다시 전환할 경우 작업 집합이 메모리에 있는 경우와 비교하면 반응 속도에서 큰 차이를 느낄 수 없습니다. 하지만 이동 거리는 달라집니다. 작업 집합이 클수록 디스크에서 읽어 오는 데 걸리는 시간은 길어집니다. Metro 스타일 앱의 경우 디스크에 기록해야 하는 양을 지속적으로 줄여 나가고 있으며 이 기능을 더 최적화하려고 노력하고 있습니다.

이 기능은 Consumer Preview 릴리스를 사용하는 모든 사용자들이 직접 시도해 볼 수 있습니다. Metro 스타일 앱과 데스크톱 앱을 몇 개 열어 놓고 메모리 부족 상태가 되도록 한 다음 작업 집합이 비워진 일시 중지된 Metro 스타일 앱으로 다시 전환하기만 하면 됩니다.

참고: Windows는 메모리가 위험 범위에 도달하면 Metro 스타일 앱을 닫습니다. 하지만 이 기능을 사용하면 해당 지점에 도달하기 전에 시스템에서 더 많은 응용 프로그램을 실행할 수 있도록 할 수 있습니다.

작업 집합에서 읽기 최적화

사용자가 디스크에 작업 집합이 있는 일시 중지된 앱으로 다시 전환할 때 빠르게 반응하도록 하기 위해 우선 작업 집합을 쓰는 방법을 최적화하여 가능한 한 디스크에서 작업 집합을 효율적으로 읽어 올 수 있도록 했습니다.

일시 중지된 Metro 스타일 앱의 작업 집합을 기록할 때 작업 집합 페이지는 디스크에 순서대로 기록됩니다. 이렇게 하면 적은 수의 대용량 순차 디스크 읽기로 데이터를 프로세스로 읽어 들일 수 있습니다. 아래 스크린샷은 평가 및 배포 키트(ADK)의 일부로 제공되는 WPA(Windows 성능 분석기) 도구에서 가져온 것으로 이 프로세스 중의 디스크 읽기를 시각적으로 나타내고 있습니다. 작업 집합 '읽어 오기' I/O를 강조 표시했습니다. 앱의 작업 집합을 다시 채우면서 순차 스트림을 명확히 확인할 수 있습니다.

앱의 작업 집합을 다시 채우기 위한 순차 읽기 I/O(WPA 도구)

거의 대부분의 저장 장치에서 순차 데이터를 매우 빠르게 읽어 옵니다. 대부분의 회전 디스크는 초당 50-100MB 사이가 될 수 있습니다. 저장 장치가 플래시 기반(예: SSD)인 경우 이러한 읽기가 초당 200MB 이상이 될 수 있습니다.

여러 앱에서 일시 정지된 앱의 작업 집합을 메모리로 가져오는 시간이 보조 I/O의 1초보다 적게 걸릴 것으로 예상합니다.

결론

모든 다양한 폼 팩터의 PC에서 실제로 사용 가능한 메모리는 한정되어 있습니다. 더 많은 메모리를 요청하는 더 많은 프로그램을 실행 중인 경우라면 실제 메모리를 더 추가한다고 해도 메모리 관리 문제가 항상 뒤따르기 마련입니다.

최신 소프트웨어의 일부 클래스, 예를 들어 대용량 RAW 이미지의 사진 편집, 인메모리 데이터베이스, 아주 큰 스프레드시트 등은 더 많은 메모리를 사용하도록 진화하게 될 것입니다. 이러한 것들이 WinRT 기반 구현이든 데스크톱 구현이든 OS는 끊임없이 늘어나는 메모리 요청을 관리할 수 있도록 진화해야 합니다. WinRT는 프로그래머들이 반응 속도 면에서 사용자를 우선 고려하여 작업을 완료할 수 있으면서도 필요한 모든 메모리에 액세스할 수 있도록 해 주는 API를 사용할 수 있는 기회입니다. Windows 8 Consumer Preview에서 이 기능을 체험해 보시길 바랍니다.

- Bill Karagounis

다음을 통해 공유