작업 관리자에서의 "Commit size"가 가리키는 메모리의 의미
윈도우 개발자 중에 "VirtualAlloc" 관련 함수의 사용법을 아시는 분들이라면,
VirtualAlloc function
; https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc
가상 메모리의 "예약(Reserve)"과 "실제 할당(Commit)"의 차이점을 아실 것입니다. 이것이 사용되는 대표적인 활용예가 바로 "스레드의 스택(Stack)"인데요. 윈도우 프로그램에서 스레드 하나를 생성하면 그 스레드가 사용하게 될 스택을 위해 (기본값으로) 1MB 메모리를 사용하게 됩니다. (너무 크지 않나??? 하고 놀라는 분도 계실 듯 싶습니다.) 1MB라니! 따라서 32비트 윈도우 시스템에서 EXE 프로세스의 사용자 메모리 영역으로 2GB가 할당되어 있기 때문에 대략 2천개 정도의 스레드를 생성하면 개당 1MB 씩 계산해서 거의 2GB 가상 메모리를 모두 점유해 메모리 부족에 시달리게 됩니다.
그런데, 여기서 윈도우는 약간 똑똑한 작업을 합니다. 스레드 스택을 '가상 메모리'로써 연속된 주소를 보장하도록 1MB를 예약하긴 하지만 그 1MB 전부를 미리 할당(Commit)하지는 않습니다. 대신 (32비트 운영체제에서 기본값으로) 4KB 영역을 할당(commit)해서 사용하고 추가적으로 그 위의 4KB를 guard 접근 권한으로 미리 할당해서 최초 8KB를 할당하게 됩니다. 나머지 "1016KB = 1MB - 8KB" 영역은 가상 주소(virtual address) 상으로 점유만 하고 있을 뿐, 실제로 그 영역을 위해 물리 메모리나 디스크 상에 할당이 되는 것은 아닙니다.
그러다가, 스레드가 4KB 영역을 넘어서 guard 페이지로 할당된 메모리를 접근하는 순간 Fault 예외가 발생하고 윈도우 운영체제는 그 순간 guard 페이지를 응용 프로그램이 사용할 수 있는 평범한 Read/Write 페이지로 바꾸고 새로운 4KB 물리 메모리를 또다시 할당해 guard 페이지로 설정해 놓습니다. 그런 식으로 4KB씩 자라다가 "1020KB = 1MB - 4KB"가 넘는 순간 Stackoverflow 예외가 발생하는 것입니다. 왜냐하면 마지막 guard 페이지는 그 이후의 보호 장치를 걸어둘 수 없는 이유로 사용하지 않습니다. (참고로, 64비트에서는 8KB + 8KB로 해서 최초 16KB를 commit합니다.)
좀 더 자세한 사항은 다음의 글을 참고하세요. ^^
Pushing the Limits of Windows: Processes and Threads
; https://techcommunity.microsoft.com/t5/windows-blog-archive/pushing-the-limits-of-windows-processes-and-threads/ba-p/723824
이 때문에, 가상 메모리 상으로 예약(Reserved)된 메모리를 나타내는 "Virtual Memory Size"가 있고, 그중에서도 실제 할당(Commit)까지 발생한 영역을 나타내는 "Virtual Commit Size"가 있습니다.
이 설명을 듣고 작업 관리자의 메모리 관련 럼을 보겠습니다.
- Working Set (Memory)
- Memory (Private Working Set)
- Commit size
"Working Set"은 Commit된 것 중에서 물리 메모리(RAM)에 올려진 것을 말합니다. 당연히 RAM에 없는 것은 디스크로 페이징되어 있을 것이고요. 따라서 다음과 같은 관계가 성립합니다.
Virtual Size = Commit Size + 미할당된 예약 영역 크기
Commit Size = (RAM에 있는) Working Set + (디스크에 있는) 페이징된 Commit 메모리
또한, "Private"이라는 것은 해당 EXE가 전용으로 할당한 것을 의미합니다. 쉽게 말해 C/C++에서 "new" 연산자를 사용해 할당한 메모리는 전부 private에 해당합니다. 따라서 보통은 메모리 누수(Leak)가 나타나는 프로그램은 private 메모리의 사용량에 대한 증가 추세를 보고 짐작할 수 있게 됩니다.
여기까지만 듣고 보면, Commit size보다 큰 Working Set은 있을 수 없는 상황입니다. 그런데, 작업 관리자를 보다 보면 종종 (보통 dwm.exe 같은 프로세스에서) Commit Size보다 Working Set 칼럼의 값이 큰 것을 볼 수 있습니다.
왜냐하면, 작업 관리자에서의 "Commit size"는 가상 메모리와 연관된 의미에서의 할당(commit) 메모리를 가리키는 것이 아니고 "Private"하게 할당된 모든 메모리의 크기를 의미하기 때문입니다. 이를 확인하려면
Process Explorer가 도움이 됩니다.
위에서 보는 것처럼, 작업 관리자(Task Manager)의 "Commit size"와 동일한 크기로 Process Explorer에서 "Private Bytes"로 표시되는 것을 볼 수 있습니다. 그리고, Process Explorer의 "Virtual Size"는 예약된 크기를 포함하는 가상 메모리 크기입니다. 그렇다면 가상 메모리 중에서 진짜로 commit된 크기는 어떻게 알 수 있을까요? 아쉽게도 이것은 작업 관리자와 Process Explorer 모두 보여주지 않습니다.
대신 VMMap 프로그램을 사용하면 가능합니다.
VMMap
; https://learn.microsoft.com/en-us/sysinternals/downloads/vmmap
이 프로그램을 실행시켜 출력된 "Committed"가 바로 그것입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]