Sankim's Blog : Kernel

Windows 7, W2K8 Server R2(Version 6.1) & 32bit와 64bit 최대 메모리

sankim — Wed, 04 Nov 2009 06:56:00 GMT

안녕하세요? Sankim 입니다.

오늘은 Windows 7, Windows Server 2008 R2 그리고 32bit/64bit 최대 지원 메모리(RAM)에 대해서 간단히 정리해 보기로 하겠습니다.

Windows 7과 W2K8 Server R2(Version 6.1) 최대 메모리

[Windows 7 최대 물리 메모리]

: Windows 7 클라이언트 버전에서 32Bit는 최대 4GB 메모리, 64bit는 192GB 메모리까지 사용 가능합니다. Starter Edition은 기본적으로 2GB이하 메모리를 가진 H/W를 위한 Edition이므로 2GB로 제한 되었습니다.

에디션(SKU)	32Bit 최대 메모리	64bit 최대 메모리
Windows 7 Ultimate	4 GB	192 GB
Windows 7 Enterprise	4 GB	192 GB
Windows 7 Professional	4 GB	192 GB
Windows 7 Home Premium	4 GB	16 GB
*Windows 7 Home Basic	4 GB	8 GB
Windows 7 Starter	2 GB	2 GB

[Windows Server 2008 R2 최대 물리 메모리]

: Windows Server 2008 R2 서버 버전에서는 최대 2TB까지 가능합니다.

*에디션(SKU)	64bit 최대 메모리
Windows Server 2008 R2 Datacenter	2 TB
Windows Server 2008 R2 Enterprise	2 TB
Windows Server 2008 R2 for Itanium Based	2 TB
Windows Server 2008 R2 Foundation	8 GB
Windows Server 2008 R2 Standard	32 GB
Windows HPC 2008 R2	128 GB
Windows Web Server 2008 R2	32 GB

* Windows Server R2에서는 32bit 버전은 출시되지 않았습니다.

이전 Windows 버전에 대한 메모리 정보는 ‘Windows 최대 메모리 크기(Size)’를 참조 하여 주십시오.

32/64Bit 최대 메모리

[Windows 32bit 최대 메모리]

32bit CPU에서는 서버 버전에 한해서 최대 64GB까지 가능합니다. 클라이언트트 4GB로 제한 되어 있습니다.

SKU	Edition	최대 메모리
*Server 버전	Windows Server 2008 Enterprise & Datacenter 32bit	64GB
Client 버전	Windows 7 Ultimate & Enterprise 32bit	4GB

*Windows Server 2008 R2는 32bit이 존재하지 않으므로 서버 버전에서는 제외 했습니다.

**32bit Windows Client의 최대 지원 메모리에 대한 내용은 ‘4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트’를 참조하여 주십시오.

[Windows 64bit 최대 메모리]

SKU

Edition

최대 메모리

Server 버전

Windows Server 2008 R2 Enterprise & Datacenter 64bit

2TB

Client 버전

Windows 7 Ultimate & Enterprise 64 bit

192GB

(* Windows Vista는 128GB)

그리고 Memory FAQ 2가지..

1. 'Windows 최대 메모리 크기(Size)'라는 글을 보면 서비스팩 별로 지원 되는 최대 메모리가 단계적으로 올라가는데 왜 그런가요?

: 윈도우가 처음부터 32bit 198GB, 64bit 2TB까지 지원 가능한 구조였을까요? 물론 이론적으로 가능하지만 처음부터 Windows가 그런 대용량의 메모리를 지원할 수는 없었습니다. 왜냐하면 그 사양의 메모리가 있어야 그것에 맞게 설계하고 테스트 할 수 있어야 하는데 구현하기 위한 H/W가 없는데 윈도우 혼자서 만들 수는 없기 때문입니다. 그래서 H/W의 장착 가능한 Memory 용량이 단계적으로 발전할 때 마다 동시에 Windows가 서비스 팩 시점에 맞춰 최대 메모리를 확장 해왔다고 보시면 좋을 것 같습니다.

2. 64bit Windows를 사용하면 프로그램도 64Bit처럼 사용할 수 있나요?

: 아닙니다. 64bit CPU에 64bit OS가 설치되어야 64bit Computing을 하기 위한 환경이 구성되고 여기에 64bit 메모리 환경을 활용할 수 있는 64bit 프로그램(대용량 메모리를 사용할 수 있도록 설계된)을 구동해야 진정한 64bit Computing이라 할 수 있습니다. 즉 ‘x64 CPU + 64bit Windows + x64 응용프로그램’이어야 진정한 64bit Computing을 하는 것입니다. 자세한 내용은 'Windows 64bit Computing’에 대한 오해 혹은 잘못된 상식'을 참고 하십시오.

p.s. Address Space Limitation 항목도 그림과 함께 만들어 보려고 낑낑 댓는데, 이거 영~ 조잡해서 안되겠군요.. 그림 잘 만들어지면 다음 블로그에 올리도록 하겠습니다. 혹시 그림판(mspaint.exe)으로 그림 좀 멋지게 만드는 방법 아시는분 ? … ㅜㅜ

윈도우 7 메모리 덤프 생성 과정 변경

sankim — Tue, 27 Oct 2009 08:29:00 GMT

안녕하세요? Sankim입니다, 오늘은 제목이 좀 건조 합니다.

이번 포스팅에서는 Windows 7에서 변경된 메모리 덤프(Memory dump) 생성 프로세스에 대해서 말씀 드릴까 합니다. 다 읽으시고 나서는 Windows 7을 기점으로 지금까지 생각지도 못한 세밀한 부분들까지 새로운 PC환경을 위해 능동적으로 변화하고 있다고 느끼(?) 실지도 모르겠습니다.

[블루스크린] 블루스크린이 왜 파란색인지 궁금하시면 여기를 클릭하세요.

Windows 사용자라면 애석하게도 블루스크린을 한번씩 경험해 보셨을 거라 믿습니다. 블루 스크린이란 윈도우의 커널 모드에서 문제(Crash)가 발생하면 화면상에 Crash가 발생했음을 알리는 블루스크린을 띄우면서 시스템 드라이브(보통 C 드라이브 루트 폴더)에 있는 페이지파일(pagefile.sys) 파일에 메모리 내용을 쓰게 됩니다, 그 뒤에 부팅하면서 덤프가 저장된 이전 pagefile.sys로 C:\Windows 폴더에 메모리 덤프 파일인 memory.dmp를 생성합니다. Dump(덤프)라는 의미가 어떤 매체의 데이타를 다른 종류의 매체로 옮긴다는 의미를 가지고 있는데, 블루스크린이 발생하면 숫자가 1%에서 100%까지 옮겨 가는 것을 볼 수 있죠? 이것이 바로 메모리에 있는 데이터를 하드디스크에 있는 Pagefile.sys에 옮기는 과정을 나타내는 것 입니다.

[메모리에서 Memory.dmp로 가는 과정]

윈도우에서 어떤 작업을 하기 위해서는 실행 데이터가 메모리에 올라와 있어야 하는데 이 때문에 memory.dmp에는 당시 윈도우가 문제 시점에 어떤 일들이 벌어 지고 있는지를 확인할 수 있는 아주 중요한 단서를 가지고 있습니다. 그래서 이 memory.dmp 파일을 분석하여 문제(Crash)가 발생한 원인을 찾아 해결 합니다.

[WinDBG를 이용해 디버깅 중(?)..]

덤프에는 메모리에 있던 모든 내용을 모두 dump하는 전체덤프(Complete dump), 메모리에서 커널(Kernel) 관련 내용만 dump하는 커널덤프(Kernel dump)가 있고 덤프에 대한 간략한 정보만을 담은 작은 메모리 덤프(Mini dump)가 있습니다. 만약 메모리가 2GB를 넘어가면 아래 그림에서처럼 전체덤프 옵션을 사라지고 커널덤프와 미니덤프만 남습니다, 그러나 사용자가 필요하다면 레지스트리 변경으로 전체덤프 생성이 가능합니다. 시스템 Crash(블루스크린이 나타난 경우 보통 이렇게 부릅니다)이 발생한 경우 대부분 커널덤프로 분석하지만(당연히 Kernel에서 문제니까) 경우에 따라서 Application Mode가 커널모드(Kernel Mode)에 영향을 주어 시스템 Crash를 야기하는 경우가 있어 드물지만 전체 덤프가 필요한 경우가 있습니다. 몇 년 전만해도 대용량의 전체덤프가 필요할 때 때 이것을 어떻게 받아내서(마치 산고를 거쳐 한 생명을 받아내듯이..) 그걸 어떻게 원격에 가져가 분석할지에 대해서 고민한적이 있었는데요.. **요즘이야 워낙 하드디스크가 커져서리..

[디버깅 정보 쓰기] ‘덤프 유형 확인은 제어판 > 시스템 > 고급 시스템 설정 > 시작 및 복구’에서 확인 가능합니다.

덤프의 유형이 ‘전체 덤프’로 설정 되어 있으면 ‘실제 페이지 파일(Pagefile.sys) 크기 + 300MB’의 크기의 memory.dmp 파일이 생성 되는데. 요즘 대부분의 PC나 노트북의 경우 2GB 정도의 메모리가 기본으로 장착 되어 있기 때문에 2GB의 메모리가 있다면 2.3GB 정도의 memory.dmp 파일이 생성 됩니다, 혹은 커널 덤프라고 해도 수백 메가바이트가 되기도 합니다. 아무리 요즘 하드디스크가 대용량화 되었다고 해도 이런 크기는 무시 못할 것입니다, 게다가 넷북과 같은 경우 PC만큼 넉넉한(?) 용량을 가지고 있지 못하기 때문에 큰 부담이 될 수 있습니다. 이에 Windows 7에서부터는 하드디스크에서 부담을 줄이고자 메모리 전체 덤프와 커널덤프 파일 생성 여부를 아래와 같이 변경 하였습니다.

[메모리 덤프 생성 여부 순서도]

결론부터 말씀 드리면 위 순서도의 결론은 4GB 이상의 여유 공간이 존재 하지 않는 한 메모리 덤프를 생성하지 않는다는 것입니다. 이것은 하드디스크의 공간이 충분하지 않은 상태에 Memory.dmp 파일이 생성되어 시스템 리소스를 차지 하는 것을 막겠다는 의도 입니다.

위 표를 정리 해보죠.

① 먼저 레지스트리 AlwaysKeepMemorydump값이 1로 되어 있으면 무조건 메모리 덤프 파일을 생성합니다. 아래 덤프를 만들기 위한 조건에 관계하지 않고 무조건 메모리 덤프를 생성 합니다. 경로는 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl 입니다, 기본적으로는 없는 값이므로 필요하면 만드셔야 합니다.

② 만약 Windows가 Windows Server 2008 R2 이상이면 무조건 메모리 덤프 파일을 생성합니다. 기업에서 서버로 사용하는 제품에 문제가 생겼는데 덤프 분석이 필요할 가능성이 높겠죠? 그래서 더 볼 것 없이 W2K8 R2에서는 무조건 덤프를 생성 합니다. 이전에 말씀 드렸듯이 Windows 7과 Windows Server 2008 R2는 동일한 커널을 가지고 있으며 이번에 새로 적용된 룰은 이 둘에게만 해당 됩니다.

③ 만약 Windows 7 이상 클라이언트가 도메인에 Join 되어 있다면 무조건 메모리 덤프 파일을 생성한다. 도메인에 Join되어 있다는 의미는 기업 고객일 가능성이 높고, 고객 기업이라면 덤프 발생시 클라이언트라도 덤프 분석이 필요한 가능성이 높기 때문입니다.

④ 도메인에 조인 되어 있지 않다면 하드디스크의 여유 공간이 4GB 이상인지 확인 한다, 만약 4GB 이상이면 메모리 덤프 파일을 생성 하지만, 그렇지 않다면 생성하지 않습니다.

자~ 그럼 전체덤프와 커널덤프 말고 미니덤프(Minidump)는 어떨까요? 이전에는 시스템 Crash가발생할 때마다 Minidump폴더(보통 C:\Windows\Minidump)에 MiniMMDDYY-nn.dmp 파일(MMDDYY는 월/일/연도) 이름 형식으로 미니덤프가 쌓였었습니다, 미니덤프와 다른 덤프의 차이점은 크기가 작다는 점 이외에 다른 전체/커널덤프들은 만약 덤프가 발생하면 이전에 있던 memory.dmp위에 덮어 씁므로써(Overwrite) 복수의 덤프 파일이 생성되지 않지만 미니 덤프파일의 경우 계속해서 발생일 표시인 MMDDYY과 뒤에 nn의 이름을 바꿔가며 생성됩니다. 그래서 Windows 7에서 부터는 레지스트리 MinidumpsCount 값으로 최대로 만들어 질 수 있는 미니덤프 값을 조정 할 수 게 되었습니다. MinidumpsCount는 레지스트리 경로 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl에서 볼 수 있으며 기본 50개로 설정 되어 있습니다.

Windows 7에서는 지금까지 말씀 드린 덤프 파일과 같이 디스크 크기(Disk Footprint)를 줄이기 위한 노력 이외에도 정말 여러 방면에서 OS를 가볍게 해서 빠른 Performance를 내기 위한 눈물겨운(?) 노력을 기울였는데요, 앞으로 계속해서 소개하도록 하겠습니다.

**생각해 보니 HDD는 커졌지만 메모리도 너무 많이 커져서.. 램이 512GB인데 이걸 전체 덤프로 받으려면..

그럼 모두 가을을 만끽 하시길 빌며 저는 이만~ :^^

Thanks talee

p.s. 아~ 역시 전 미적 작업에 있어서는 감각이 떨어지나 봅니다.. 위에 간단해 보이는 순서도 하나 만드는 것이 글 쓰는 시간이랑 비슷했어요.. ㅜㅜ

누구 레드 스크린(Red Screen) 보신 분 안계세요???

sankim — Mon, 21 Sep 2009 05:19:00 GMT

이전에 '윈도우의 블루스크린은 왜 파란색일까?'라는 포스팅에서 블루스크린이 파란색(Blue)이 된 사연을 설명 드린 적이 있었습니다. 그런데 이후에 댓글로 블루스크린 뿐만 아니라 레드 스크린(Red Screen)을 보셨다는 제보가 있어 사실 유무를 확인 해 보았습니다.

사실 Windows 기술 지원을 꽤 오래 해왔음에도 레드스크린 이라는 것을 한번도 본적이 없던 터라 반신 반의 했었는데 Research 중 'Sorting it all Out' 블로그에서 실제 Red Screen을 캡쳐한 화면을 볼 수 있었고 그 이외에도 검색을 해 보면 레드스크린 관련된 KB 문서와 실제로 사진으로 찍은 화면까지 볼 수 있었습니다.

!!! 진짜 레드 스크린이...!!!

확인 결과 컴퓨터를 부팅할 때 부팅을 관리 하는 부트 매니저(Boot Manager)단에서 유효한 엔트리(Valid Entry)를 찾지 못할 경우 Windows는 레드스크린 함께 에러 메시지(Valid Error Message)를 보여 줍니다. 일반적인 사례들을 보면 원인의 대부분이 BIOS나 디스크와 관련이 있지만 다행히 재부팅으로 문제가 해결됩니다. 혹시 재부팅 해도 문제가 해결 안되고 레드스크린에서 디스크 관련 문제라는 메시지를 뿌려 주면 한번 복구콘솔에서 ‘chkdsk /p /r’를 실행해 보시기 바랍니다, 해결 가능성이 있습니다..

그럼 오늘도 좋은 하루 되시고요 앞으로 다가올 가을의 향취를 만끽하시길 바랍니다~ :)

*10월5일 업데이트: 이번 추석에 windows 7에서 몇가지 테스트를 하다 Boot Manager 단에서 Crash를 발생 시켜보았는데, Windows 7에서는 레드 스크린이 나타나지 않고 마친 콘솔처럼 검은색 바탕에 하얀 글씨로 Windows Vista와 동일한 모습의 메시지가 나타났습니다.

p.s. 개인적으로 바뻐서 블로깅이 뜸합니다.. ^^;;

Windows 성능 옵션(프로그램 vs 백그라운드 서비스)을 이해하다

sankim — Wed, 10 Jun 2009 06:45:00 GMT

Windows NT부터 Windows 7에서 까지 ‘시스템 속성 > 성능 > 설정 > 성능 옵션 > 고급 > 프로세서 사용 계획’에 ‘프로그램’과 ‘백그라운드 서비스’ 옵션 두 가지 중 하나를 사용자가 선택할 수 있습니다. 이 두 개의 옵션에 대해서 여러 의견(?)들이 난무하는데요, 이번 포스팅에서는 이 두 가지 옵션이 어떤 의미를 가지는지 그리고 여러분은 어떤 상황에서 두 옵션 중 하나를 선택할 것인지를 설명 드릴까 합니다.

[그림 1. Windows 7, 프로세서 사용 계획]

잘못된 오해
많은 분들께서 이 옵션에 대해서 아래와 같이 잘못 이해하고 계십니다.

{‘프로그램’은 실제 사용자가 실행하는 응용 프로그램이고 ‘백그라운드 서비스’는 ‘서비스 관리자(services.msc)’에서 실행되는 서비스를 의미한다. 그래서 프로세서 사용계획의 설정에 의해 ‘프로그램’을 선택하면 사용자 프로그램에 더 많은 CPU 사용량을 할당하고 ‘백그라운드 서비스’를 선택하면 서비스(Service)에 더 많은 CPU 사용량을 할당한다} => NO, NO, NO 이렇게 이해하고 계시면 안됩니다.

진실을 말씀 드리겠습니다.
(이 옵션을 이해하기 위해서는 먼저 스레드와 컨텍스트 스위치 두가지 개념을 이해하셔야 합니다 그래서 이 단어의 정의를 설명드리면서 옵션을 이해하도록 하겠습니다)
우리가 사용하는 프로그램이란 것은 알고 보면 실행 파일이 프로세스(Process)로 만들어 진 후 스레드(Thread)에서 명령이 실행되는 것 입니다, 여기서 스레드란 명령어가 CPU를 사용하여 실행되는 단위로 정의 할 수 있습니다. (그밖에 많은 복잡한 이야기들이 있지만 여기서는 이정도 까지만 이해하시면 되겠습니다)

우리가 컴퓨터를 사용할 때 우리는 모르지만 네트워크 처리, HDD 처리, 커널에서의 작업, 응용프로그램 처리 등등 너무나도 많은 작업들이 동시 다발적으로 이뤄지고 있습니다. 다른 예로, 사용자가 인터넷에서 파일을 다운로드 하면서 Word와 WMP를 함께 사용하는 경우도 생각해 볼 수 있습니다. 이러한 것들은 모두 스레드 단위로 작업이 이뤄지며 작업에 따라 스레드 처리 시간이 길수도 짧을 수도 있습니다.

일상 생활에서도 금방 끝나는 일이 있고 오래 걸리는 일들이 있듯이 스레드도 처리 하는데 시간이 긴 작업과 짧은 작업들이 섞여 있는데 만약 그림처럼 CPU에서 하나의 스레드가 끝날 때까지 다른 스레드들은 기다려야 한다면 스레드 A가 끝날 때 까지는 스레드 B, C는 기다리고만 있어야 할 것 입니다.

[그림 2]

위 그림 2처럼 하나의 스레드가 자신의 명령이 끝날 때가지 계속 CPU 독점해서 사용한다고 하면 오랜 시간 동안 다른 스레드들(프로그램)이 실행되지 못할 것입니다, 그렇게 되면 다른 프로그램의 성능에 영향을 주겠죠? 특히 스레드 B의 입장에서는 잠시 CPU를 사용하면 금방 끝날 일인데 앞에서 스레드 A의 작업이 끝나기를 기다려야 하니 답답한 노릇일 것입니다.

그래서 좀더 효율적으로 동시 작업이 가능 하도록 하나의 스레드가 시작해서 끝날 때까지 무작정 CPU를 사용하는 것이 아니고 그림 3. 처럼 스레드의 실행 시간을 짧은 시간 단위로 잘라낸 뒤 순서대로 세워 놓고 실행하다 자신에게 할당된 시간이 끝나면 하던 일을 멈추고 다음 스레드에게 CPU를 사용할 수 있도록 한 뒤 다시 자기 차례가 돌아오면 자신의 일을 다시 합니다. 스레드가 CPU를 얼마 동안 사용할지를 정의한 시간 단위를 바로 퀀텀(Quantum)이라고 합니다. 그러면 그림에서처럼 스레드 B는 다음 순번에서 바로 작업을 끝낼 수 있습니다. (그림 3의 ‘A B C A B C A C A C A A A’ 순서를 보시면 이해가 좀 쉬우실 것입니다)

[그림 3]

이 퀀텀을 사용자가 길게도 혹은 짧게도 설정 할 수 있는데 이것이 바로 ‘프로세스 사용 계획 옵션’입니다. 그래서 ‘프로그램’으로 설정하면 모든 스레드의 퀀텀을 짧게(6, 대략 2 Click) 설정하고 반대로 ‘백그라운드 서비스’로 설정하면 길게(36, 대략 12 Click) 설정 합니다.

그렇다면 퀀텀(스레드 실행 시간)을 짧게 혹은 길게 설정 하는 것은 어떤 차이가 있을까요?

차이와 그에 따른 장단 점을 이해 하시려면 Context Switch라는 의미를 이해 해야 합니다.

[그림 4, Context Switch]

그림 4.와 같이 퀀텀에 정의된 시간이 끝나 CPU를 떠나야 하는 스레드 A는 CPU를 떠나기 전에 자신이 어디까지 작업을 했는지를 저장합니다, 그래야 다음 차례에 다시 A가 실행될 때 앞에서 마지막으로 진행했던 부분부터 다시 시작 할 수 있기 때문입니다, 또한 B는 자신이 앞에서 실행 했던 부분부터 다시 시작 하기 위해 앞에서 저장했던 실행정보를 불러옵니다, 바로 이런 일련의 작업을 컨텍스트 스위치(Context Switch)라고 합니다.

이 Context Switch 자체는 미약(?)하기는 하지만 전체적으로 보면 성능에 영향을 줄 수 있는 작업입니다. 그래서 만약 다른 작업은 거의 없고 CPU에서 스레드를 처리하는데 긴 시간이 필요한 단일 응용프로그램(SQL Server 혹은 그래픽 랜더링 작업 같은)만 실행하는 환경이라면 ‘백그라운드 서비스’로 설정해 Context Swith를 최소화하고 해당 프로그램의 스레드가 긴 시간 CPU를 사용 할 수 있도록 하는 것이 효과적일 것입니다.

반대로 일반 사용자의 컴퓨터 사용 패턴은 아주 소소한 아이콘 클릭 같은 작업을 포함해 IE같은 웹 브라우저 사용과 함께 음악을 듣는 것과 같이 동시에 여러 프로그램을 실행하는 패턴을 보입니다. 이런 경우 스레드에 긴 시간을 주면 스레드가 끝나기를 기다리는 시간이 오래 걸리기 때문에 다른 작업으로 넘어가는데 시간이 걸려 반응속도를 늦출 수 있지만, 일정한 시간 내에 여러 스레드들이 실행 될 수 있도록 퀀텀을 작게 설정하면 사용자 측면에서 반응속도를 높일 수 있습니다..

두 옵션은 아래와 같이 정의 할 수 있습니다
프로그램: 여러 작업을 동시에 수행하는 일반 사용자 환경에서 쾌적한(?) 반응 속도를 보여준다.
백그라운드 서비스: 계속해서 한가지 작업을 실행하는 응용프로그램을 실행 하는 경우 높은 처리 효율을 가진다.
* 이 두 옵션을 그 반대의 환경에 설정하였다면 반드시 나쁘다고는 말할 수 없겠지만 성능 효율면에서는 떨어질 것입니다.

그래서 기본적으로 Windows 2000 Professional, XP, Vista그리고 Windows 7과 같이 일반 사용자를 위한 Windows 클라이언트에서는 ‘프로그램’으로 설정 되어 있으며 Windows Server 2000, 2003, 2008에서는 ‘백그라운드 서비스’로 설정 되어 있습니다. 만약 윈도우 클라이언트지만 그래픽 랜더링 작업 같이 CPU를 많이 사용하는 하나의 작업을 주로 사용하는 환경이라면 ‘백그라운드 서비스’를 선택 할 수 있을 것이고 반대로 윈도우 서버지만 클라이언트 환경같이 사용한다면 ‘프로그램’ 옵션을 선택하면 성능에 효과적일 것입니다.

조금 자세한 추가 설명
‘프로그램’으로 설정 되어 있으면 스레드는 2 Clock interval 기간 동안 실행이 가능하며 ‘백그라운드 서비스’는 12 Clock interval 기간 동안 실행할 수 있습니다.

퀀텀에서는 Clock interval의 3배수로 설정됩니다, 그래서 ‘프로그램’으로 설정 되어 있으면 Short 값인 6(‘실제 Clock 2개’ x 3배수)을 가지고, ‘백그라운드 서비스’로 설정 되어 있으면 퀀텀 Long 값인 36(‘실제 Clock 12개’ x 3배수)을 가집니다. 그래서 클럭인터럽트가 걸릴 때마다 퀀텀 값을 3단위로 줄여가 결국 0이 되면 일단 그 스레드가 이번에 실행될 시간은 모두 끝내고 기다리고 있던 다음 스레드가 실행 되도록 합니다.

이해를 돕고자 상당 부분 단순화 썼습니다. 좀더 자세한 정보가 필요하신 분들께서는 아래 Windows Internals의 Thread 부분을 참고 하시기 바랍니다.

[참고문서]
Windows Internals 4’th, Chapter 6, Controlling the Quantum

4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트

sankim — Thu, 21 May 2009 04:29:00 GMT

지난 ‘Windows 메모리 FAQ’에서 Windows 메모리에 대한 이야기를 드렸는데요, 특히 Windows 클라이언트의 4GB 제한에 대해서 여러분들의 아주 뜨거운(?) 반응이 있었습니다. 그래서 지난 번에 약속 드린 ‘Easy Transfer를 이용한 마이그레이션’은 다음 포스팅으로 미루고 오늘은 ‘4GB 제한의 진실, 32비트 Windows 클라이언트‘라는 주제로 Q&A 형식으로 이야기를 나누도록 하겠습니다.

Q1) 왜 Windows 클라이언트는 4GB까지만 지원하나요?

1. Windows XP가 처음 출시된 초기만 해도 4 기가 바이트(GB) 메모리라는 게 서버에서도 거의 사용되지 않는 고사양의 메모리였으므로 4GB를 이상 지원을 고려할 필요가 없었습니다. (당시는 일반적으로 사용하는 서버의 메모리가 512MB 혹은 그 이하였던 시절 이였습니다, 64MB 서버도… ^^)

2. Windows XP SP2가 출시될 시점에 윈도우 클라이언트도 4GB 메모리 필요성의 조짐이 보였습니다, 그래서 당시 Windows 개발팀에서는 윈도우 클라이언트에서 4GB 이상 메모리 지원을 검토하였습니다.

3. 그런데 윈도우 클라이언트에서 4GB 이상의 메모리를 관리(Memory Management)하면 블루스크린(Crash), 시스템 행(System Hang), 부팅이 되지 않거나 혹은 비디오 카드 같은 장치의 드라이버 문제로 장치를 인식하지 못하는 문제가 빈번하게 발생하는 것을 볼 수 있었습니다. (대부분 Memory corruption)

4. 원인은 윈도우 클라이언트를 위해 만들어진 3'rd Party 디바이스 장치 드라이버(Driver)가 4GB 이상 메모리 환경을 고려하지 않고 만들어졌기 때문에 발생한 문제였습니다.

5. 이런 장치 드라이버 호환성 문제를 피하기 위해 윈도우 클라이언트(XP, Vista, 7)에서는 4GB까지만 메모리 관리(Memory Management)를 할 수 있도록 한 것 입니다.

Q2) 4GB메모리가 전부 보이지(인식)되지 않고 3(.xx)GB 정도로 보여요, 왜 그런가요?

아래 그림은 제 Windows 7에서 시스템 정보(msinfo32.exe)를 실행시켜 얻을 결과입니다, 실제 설치된 메모리는 4GB지만 윈도우가 이용할 수 있는 실제 메모리는 3GB로 인식하고 있습니다.

하나 더 아래 그림은 작업 관리자에서 나타난 값입니다, 마찬가지로 실제 메모리를 3GB 정도만 인식하고 있는 것을 볼 수 있습니다.

결론부터 말씀 드리면 이 현상의 원인은 컴퓨터의 칩셋(Chipset)과 연결된 장치(비디오 카드, Lan 카드 같은)가 가지고 있는 메모리 때문에 실제 장착된 메모리보다 적게 나타나는 것입니다. 윈도우는 '실제 메모리'에 나타난 '전체' 크기 만큼의 메모리만 사용할 수 있므며(즉 위와 같은 경우에는 전체 4GB를 사용하지 못합니다) 이는 하드웨어 이슈 입니다. 이와 연관있는 디바이스 요소로는 System BIOS, Motherboard Resources (I/OxAPIC), Memory Mapped I/O, PCI Express Configuration Space, Additional PCI Device Memory (Graphics Aperture), VGA Memory 등이 있습니다.

[이유는 아래와 같습니다]

어려운 이야기가 될 수 있으니 쉬운 이해를 위해 먼저 아래 그림을 보시죠. 시스템이 시작할 때 Physical Address Map(이하 PAM)이라는 걸 만듭니다, PAM은 RAM과 각 장치들이 가지고 있는 메모리의 주소 정보로 일종의 '순서' 혹은 '차례'를 만들어 Windows에게 넘겨줍니다, 그러면 Windows는 PAM 범위의 메모리만 사용(Access) 할 수 있습니다.

그런데 PAM이 만들어 질때 메모리(RAM)만 가지고 만드는 것이 아니고 모든 종류의 장치가 가진 디바이스 메모리(비디오 카드, Lan 카드가 가지고 잇는 메모리를 칭함)까지 포함합니다, 처음에는 RAM만 가지고 PAM을 만들어 가다는 중간에 디바이스 메모리가 끼어들게 됩니다, 그러면 PAM 중간에 디바이스 메모리가 포함되고 다시 PAM에 추가되다만 나머지 RAM이 PAM에 추가 되는데 이때 추가된 RAM이 4GB 범위 밖에서 만들어집니다. x86 Standard Memory management Mode를 사용하는 32-bit Windows는 4GB 메모리 영역까지만 사용(Access) 할 수 있는데 디바이스 메모리 때문에 RAM이 4GB 범위 밖으로 밀려나 해당 범위의 메모리가 보이지 않게 되는 것입니다.

위 그림은 총 4GB메모리 환경에서 디바이스 메모리가 총 500MB이기 때문에 사용할 수 있는 총 메모리가 3.5GB로 줄어든 예입니다. 밀려난 500MB는 윈도우가 Access 할 수 없는 영역이기 때문에 사용할 수 없습니다. 이 이슈는 하드웨어에서 해결해야 할 이슈입니다. (이전에 사용한 '문제'라는 표현은 오해를 가져 올수 있어 '이슈'로 변경하였습니다, 여기서 하드웨어란 칩셋을 의미합니다 )

*참고로 32비트 Windows 서버 관련한 4GB 제한에 대한 이야기는 이전에 ‘누가 내 메모리를 훔쳤나?’라는 글로 포스팅한 적이 있습니다, 서버에 관심 있으신 분들은 참고로 읽어 보시기 바랍니다.

Q3) 정말 디바이스 장치들이 메모리 중간에 끼어 들어 메모리가 밀려났는지를 어떻게 해야 볼 수 있죠?

이전에 어떻게 해야 볼 수 있을까 고민 많이 했는데(디버거 봐야 하나.. 등등 ^^;) 의외로 장치 관리자(devmgmt.msc)에서 간단하게 보실 수 있었습니다. 아래 내용은 32비트 클라이언트뿐만 아니라 64비트와의 비교를 보여드리기 위해 제 테스트 머신에 듀얼 부팅으로 Windows Vista 32비트와 64비트를 설치해 테스트를 진행하였습니다.

32 비트 Windows 클라이언트

아래 그림은 32비트 Vista 작업 관리자(taskmgr.exe)에서 보이는 Physical Memory의 모습입니다, 4GB를 장착했지만 전체가 3.3GB정도가 나옵니다.

그렇다면 ‘작업 관리자’가 말하는 Windows가 실제 인식한 Physical Memory 범위는 어떤 모습일까요? 아래 그림은 Meminfo.exe를 이용하여 Windows가 실제 인식하는 Physical Memory 범위를 출력한 결과입니다. (meminfo는 전에 소개해 드렸던 Windows Internals 5’th Edition을 쓴 Alex Ionescu가 만들었습니다)

메모리를 표기할 때 16진수로 표현하고 이를 00000000~FFFFFFFF로(0MB에서 4GB)로 표현합니다. 위 결과를 보시면 Physical Memory 범위가 ‘00001000~0009F000’과 ‘00100000~CFDFF000’ 두 범위로 나눠져 있으며 대략 3.4GB 정도의 크기 입니다.

그럼 두 범위에 중간에 빠진 ‘0009F000~00100000’과’CFDFF000~FFFFFFFF’ 사이 영역은 왜 Windows에서 인식하지 못한 것 일까요? 앞에서 말씀 드렸듯이 디바이스가 해당 영역을 점유해 윈도우가 사용(Access)할 수 있는 메모리가 아니기 때문입니다.

디바이스가 점유한 모습은 ‘장치 관리자(devmgmt.msc)’를 통해 확인 하실 수 있습니다, ‘장치 관리자(devmgmt.msn) > 보기 > 리소스(연결별) > 메모리’를 선택합니다, 그러면 아래 그림과 같이 비디오 카드 Radeon X13000이 ‘D0000000~DFFFFFFF’(대략 268MB)과 ‘FE900000~FEAFFFFF’(대략 2MB) 영역, 즉 Physical Memory 범위에서 제외되었던 곳에 자리 잡고 있음을 확인 할 수 있습니다.

32비트에서는 4GB에서 밀려난 메모리를 볼 수 없습니다, 그럼 밀려난 나머지를 보기 위해 우리 64비트를 살펴보도록 하죠~

64비트 Windows 클라이언트

아래는 64비트 Vista 작업 관리자(taskmgr.exe)에서 보이는 Physical Memory의 모습입니다, 4GB 모두 보입니다.

Meminfo로 본 Physical Memory 범위입니다, 64비트라 Address 범위부터가 다르죠? Memory Address가 4GB를 넘고 메모리 또한 4GB 범위 모두 나타납니다.

장치 관리자에서 본 모습입니다.

32비트에서 본 것과 마찬가지로 위 빨간 박스의 부분은 268MB정도 되고 아래가 2MB정도가 됩니다. 중간에 비디오 카드가 끼어 들었지만 4GB 이후 주소인 '0000000100000000~000000012C000000(실제 메모리 5GB 쯤의 자리)'에서 나머지 720896KB(대략 720MB)를 인식한 것을 볼 수 있습니다. 즉 디바이스가 메모리를 4GB 영역 밖으로 밀어냈다고 해도 128GB까지 인식하는 64bit Addressing 때문에 문제없이 모든 Physical Memory가 보입니다.

처음에 드렸던 예로 이런 상황에서 64비트를 그림으로 표현 하면 아래와 같습니다.

Q4) 그럼 32비트 클라이언트가 4GB 이상을 사용(Access, Addressing)하려면 어떻게 해야 할까요?

정답은 32비트 클라이언트는 4GB 이상을 사용할 수 있는 방법이 없습니다, 4GB 이상 메모리의 사용이 필요하다면 64-bit Windows 클라이언트를 사용하십시오.

현재는 32-bit 환경에서 64-bit 환경으로 넘어가기 위해서는 우선 64비트로의 인식전환이 필요할 것입니다. 다음으로 64비트 전용 응용프로그램들이 많이 나와야 할 것 입니다, 32비트 응용프로그램을 에뮬레이션 하기 위한 WOW 64 Subsystem이 있기는 하지만 모든 응용프로그램에 호환성을 보장하지 않고 32비트 응용프로그램 구조상 64비트 Windows에서 실핼 할 때 64비트가 제공하는 무한(?)한 메모리를 이용할 수 없는 제한이 있습니다.

*64비트 윈도우와 응용프로그램에 대한 이야기는 예전에 포스팅 한 글이 있습니다, 읽어 보시고 추가적인 이해에 도움이 되셨으면 합니다.

Windows 64bit Computing에 대한 오해 혹은 잘못된 상식
http://blogs.technet.com/sankim/archive/2007/12/28/windows-64bit-computing.aspx

Q5) Windows XP를 보면 PAE를 지원하는데 이는 XP도 PAE를 사용하면 4GB 이상을 사용할 수 있다는 의미 아닌가요?

Windows XP SP2 부터 나온 DEP(Data Execution Prevention)를 사용하기 위해서는 기본적으로 PAE가 활성화(Enable)되어 있어야 합니다, 그래서 PAE 기능을 활성화 할 수 있도록 한 것입니다. 이는 Windows Kernel에서 32bit에서는 존재하지 않는 64bit PTE table의 field를 이용하기 때문입니다.

To use these processor features, the processor must be running in Physical Address Extension (PAE) mode. However, Windows will automatically enable PAE mode to support DEP. *해당 문서를 보시려면 여기를 클릭하세요.

참고로 PAE를 활성화 하는 경우와 반대의 경우 윈도우가 시작 시 로드하는 커널 파일은 아래와 같습니다.

CPU 수에 따른 환경	기본	PAE 활성
Uniprocess(단일 CPU)	Ntoskrnl.exe	Ntkrnlpa.exe
Multiprocess(다중 or 코어 CPU)	Ntkrnlmp.exe	Ntkrpamp.exe

Q6) 번 외 질문인데요, 도구마다 메모리 측정 결과가 각기 조금씩 다른 경우가 있어요 왜 그렇죠?

위 그림에서 작업관리자는 3.3인데 왜 meminfo는 3.4냐고 반문하실 수도 있습니다 또한 제가 종종 받는 질문 중 하나가 작업 관리자에서 ‘사용가능’ 항목과 성능 모니터에서 ‘Available %메모리%’의 값이 다르다는 것입니다. 이는 각 도구마다 메모리를 계산하기 위한 항목 수집 기준이 조금씩 달라서입니다, 크게 차이가 나는 것이 아니므로 이번 포스팅에서는 무시하셔도 좋습니다. 언제 작업 관리자에 나온 항목에 대한 자세한 설명을 드리겠습니다. (약속만 드리고 지키지 못하는 것들이 많지만 이번 약속은 꼭!!)

그럼 여러분 좋은 하루 되세요~

* 이전에 댓글에 추가로 명시 했습니다만 '장치 메모리', 혹은 'MMIO'라고만 명시 한것에 대해서 모호하다는 의견이 있어 본문 내용과 하단 부분에 함께 추가 합니다. ^^ 4GB 전체 사용하지 못하는 이슈에 영향을 끼치는 디바이스 요인으로 System BIOS, Motherboard Resources (I/OxAPIC), Memory Mapped I/O, PCI Express Configuration Space, Additional PCI Device Memory (Graphics Aperture), VGA Memory *등(헥헥헥..)이 있습니다. 그러나 말씀안드려도 이들 모두 '장치 메모리'의 범주 임을 알 수 있는 센스~!

[참고자료]
Pushing the Limits of Windows: Physical Memory, Written by Mark Russinovich *이번 포스팅의 대부분의 아이디어가 이 글에서 나왔습니다, 꼭 한번 읽어 보시기 바랍니다.
Windows Internals, Chapter 7 Memory Management
Intel 64 and IA-32 Architectures Software Developer’s Manual, Intel 64 and IA-32 Architectures

Windows 메모리 FAQ

sankim — Mon, 11 May 2009 12:10:00 GMT

안녕하세요~ sankim 입니다.

최근 들어 여러 Windows 관련 커뮤니티나 블로그를 방문하면서 가장 많이 눈에 뜨이는 질문이면서도 정확한 답을 얻기 어려운 것이 Windows 메모리 관련 질문들인 것을 보았습니다. 그래서 메모리 관련해서 가장 많이 올라오는 질문들에 대해서 간단한 답을 정리해 보았습니다. 자세한 기술적 내용은 꼭 한번 시리즈(?)로 올릴 것을 약속 드립니다. ^^

Windows Memory FAQ

1. Windows에서 사용 할 수 있는 최대 메모리(Windows Maximum Memory Size) 크기는 얼마인가요?

현재 나와 있는 Windows 클라이언트는 Vista Ultimate의 경우 32-bit OS는 4GB, 64-bit는 128GB 이며 Windows 서버 Windows Server 2008 Enterprise는 32-bit는 64 GB, 64-bit는 2 TB입니다. 자세한 사항은 여기를 누르시면 각 Windows 별 최대 메모리를 확인 할 수 있습니다.

2. XP, Vista와 같은 32-bit Windows Client에서 4GB 이상 메모리를 사용할 수 있는 방법은 없나요?

32-bit Windows Client(Windows 2000 Professional, XP, Vista)는 메모리 4GB까지만 인식합니다, 4GB 이상의 메모리를 사용하고 싶으신 분들께서는 64-bit Edition을 사용하시거나 혹은 Windows Server 제품을 이용하셔야 합니다. 개인적으로 4GB 이상 사용하는 방법에 대한 Tip이나 Trick이 있다는 글들을 본적이 있는데 모두 근거가 없거나 실제 메모리가 확장되어 사용하는 방법이 아닌 것으로 보입니다.

3. Windows Client에서 메모리 4GB를 설치 했는데 Windows에서 4GB로 보이지 않고 3.xxGB로 보여요

실제 장착된 물리 메모리를 OS가 인식하기 위해서는 그 메모리 정보를 H/W가 Windows에게 알려줘야 합니다, 그런데 PCI Bus, BIOS 그리고 비디오 카드 등에서 사용하는 PCI Bus, BIOS 그리고 비디오 카드 등에서 사용하는 MMIO가 Windows에서 인식하기 위한 물리 메모리 공간 중간에 끼어 들면서 MMIO 크기만큼 실제 메모리가 밀려나 버리게 됩니다, 그래서 윈도우는 밀려난 실제 메모리 영역을 인식하지 못한 나머지 영역만을 실제 메모리로 인식해 실제 메모리보다 적은 양을 사용하게 됩니다. 이는 하드웨어 이슈 입니다.

*경우에 따라 Windows Vista에서 4GB를 장착하였는데 3.12GB로 나오는 경우가 있습니다 이는 디바이스 드라이버 호환성 문제를 피하기 위해 Vista가 의도적으로 3.12GB로 설정 하는 것입니다.

자세한 사항은 아래 링크를 참조 하십시오.
http://blogs.technet.com/sankim/archive/2007/05/31/4gb.aspx

4. Windows Vista SP1(Service Pack 1)을 설치 하니 3.xxGB 보이던 메모리가 4GB로 나타납니다.

Windows Vista Service Pack 1에서부터는 실제 메모리의 정보를 직접 BIOS에서 가져와 시스템 정보에서 보여 줍니다, 그러나 BIOS 호환성에 따라 지원 되지 않을 수도 있습니다.

위 그림에서 왼편 Memory (RAM)에는 4GB라고 나오지만 오른편 실제 사용할 수 있는 Physical Memory에는 3061(3.0GB)이라고 나타납니다. 이렇듯이 Windows Vista SP1을 설치 하면 작업 관리자 등에서 4GB 전체를 보실 수 있습니다만 MMIO로 인한 메모리 사용의 제한은 그대로 받게 됩니다.

자세한 사항은 아래 포스팅을 참조 하십시오.
http://blogs.technet.com/sankim/archive/2008/01/31/windows-vista-service-pack-1.aspx

Windows 7에서는 리소스 모니터를 통해 이것을 비주얼 하게 보여 줍니다.

5. 메모리를 64-bit로 확장해 준다는 PAE 옵션은 무엇인가요?

32-bit 윈도우가 사용할 수 있는 4GB 메모리 한계를 최대 128GB 까지 확장해주는 기술입니다.

1) X86 CPU(Processor)를 사용하는 32bit 운영체제의 최대 메모리는 2^32(32bit)로 4GB 입니다.
2) 과거에 4GB는 엄청난 크기였지만 세월이 흐르면서 데이터베이스 같이 큰 메모리가 필요한 응용프로그램들이 나타났습니다. (제가 처음 지원했던 Windows NT의 메모리가 128MB였던 걸로 기억합니다)
3) 그래서 CPU(Processor) 회사는 컴퓨터가 사용할 수 있는 물리 메모리 영역을 아주 크게(36Bit로) 확장 할 수 있는 PAE라는 기술을 만들어냈습니다.
4) Windows는 CPU가 제공하는 이 PAE 기술을 이용하여 4GB 메모리 크기의 한계를 극복 할 수 있게 되었습니다.
5) Windows가 CPU에서 제공하는 PAE를 사용하기 위해서는 boot.ini에서 /PAE 옵션을 추가 합니다. Windows Vista 이상 환경에서는 ‘bcdedit /set [{해당 윈도우GUID}] pae ForceEnable’을 실행 합니다.
6) PAE로 확장된 상태라도 AWE(Address Windowing Extensions) 함수를 이용하지 않는다면 PAE로 확장된 메모리 모두를 Application이 모두 사용 할 수 없습니다 그러나 OS가 file Cache Data등으로 사용합니다.
7) XP, Vista와 같은 Windows Client에서는 PAE를 사용해도 4GB 이상으로 확장되지 않습니다

PAE를 사용하는 경우 CPU의 MMU(Memory Management)가 Virtual address에 Page directory pointer를 추가(three-level page table)하는 방식으로 필드를 4개로 나눠 메모리를 확장합니다.

[Virtual Address(x86)의 경우]

[PAE 활성화된 Virtual Address(x86)의 경우]

6. /3GB 옵션은 무엇인가요?

4GT 기술이라고 하는데 흔히 /3GB 옵션이라고도 부르며 응용프로그램에 더 많은 메모리를 할당하기 위한 기술입니다.

x86 컴퓨터에서 사용되는 기술로써 가상 메모리 공간 4GB를 둘로 나눠 2 GB는 System Space, 2GB는 User Space에 할당 합니다. System Space는 시스템이 이용하는 리소스(System cache, hyperspace, system cache, page pool 등)에 할당 하고 User Space는 사용자 응용프로그램(응용프로그램, 데이터 등)이 사용하는 공간 입니다. 만약 /3GB 옵션을 추가하게 되면 System Space에는 1GB를 할당하고 User Space에는 나머지 메모리 공간을 할당하게 됩니다. 그러면 응용프로그램이 사용할 수 있는 메모리 크기가 증가되어 응용프로그램에서 더 많은 메모리를 사용 할 수 있는 것입니다. 그러나 시스템 리소스가 많이 필요한 경우 /3GB로 System Space에 1GB만 할당하기 때문에 시스템 리소스의 부족으로 성능 저하를 가져 올 수 있습니다. 그러므로 무조건 /3GB를 할당 할 것이 아니라 충분한 모니터링 후 사용 여부를 결정해야 합니다.

[왼쪽은 일반 2GB, 2GB 모델, 오른쪽은 /3GB 모델]

쉽게 쓴다고는 했지만 아무래도 이해하기 쉽지 않은 부분입니다, 위에서 약속 드린 것 처럼 나중에 꼭 한번 메모리 구조에 대해서 포스팅 하도록 하겠습니다.

* 윈도우 클라이언트의 4GB 제한에 대해서 좀더 자세히 설명 드리기 위해 '4GB 제한의 진실, 32비트 Windows (XP, Vista, 7)클라이언트 '라는 포스팅을 올렸습니다. 참고하여 주십시오.

p.s. 그리고, 아~ 휴가 다녀 왔더니 의욕 충천입니다! 휴가 중에 저 정말 회사 와서 일하고 싶었어요.. 믿어 주세요..

p.s. 2 어제 저녁 퇴근하기 전 급히(?) 적다가 숨겨진 실수가 있어 바로 잡았습니다. 바로 찝어내주신 Talee 군에게 감사 드립니다. ^^

메모리 사용 계획(LargeSystemCache) 옵션

sankim — Mon, 19 May 2008 07:42:48 GMT

시스템 등록 정보 > 고급 > 성능 옵션 > 메모리 사용 계획에서 보실 수 있는 프로그램과 시스템 캐시에 대한 내용입니다.

이 옵션은 Windows Kernel에서 System Cache를 Large System Cache로 설정 할지를 선택하는 옵션입니다. 해당 설정은 Registry HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Memory Management\LargeSystemCache에서 수동으로 설정이 가능합니다.

기본적으로 Client OS(XP, Vista)는 Default(0) 값으로 설정 되어 있고 Server OS는 LargeSystemCache(1)로 설정되어 있습니다.

해당 옵션은Windows Vista와 Windows 2008에서 없어졌습니다(GUI로 설정할 수 있는 방법은 없습니다), 설정을 원하시면 해당 Registry 값에서 LargeSystemCache 값을 0 or 1로 변경합니다.

Desktop Heap 문제

sankim — Mon, 28 Apr 2008 16:36:34 GMT

오늘은 듣기에 조금 생소하실 Desktop Heap에 대해서 말씀드리도록 하겠습니다.

여러분들이 실행하는 응용프로그램이 띄우는 Window 하나 하나가 모두 Desktop Heap이라는 메모리 공간을 가지게 됩니다 이를 Desktop Heap Allocation이라고 하며 사용자가 새로운 Windows, Menus, toolbars등을 생성할때마다 user32.dll과 gdi32.dll에 의해 이루어지게 됩니다.

Desktop Heap에 의해서 나타나는 문제 현상은 아래와 같습니다.

1. 응용프로그램을 실행시키면 한 참 뒤에서야 해당 프로그램의 Window가 나타난다. (2~30초 에서 늦으면 3분)
2. 시스템 응답 속도가 느려지거나 메모리와 관련된 문제라고 의심이 드는 현상이 발생한다.
3. 작업 관리자(Taskmgr.exe)를 실행하면 탭(응용프로그램, 프로세서, 서비스, 성능 등..)들 중에 나타나지 않는 텝이 있거나 혹은 메뉴 일부가 나타나지 않는다.

대부분 잘못된 프로세스에 의해서 Desktop Heap이 고갈되면서 나타나며 특히 3번 현상이 나타나면 백발 백중 Desktop Heap 문제라고 보시면 됩니다.

Desktop Heap 문제 발생 에러

Desktop Heap 문제를 프로세스를 찾아 내는 방법이 있기는 하지만 조금(?) 복잡하고 아주 길어지는 이야기라 블로그에서는 Skip하기로 하고 Workaround로 Desktop Heap 크기를 조절해서 문제를 최대로 피하는 방법을 설명 드리겠습니다. Desktop Heap은 아래와 같은 구성 영역들로 이뤄집니다.

Total Desktop Heap size (48MB) =
    win32k.sys (8MB)
    + Session Working Set (4MB)
    + Mapped views for the session (20MB)
    + Paged Pool for this session (16MB)

*그러나 Terminal Service가 enable되어 있을 경우, desktop heap allocation 가능크기는 20MB(default)으로 변경됩니다, 그래서 Terminal Service 환경에서 Desktop Heap 이슈가 발생할 확률이 높습니다.

Desktop Heap 문제가 있을 경우아래 두 가지 Registry key를 이용해 Desktop Heap 크기를 증가시킬 수 있습니다, 증가는 16MB씩 증가시켜야 합니다.

- SessionViewSize (default: 20MB)를 증가시키면 "Mapped views for the session" Size가 증가
- SessionPoolSize (default: 16MB)를 증가시키면 "Paged pool for this session" size가 증가

* Windows 2000 SP4 이하 버전에서는 kb318942 fix를 설치한 후에 위 설정을 적용합니다, 단 Windows 2000 SP4 Update RollUp 1이나, 그 이후의 Windows버전에서는 이미 적용되어 있어 별도 Hotfix를 적용할 필요가 없습니다.

그러나 여기에는 상충관계가 존재합니다. 즉, SessionViewSize를 많이 증가시키게 되면, System Cache and/or System PTE for threads 공간을 그만큼 사용하게 만들어 그 영역의 문제를 유발할 수 있습니다. 즉 하나의 파이를 어떻게 나누느냐에 따라 누구는 큰 파이를 먹게 되고 누구는 남이가져간 양 만큼 파이의 크기가 적어지듯이 한정된 리소스에서 기본적으로 하나를 증가시키면 다른 하나의 영역이 감소하게 됩니다, 그러면 줄어든 영역에서 또 다른 문제가 발생할 수 있습니다. 그러므로 너무 지나치게 증가시키지 않도록 조심 하십시오.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management 에서 Registry Key]

SessionViewSize - the desktop heap when Terminal Services enabled. (Default 20MB on NT/2K. Default 48MB on XP/2003)

SessionPoolSize - the session pool space when Terminal Services enabled. (Default 16MB)

SystemViewSize - the desktop heap when Terminal Services disabled. (Default 48MB)

SessionImageSize - the address space where the Win32k.sys file and the NT4 print drivers are loaded. (Default 8 MB)

* 이론적으로 32bit 환경에서 이 값의 합은 512MB를 초과할 수 없으며, 대부분의 설정에서는, 450MB정도를 기록합니다.

p.s. 바쁘다 보니 이제 알았네요.. 요즘 따뜻한 봄 바람이 분다는 걸..

Dave Culter, Father of the Windows kernel

sankim — Fri, 29 Feb 2008 12:29:00 GMT

Windows kernel의 아버지 Dave Culter 입니다.

DEC에서 VAX/VMS, RSX-11M, VAXELN을 만들었으며 당시 빌게이츠 회장의 삼고초려로 1988년 10월 마이크로소프트로 옮겨와 마이크로소프트 최초의 서버 OS인 Windows NT 3.1을 만들게 됩니다. 당시 Windows NT 개발을 총괄하였으며 지금까지 Windows Kernel의 아버지라 불립니다.

동영상에서 느껴지듯이 상당히 터프하고 열정적인 분입니다. 동영상에서는 Sr. Distinguished Engineer라고 나오는데 현재는 Technical Tellow라는 직책에 있습니다. 얼마 전 Windows의 X64 포팅 작업을 주도했었습니다.

외부에 드러내는 것을 꺼리시는 분이라 조금은 레어한 동영상이 아닐까 싶습니다. ^^

David Cutler
http://www.microsoft.com/presspass/exec/techfellow/Cutler/default.mspx

Windows Vista Service Pack 1 에서는 실제 장착된 물리 메모리를 확인 할 수 있다

sankim — Thu, 31 Jan 2008 14:53:54 GMT

예전에 Windows에서 실제 물리 메모리중 일부가(100~700MB 정도) 인식되지 않는 현상에 대해서 ‘누가 내 메모리를 훔쳤나’라는 제목으로 포스트 한적이 있었습니다.

지금까지는 시스템이 온라인 되어 있는 상태에서는 MMIO 때문에 실제 Machine에 장착된 실제(Physical) 메모리의 크기를 확인하기 어려웠습니다. 그러나 Windows Vista Service Pack 1 부터는 실제 메모리의 정보를 직접 BIOS에서 가져와 시스템 정보에서 보여 줍니다, 그러나 BIOS 호환성에 따라 지원 되지 않을 수도 있습니다.

그림 1 시스템 등록정보에 보이는 메모리 크기와 작업관리자에 나타난 메모리 크기

그림을 보시면 왼쪽편의 '시스템 등록정보/Memory' 항목에서는 SP1을 설치 하기 전에는 3060MB로 표시 되었던 메모리가 4.00GB로 모두 나타나는 것을 볼 수 있습니다. 그러나 장착된 메모리 정보를 보여줄 뿐이지 오른쪽 작업 관리자의 'Physical Memory/Total'에서 나타난 것과 같이 32-bit OS에서 MMIO에 의한 메모리 사용량 제한은 그대로 유지 됩니다.

앞으로 나올 Windows Server 2008에서도 동일합니다.

[참고문서]

Notable Changes in Windows Vista Service Pack 1 Release Candidate

http://technet2.microsoft.com/WindowsVista/en/library/005f921e-f706-401e-abb5-eec42ea0a03e1033.mspx?mfr=true

With SP1, Windows Vista will report the amount of system memory installed rather than report the amount of system memory available to the OS. Therefore 32-bit systems equipped with 4GB of RAM will report all 4GB in many places throughout the OS, such as the System Control Panel. However, this behavior is dependent on having compatible BIOS, so not all users may notice this change.

오랜만에 짧은 포스팅 입니다 ^^

Windows 64bit Computing에 대한 오해 혹은 잘못된 상식

sankim — Fri, 28 Dec 2007 05:08:49 GMT

[오해]

Windows는 진정한 64bit Computing을 할 수 없다.

_혹은_

x64 Processor만 있으면 64bit 컴퓨팅이 가능하다.

X86 Processor에 64bit Windows를 설치하면 64bit 컴퓨팅이 가능하다.

x64 Processor에 64bit Windows를 설치하면 어떤 응용프로그램이든 64bit 컴퓨팅이 가능하다.

[답변]

한번쯤은 Windows 64bit 컴퓨팅에 대해서 위와 같은 궁금증이 있으셨을 거라 믿습니다. 그럼 Windows 64bit Computing에 대한 잘못된 오해 혹은 편견을 벗겨 보도록 하겠습니다. (여기서 설명 드리는 내용은 x64뿐만 아니라 Itanium Processor도 포함됩니다)

x64가 진정한 64bit computing이 아니라는 오해는 환경적으로 64bit computing이 가능하게 구성되어 있느냐 혹은 아니냐의 차이에 의한 것입니다. X64가 진정한 64bit computing을 하기 위해서는 ‘X64 Processor + Windows x64 edition + 64bit Application‘ 환경이어야 합니다.

64bit processor에 64bit OS가 설치되어야 실질적으로 64bit computing하기 위한 리소스(메모리 2TB 사용 가능) 환경을 만들 수 있고 여기에 이 64bit 리소스를 활용할 수 있는 64bit Application(대용량 메모리를 사용할 수 있도록 설계된)이 설치되어야 진정한 64bit Computing이라 할 수 있습니다. 예를 들어 ‘x64 Processor + Windows Server 2003 x64 edition + x64 SQL Server 2005’이라면 64bit Computing을 하는 것입니다.

즉 Processor + OS + Application이 64비트를 지원해야 완전한 64bit Computing이 가능합니다. 64bit computing의 핵심이라 할 수 있는 확장된 최대 사용메모리를 사용하기 위해서는 위 3가지 조건을 모두 만족해야 합니다. 만약 세가지중 한가지라도 64bit를 지원하지 않는다면 진정한 64bit computing을 할 수 없습니다.

(예)

x64 Processor + x64 Windows + 64bit application => 64bit Computing

x64 Processor + x64 Windows + 32bit application => 해당 application 단에서 WOW64를 이용한 32bit Computing

x64 Processor + x86 Windows + 32bit application => OS단에서 32bit Computing

x86 Processor + x64 Windows + 64bit application => 불가능(Windows가 설치 조차 되지 않습니다)

x64에서 32bit 응용프로그램이 구동 될 수 있는 이유는 x64에서는 WOW64 라는 subsystem을 이용하여 일종의 시뮬레이터와 같이 32비트 응용프로그램을 구동합니다. 이런 경우 32bit Application은 32bit Computing을 하게 되고 하나의 Subsystem을 거치기 때문에 성능도 떨어지게 됩니다 또한 경우에 따라서 정상적으로 구동하지 않는 경우도 있을 수 있습니다.

커널 라이브 디버깅을 위한 Remote Live Debugger 설정 하기

sankim — Mon, 20 Aug 2007 09:35:00 GMT

이번 Post는 바로 원격에서 커널 디버깅을 할 수 있는 Remote Live Debugger 설정하기 입니다. 지금까지 자료들은 많은(?)데 실질적으로 Setting에 어려움을 격으신 분들이라면 많은 도움이 되실것이라 믿습니다.

Windows Server 2003을 기준으로 작성하였습니다.

[용어정리]

Target: 문제가 발생하여 라이브 디버깅이 필요한 컴퓨터를 Target 컴퓨터라 부릅니다.

Host: 원격에서 문제의 컴퓨터를 디버깅 하기 위한 컴퓨터를 Host 컴퓨터라 부릅니다.

Null Modem Cable: Target과 Host 컴퓨터 간의 통신을 위해 매개가 되는 Cable입니다.

WinDbg: Kernel 라이브 디버깅을 하기 위한 소프트웨어 입니다. 최신 버전은 http://www.microsoft.com/whdc/devtools/debugging/default.mspx 에서 확인 하십시오.

그림 1 Null Modem Cable

[사전준비사항]

1. Target 컴퓨터에 연결하여 Debug를 하기 위한 별도의 컴퓨터가 준비 되어야 합니다.

2. Null Modem Cable이 준비 되어야 합니다.

3. 두 컴퓨터에 사용할 수 있는 Com 포트가 있어야 합니다.

4. Debug를 실시할 Host 컴퓨터는 WinDbg가 설치 되어야 하며 Symbol 파일이 있어야 합니다. 그렇지 않으면 인터넷에 연결하여 Web Symbol Server와 연결되어야 합니다.

사전 준비 작업

1. Target과 Host 컴퓨터의 장치 관리자에서 사용가능 한 Com Port 번호를 확인 합니다.

그림 2 Com Port 확인

2. Target, Host 컴퓨터의 Com port에 Null Modem Cable를 연결합니다.

[Kernel Live Debuger 설정 방법]

1. Target 컴퓨터에서 아래와 같이 설정 합니다.

a. 아래 명령을 C:\에서 실행합니다.

attrib -s -h -r c:\boot.ini

b. C:\boot.ini에서 아래와 같은 옵션을 추가 합니다.

/debug /debugport=com1 /baudrate=115200

/debugportㅇ에서 옵션에서 사용가능 한 Com Port를 확인하고 설정합니다.

그림 3 Boot.ini 편집

2. Host 컴퓨터에서 아래와 같이 설정합니다.

1. WinDbg(디버깅 도구)를 설치 합니다.

a. http://www.microsoft.com/whdc/devtools/debugging/default.mspx에서 환경에 맞는 WinDbg를 다운로드 하여 설치 합니다.

2. WinDbg에 Symbol 경로를 설정합니다.

a. Windbg를 실행합니다.

b. File > Symbol File Path를 선택합니다.

c. Symbol path에 아래와 같은 Text를 입력하고 OK 버튼을 클릭합니다.

SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols

그림 4 Web Symbol 설정

[라이브 디버깅 시작하기]

a. Host 컴퓨터의 WinDbg에서 File > ‘Kernel Debug…’를 클릭합니다

b. ‘Baud rate’ 값에 115200, Port에는 Host 컴퓨터의 Com Port 번호를 설정하고 ‘확인’ 버튼을 클릭합니다.

그림 5 Com Port 설정하기

c. WinDbg 화면에서 ‘Waiting to reconnect...’ 메시지가 나타나면 Target 컴퓨터를 재부팅 합니다.

그림 6 Waiting to reconnect 상태

d. ‘그림 7’과 같은 상태에서 Ctrl + Break 키를 눌러 Control을 Host 컴퓨터로 가져 옵니다.

그림 7 Control을 가져오기 전 상태

그림 8 Control을 가져온 상태

위 상태에서 라이브 디버깅이 가능합니다.

[Target 컴퓨터에서 Memory dump 생성]

‘0> kd’에서 ‘.crash’를(따옴표 빼고) 입력하면 원격의 Target 컴퓨터에서 블루스크린이 발생하면서 Memory dump를 생성합니다. 생성된 Memory dump는 Target 컴퓨터의 C:\%Systeomroot%\

그림 9 Crash 실행

[Exception 발생시 Action 설정]

라이브 디버깅을 설정하면 일반적인 First Exception에도 사용자의 Action이 필요할 수 있습니다. 이를 막기 위해 아래와 같은 방법으로 Exception 발생시 어떤 Action을 취할 지 설정 할 수 있습니다.

SXD: Exception 발생시 Break into하여 특정 명령을 실행 할 수 있습니다.

e.g) SXD -c "kb;.time;g" -c2 "kb;.time;g" *

SXN: Exception 발생시 Break into를 하지 않고 메시지 정보 만을 Debuger에 Display합니다.

e.g) SXn -c "kb;.time;g" -c2 "kb;.time;g" *

그림 10 SX* 설정 방법

[관련 문서]

How to Set Up a Remote Debug Session Using a Modem

http://support.microsoft.com/?id=148954

누가 내 메모리를 훔쳤나? [4GB 이상 물리 메모리가 정상적으로 윈도우에 인식되지 않는 현상]

sankim — Thu, 31 May 2007 08:12:00 GMT

누가 내 메모리를 훔쳤나?

많은 분들이 4GB 이상 메모리를 탑재한 32bit Windows에서 물리 메모리 4GB가 전부 나타나지 않고 3.xGB 식으로 나타나는 경우를 보셨던 경험이 있으실 것입니다. 누가 내 컴퓨터를 분해해서 메모리만 딸랑 훔쳐간 걸까요?

이 현상에 대한 원인과 답은 아래 KB929605 문서에서 잘 나와있습니다. 아래 부분을 읽기 전 정독해서 읽어 보시기 바랍니다.

------------------------------------------------------------------------------------------

[KB929605 일부입니다.]

원인

이 동작은 특정 하드웨어 및 소프트웨어 요소의 예상된 결과입니다.

일반적인 컴퓨터에서는 다양한 장치가 메모리 매핑된 액세스를 필요로 하는데, 이것을 MMIO(메모리 매핑된 I/O)라고 합니다. MMIO 공간을 32비트 운영 체제에 사용하려면 해당 MMIO 공간이 첫 4GB의 주소 공간 내에 있어야 합니다.

예를 들어, 256MB의 온보드 메모리를 사용하는 비디오 카드의 경우 해당 메모리가 첫 4GB의 주소 공간 내로 매핑되어야 합니다. 4GB의 시스템 메모리가 이미 설치되어 있는 경우 이 주소 공간의 일부가 그래픽 메모리 매핑용으로 예약되어 있어야 합니다. 그래픽 메모리 매핑은 시스템 메모리의 일부를 덮어씁니다. 따라서 운영 체제에 사용할 수 있는 총 시스템 메모리 양이 줄어듭니다.

사용 가능한 시스템 메모리의 감소는 컴퓨터에 설치된 장치에 따라 다릅니다. 그러나 잠재적인 드라이버 호환성 문제를 방지하기 위해 32비트 버전의 Windows Vista에서는 사용 가능한 총 메모리가 3.12GB로 제한됩니다. 잠재적인 드라이버 호환성 문제에 대한 자세한 내용은 "추가 정보" 절을 참조하십시오.

컴퓨터에 많은 장치가 설치되어 있는 경우 사용 가능한 메모리가 3GB 이하로 줄어들 수 있습니다. 그러나 32비트 버전의 Windows Vista에서 사용할 수 있는 최대 메모리는 대개 3.12GB입니다.

[참고문서]

KB929605: 4GB의 RAM이 설치되어 있는 경우 Windows Vista의 시스템 정보 대화 상자에 보고되는 시스템 메모리가 예상한 것보다 작다

KB929580: Windows Vista or Windows Server 2003 may report less memory than you expect

------------------------------------------------------------------------------------------

위에 말이 무슨 말인지 이해가 잘 안 되신다고요? 그렇다면 아래 그림을 보시죠~

PCI Bus, BIOS 그리고 비디오 카드 등에서 사용하는 MMIO는 물리 메모리 첫 4GB의 영역에 위치하게 됩니다. 그러면 MMIO의 크기만큼의 물리 메모리 영역이 4GB 범위 위로 밀려(?) 올라가 버리게 되지요, 그림(2)를 보시면 MMIO로 인해 실제 물리 메모리가 위로 밀려났다는 의미를 이해 하실 수 있으실 겁니다.

윈도우뿐만 아니라 다른 운영체제들도 32bit 시스템은 4GB address 까지만 액세스가 가능합니다. 그러므로 MMIO가 포함된 4GB 영역까지만을 볼 수 있게 됩니다 이때 MMIO는 실제 물리 메모리가 아니므로 OS는 사용할 수 있는 물리 메모리 계산에서 제외하게 됩니다. 그래서 OS는 MMIO영역을 뺀(4GB-0.5GB=3.5GB) 나머지 3.5GB만을 인식하게 됩니다. 이 문제는 해당 문서가 이야기 하듯이 하드웨어 이슈입니다(OS 잘못은 없어요~).

Workaround로 boot.ini파일 내에서 PAE 모드를 설정 하면 address 범위 자체가 36bit로 확장되어 MMIO 때문에 위로 밀려나 보이지 않던 실제 메모리 영역까지 볼 수 있어 정확히 4GB를 표시하게 됩니다. PAE 자세한 설정 방법은 아래 문서를 참고 하십시오.

참고로 문서에도 있지만 비스타의 경우에는 장치가 4GB를 지원 요구사항을 만족시키지 못하면 드라이버 호환 문제를 피하기 위해 총 사용 가능한 메모리를 3.12GB로 제한 합니다.

KB283037: Windows 2000 및 Windows Server 2003에서 대형 메모리 지원 기능을 사용할 수 있다

*사실 이 글 쓰는 것 보다는 위에 단순한 그림 만드는 게 훨씬 오래 걸렸습니다. 아무래도 전 예술과는 좀 거리가 있는 사람인가 봅니다.

*‘누가 내 치즈를 옮겼나?’라는 책 제목을 패러디 해보았는데 그리 호응이 좋을 거라 생각이 들지는 않는군요..