풀 메모리의 단편화

원문 : http://blogs.msdn.com/ntdebugging/archive/2009/12/11/pool-fragmentation.aspx
모든 권리는 원문 저작자에 있습니다.

안녕하세요. 제 이름은 스태판입니다. 저는 Microsoft의 Global Escalation Service Team에서 Escalation engineer로 근무하고 있습니다. 오늘은 제가 최근에 경험했던 풀 메모리의 단편화에 대해서 이야기 하겠습니다. 자 덤프파일을 보도록 하겠습니다.

아래는 !vm에 대한 결과 입니다.

!poolused /t5 2 명령어를 통해 nonpaged pool 사용량이 많은 유저들을 확인해 보았습니다.

!vm 의 결과는 101MB 의 사용을 표기 하고 있으나 !poolused 는 65MB 의 사용이 확인 됩니다. 이는 바로 풀 메모리 단편화를 의미합니다. 조사 결과 저는 많은 풀 페이지들이 아래와 같은 패턴으로 구성되어 있음을 확인하였습니다.

페이지 fa808000 은 0x18 = 24 byte 크기 입니다.  fa808000 과 fa808a38의 모든 페이지들은 freed 되어 이고, 다른 목적을 위하여 재사용 될 것입니다. 위의 페이지에서는 4096 Bytes 중 24 Bytes 만 사용 중입니다.

이런 상황은 fa550000 과 f8feb000 에서도 동일하게 나타나고 있습니다. 자 우리의 질문은 왜 이런 일들이 일어나고 어떻게 하면 이런 상황을 미연에 방지 할 수 있는가? 입니다.

이 덤프에서 저는 많은 MmCm 의 Pool 메모리 사용 현황을 확인 하였습니다.

다음은 일반적으로 단편화가 발생 하기 위한 상황 입니다.

1) 드라이버가 0xF18 크기의 풀 블럭을 요구합니다.  위의 3개의 풀 모두 Free 된 공간의 총합은 충분히 0xF18 크기 이상이 됩니다. 하지만 전체 페이지 4K는 3개로 분활 되어 있고, 이중 이 Free 된 공간은 꼭대기와 밑쪽에 위치하고 있습니다. 그리고 둘 모두 0xF18 크기를 할당 할 만큼 크지 못합니다.
2) 그래서 OS는 드라이버의 요청에 대한 새로운 풀 페이지를 제공합니다. 그리고 역시 밑쪽의 공간은 Freed pool 로 표시 됩니다.
3) 자 아주 작은 크기의 Pool에 대한 요청이 진행 됩니다. OS는 위에서 할당한 풀의 밑쪽 공간을 제공하게 됩니다.
4) 드라이버 MmCm이 사용하던 Pool을 해제 합니다. 하지만 해당 풀 페이지의 하단 부분은 아직도 사용 중이고, 그래서 해당 페이지가 전체는 Freed 되지 못합니다. 그리고 시간이 흘러서 이 공간은 다른 목적을 위해 할당 되게 됩니다.
5) 자 또 0xF18 크기의 풀 블럭을 요청됐습니다. 이전의 풀 블럭은 다른 용도로 이미 할당되어 사용되고 있어 새로운 요청에 사용할 수 없습니다. 그래서 OS는 다시 새로운 페이지를 할당하여 풀 블럭을 제공합니다.
6) 위와 같은 일들로 인해 풀 메모리는 점점 단편화 되게 됩니다. 그리고 그 증거가 바로 이 crash memory dump 죠.

이와 같은 이슈를 피하기 위해서는 0xF18 사이즈의 요청 대신에 전체 풀을 커버할 수 있는 4K 사이즈의 메모리를 요청하는 것이 좋습니다. 물론 할당된 페이지의 약간의 잔여 공간을 활용하지 못하긴 합니다. 하지만 그 대신에 위와 같은 단편화 현상은 방지 할 수 있습니다. 참고로 MSDN에서는 드라이버의 MmCm ( MmAllocateContiguousMemory ) 이용은 충분히 길게 사용하도록 권고 하고 있습니다. 라이브 디버깅을 할 때, 여러분은 연속적으로 할당 되고 해제 된 MmCm을 볼 것 입니다.

참고 링크
http://msdn.microsoft.com/en-us/library/ms801986.aspx
http://blogs.msdn.com/ntdebugging/archive/2006/12/18/Understanding-Pool-Consumption-and-Event-ID_3A00_--2020-or-2019.aspx