[ IPC ] memory-mapped file 관련

[퍼온글] http://serious-code.net/moin.cgi/WindowsMemoryMappedFile

1. 주의 할 점

IO를 위해서 메모리 포인터만 있으면 되기 때문에, MMF의 유혹에 빠지는 이들이 많다. 포인터 값을 증가시키기만 하면 마치 마법처럼 그 주소에 데이터가 나타난다. 시스템이 x386 가상 메모리 컨트롤러(virtual memory controller)를 이용해 실제적인 입출력을 처리해주기 때문이다. 포인터로 아직 RAM에 올라와 있지 않은 부분을 지정하면, 사용자는 알 수 없지만, 페이지 폴트가 일어나고, 시스템이 필요한 부분을 로드하게 된다. 페이지 폴트를 처리하는 동안 해당 스레드가 중지(suspend)되기 때문에, 프로그램에서는 이를 알 수 없다.

MMF를 이용하면 간단하게 디스크에 있는 데이터를 이용할 수 있고, 일반적인 파일 IO에 사용되는 코드들과 버퍼링이 필요없다. 간단하고 빠르다. 그렇다면 예전에 사용하던 파일 IO를 더 이상 고집할 필요가 없는가? 그렇지 않다.

MMF가 일반 파일 IO보다 항상 빠른 것은 아니다. MMF는 커널이 관리하기 때문에 얼마나 많은 양의 메모리가 얼마나 오랫동안 남아있는지를 사용자가 컨트롤할 수가 없다. 이는 MMF를 위해서 "곧 필요하게 될" 코드나 데이터들이 디스크로 밀려날 수도 있다는 말이다.

또한 페이지 폴트 또한 공짜가 아니다. 페이지 폴트 처리는 간단한 파일 IO보다 훨씬 많은 시간을 필요로 한다. 페이지 폴트 처리를 위해 들어가는 시간은 시스템에 의해서, 게다가 다른 스레드에서 일어나기 때문에 알 수가 없지만, 이것이 성능에 영향을 미친다는 것은 분명히 알 수 있다.

직접 만든 데이터 관리 코드는 데이터 액세스 패턴을 알고 있기 때문에 최적화가 가능하다. 참조의 지역성(locality of reference)라든지, 캐쉬의 수명 등이 그 예이다. 잘 만들어진 데이터 관리 코드는 MMF에 비교할 만한 성능을 내는 데다가, 훨씬 적은 메모리를 요구한다. 이는 페이지 폴트를 줄이고, 결과적으로 전체 시스템의 성능을 높인다.

MMF가 페이지 폴트의 원인이 될 수 있다는 점을 감안하면, 어떤 데이터를 MMF로 사용해야하는지를 알 수 있다. 즉 애플리케이션에서 가장 중요하고, 자주 사용하는 데이터에다 MMF를 이용해야 한다. 정작 자주 사용하는 데이터가 MMF 때문에 페이지 아웃 되버리면 곤란하지 않겠는가.

2. MMF의 장점

데이터가 메모리에 이미 올라와있는 것처럼 간단하게 접근할 수 있다.

대부분의 경우, 일반적인 파일 IO에 비해서 나은 성능을 보여준다.

비동기 IO를 사용하지만, 시스템에서 처리해주기 때문에 스레드 문제를 걱정할 필요가 없다.

 

3. MMF의 단점

일반 파일 IO에 비해서 상당히 많은 메모리를 요구한다.

얼마나 많은 데이터를 얼마나 오랫동안 메모리에 둘 것인지를 컨트롤할 수 없다.

MMF 파일은 일정한 크기여야 한다. MMF 파일의 크기를 증가시키는 것은 상당히 고통스런 작업이다.

디스크에 있는 데이터를 그대로 메모리에다 1:1 매칭시키는 방식이기 때문에, 압축된 파일 처리나 파일 버전 비교가 힘들다.

파일 공유를 지원하지 않는다.

하나의 연속된 주소만 사용할 수 있다. 하나의 연속된 주소에 올리기에는 너무 큰 500 메가짜리 파일 같은 경우, 프로세스의 주소 공간을 단편화시킬 수 있다.

 

link > Managing Memory-Mapped Files in Win32  : http://msdn.microsoft.com/en-us/library/ms810613

link > Faster File Access With File Mapping : http://www.flipcode.com/archives/Faster_File_Access_With_File_Mapping.shtml