[ntdebugging]The Memory Shell Game
The Memory Shell Game
https://blogs.msdn.com/ntdebugging/archive/2007/10/10/the-memory-shell-game.aspx
위의 포스트에서는 메모리에 대해서 설명하고 있습니다. 얼마나 많은 메모리가 사용 가능할지, 성능에 어던 영향을 미칠 지, working set triming 이 성능에 미치는 영향 등에 대해서 이야기 하고 있습니다.
메모리 관련 모듈들이 어떻게 동작하는지
메모리를 설명하기 위해 아래 항목들에 대해서 정의 하고 있습니다. 성능에 대해 관심을 가지고 계시다면 아래 정의를 숙지하고 있는 것이 좋습니다.
Virtual Memory, Physical Memory, Committed Memory, Commit Limit, Page file, Working Set, Modified pages, Standby pages, Free pages, Zeroed pages,
가상메모리, 물리 메모리의 차이점에 대해서 알고 있어야 하며, 프로세스에서 메모리를 할당할 경우 Committed memory가 증가되며 물리 메모리에서 사용되다가 오랜 시간 사용되지 않는 데이터 들은 페이지 파일로 저장됩니다. 프로세스가 사용하는 메모리 중 물리 메모리에 존재하는 것은 Wroking set 이고, 수정된 메모리는 modified pages 에 있고, 오랜 시간 사용되지 않았다면 standby pages 로 옮겨지는데 물리 메모리에는 존재하고 있기 때문에 해당 프로세스가 다시 메모리를 사용하고자 할 경우 매우 빠르게 다시 재 사용할 수 있습니다. 해제 되거나 해당 프로세스가 종료될 경우 사용되던 메모리를 Free pages 로 이동되고 free pages 에 있는 내용들은 IDLE 프로세스가 동작하는 시점에 Zeroed pages 로 이동됩니다.
프로세스가 새로운 메모리를 요청할 경우 먼저 Zeroed pages, Free pages, Standby pages 순으로 메모리가 있는지 검색하게 됩니다.
작업 관리자가 우리에게 보여주는 것은?
작업 관리자를 통해서 확인할 수 있는 메모리 관련 정보들이 어떤 값들을 통해서 나오는 것인지 설명하고 있습니다.
Phycal memory – Total, Available, System Cahce, PF Usage
Commit Charge – Total, Limit, Peak
Total 은 전체 물리 메모리, Available 은 standby, free, zeroed page 의 합, System Cache 은 Standby 와 system working set의 합 PF Usage 는 Page File의 사용률을 설명 합니다.
Commit Charge total 은 시스템 전체의 commited 된 메모리의 합이며 Limit 은 page file 과 물리 메모리의 크기를 합친 값입니다.
어떻게 동작하는지?
많은 물리 메모리가 file cahce로 동작하게 되는데 이는 느린 디스크 성능을 향상 시키기 위한 것 입니다.
프로세스가 메모리를 사용하면 해당 메모리는 working set에 위치 하게 됩니다. 시간이 지난 후 메모리가 사용되지 않게 되면 working set 에서 제거되고 변경되어 있다면 modify list로 이동되후 페이지 파일에 저장 후 standby list 로 이동됩니다. 변경되어 있지 않다면 standby list로 이동하게 됩니다.
메모리가 다시 사용되게 된다면 soft fault 가 발생하면서 다시 working set 으로 이동 되지만 아주 오랜 시간 사용하지 않거나 standby list 의 메모리가 너무 오랜 시간 사용되지 않거나 해제 요청이 발생할 경우 standby list 에서 제거되어 free list 로 이동됩니다. 이후 zero page 작업을 거친 후 zeroed list로 이동하게 됩니다.
매우 긴 시간이 지난 후 프로세스가 working set 에 존재하지 않는 메모리를 접근할 경우 standby list 에 있을 경우 아주 빠른 시간에 재 사용할 수 있지만 standby list 에 존재하지 않는다면 hard fault 가 발생하면서 디스크에 있는 파일 또는 페이지 파일에서 값을 읽어 오게 되고 working set에 다시 위치하게 됩니다.
페이지 파일을 많이 사용하고 있는 것 자체는 문제가 있는 것이 아닙니다.
loading PFN database
loading (100% complete)
Compiling memory usage data (99% Complete).
Zeroed: 414 ( 1656 kb)
Free: 2 ( 8 kb)
Standby: 864091 (3456364 kb)
Modified: 560 ( 2240 kb)
ModifiedNoWrite: 30 ( 120 kb)
Active/Valid: 182954 (731816 kb)
Transition: 2 ( 8 kb)
Bad: 0 ( 0 kb)
Unknown: 0 ( 0 kb)
TOTAL: 1048053 (4192212 kb)
위의 Windbg 의 !memusage 결과를 보면 4GB의 RAM에 1.6MB 정도의 Zeroed 와 free pages 그리고 731MB 정도가 process 에서 사용되고 있고 2MB는 modified page list 그리고 3.4GM 정도가 standby list 에 있습니다. 만약 위의 결과를 보고 3.4GB의 메모리가 낭비되고 있다고 생각한다면 좀더 메모리에 대해서 공부해 볼 필요가 있습니다.
어떤 것을 확인해 보아야 하는지?
만약 성능 문제가 발생한다면 성능로그를 수집해 보아야 합니다.
성능이 느려지는 가장 큰 문제 중 하나는 디스크 병목 현상 입니다. Physical Disk\% Idle Time, Avg. Disk sec/Read and Avg. Disk sec/Write 카운터를 살펴 보아야 합니다. 만약 시스템 드라이브의 Idle 이 50% 밑으로 내려 가고 Disk 응답 시간에는 문제가 없다면 Memory\Available Mbytes를 살펴 보아야 합니다. 아마도 수백 Mbyte의 여유를 가지고 있을 것 입니다. 만약 이 값이 너무 낮아질 경우 standby list, process working set 그리고 cache 가 감소될 것 입니다. 어떤 프로세스가 물리 메모리를 소모하고 있는지 working set과 file cache 값 등을 확인해 보아야 합니다.
페이지 파일이 시스템 성능에 영향을 주는지 확인하려면 Memory\Pages Input/sec 와 연관되어 있는 Physical Disk\Avg. Disk sec/Read 를 살펴 보아야 합니다. Pages Input/sec 는 초당 얼마나 많은 페이지들이 페이지 파일에서 읽혀지는 지를 보여주며 Hard fault를 나타 냅니다.(page 가 standby list 에 없는 경우) 만약 Avg. Disk sec/Read 가 물리 디스크의 스펙에 있는 속도와 근접하고 idle 이 높은 경우 페이징은 문제가 없습니다.
Memory\Pages Output/sec 그리고 Physical Disk\Avg. Disk sec/Write 를 보실 수 있습니다. 이것들은 modified page 가 프로세스의 working set에서 제거될 때를 나타내는 것으로 페이지에 데이터가 쓰여진다 하더라도 standby list 에 존재 할 것이기 때문에 성능에 큰 영향을 주지는 않습니다. 메모리 할당 요청이 많이 발생할 경우 프로세스 working set 이 trim 되는 것을 확인하실 수 있습니다.