얼마전 Windows 2003 Server (64비트 버전) 에서 실행 중인 테스트용 파일 서버가 매우 느려지며 시스템 리소스 부족현상이 나타났습니다. 이 서버는 4GB의 메모리를 가지고 있었으며, 파일서버 서비스 프로그램은 이중 최대 3.5GB의 메모리를 자체 캐쉬 메모리로 사용할 수 있도록 프로그램되어 있었습니다. 그런데, 문제는 64비트 윈도우즈가 파일 시스템 캐쉬로 모든 물리 메모리를 사용하려 한다는 하는 것이었습니다. 아래 SQL 서버와 관련하여 비슷한 문제가 이미 알려져 있었습니다.
http://sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memory-problems.aspx
윈도우즈와 어플리케이션이 메모리를 가지고 서로 경쟁하는 상황이 발생하는데, 윈도우즈는 어플리케이션의 워킹셋(working set)을 스왑파일로 페이지 아웃시킬 수도 있다는 것입니다. 이 시점에서 윈도우즈의 시스템 파일 캐쉬는 의미가 없어집니다. 왜냐하면, 어플리케이션이 사용하는 메모리가 하드디스크로 페이징 되면, 페이징 하는 시간 뿐만 아니라, 이 메모리를 액세스하기 위해 많은 시간이 소요됩니다. 특히, 수학적 데이터 프로세싱(수치해석, 이미지 프로세싱, 3D 랜더링과 같은)을 다루는 프로그램에서 이런 현상이 생기게되면, 프로그램의 속도는 엄청나게 떨어지게 됩니다. (메모리와 HDD속도 비유를 참고하시기 바랍니다.)
이 문제는 Windows 7에서 향상되었다라고 하는데 얼마나 어떻게 향상되었는지는 아직 알 수 없습니다. 다행히, SetSystemFileCacheSize()를 사용하여 시스템 캐쉬 메모리 크기를 조정할 수 있습니다. 그리고 SysInternals의 Cacheset.exe라는 유틸리티를 사용하여 변경 확인 가능합니다.
그런데, 여기서 좀 더 생각해보면, 64비트 Windows는 약 8TB라는 엄청난 메모리 주소공간을 가지기 때문에 64비트 OS나 어플리케이션이 한꺼번에 많은 물리메모리를 사용할 가능성은 얼마든지 있다는 것 입니다. (32비트 프로그램은 64비트 윈도우즈에서 4GB의주소공간을 가짐)
그럼 128GB를 가진 64비트 윈도우즈가 있다고 합시다. 처음드는 생각은 엄청난 메모리라는 것인데, 단순히 메모리 주소공간을 생각하면, 이는 32비트 윈도우즈에 48MB의 메모리를 설치한 정도 밖에는 되지 않습니다. 128GB 메모리는 거대 공룡에게 사과 한 쪽을 먹으라고 주는 것에 불과합니다. 물론, 아직 이렇게 많은 메모리를 사용할 프로그램은 드물 것이라 생각할 수도 있지만, 위의 파일서버 문제와 같이 윈도우즈가 파일 시스템 캐쉬를 계속 메모리에 쌓아두거나, 어떤 64비트 프로그램이 의도했든 아니면 버그이든 메모리를 많이 사용하기 시작하면 128GB는 아무 것도 아니라는 것 입니다.
여기서, 얻을 수 있는 점은 64비트 운영체제와 64비트 어플리케이션을 제작 (특히 서버 프로그램)함에 있어, 시스템메모리의 크기에 따라 실제 최대 얼마 만큼의 메모리를 사용할 것인지, 미리 잘 정해야만 한다는 것 입니다. 특히 파일 액세스가 많은 프로그램의 경우 윈도우즈 시스템의 파일 캐쉬도 염두해 두어야만 합니다. 하나에 1TB 싸이즈의 DIMM 메모리가 나온다면 상황은 달라지겠지만 말입니다.
http://sqlblogcasts.com/blogs/grumpyolddba/archive/2009/03/18/x64-memory-problems.aspx
윈도우즈와 어플리케이션이 메모리를 가지고 서로 경쟁하는 상황이 발생하는데, 윈도우즈는 어플리케이션의 워킹셋(working set)을 스왑파일로 페이지 아웃시킬 수도 있다는 것입니다. 이 시점에서 윈도우즈의 시스템 파일 캐쉬는 의미가 없어집니다. 왜냐하면, 어플리케이션이 사용하는 메모리가 하드디스크로 페이징 되면, 페이징 하는 시간 뿐만 아니라, 이 메모리를 액세스하기 위해 많은 시간이 소요됩니다. 특히, 수학적 데이터 프로세싱(수치해석, 이미지 프로세싱, 3D 랜더링과 같은)을 다루는 프로그램에서 이런 현상이 생기게되면, 프로그램의 속도는 엄청나게 떨어지게 됩니다. (메모리와 HDD속도 비유를 참고하시기 바랍니다.)
이 문제는 Windows 7에서 향상되었다라고 하는데 얼마나 어떻게 향상되었는지는 아직 알 수 없습니다. 다행히, SetSystemFileCacheSize()를 사용하여 시스템 캐쉬 메모리 크기를 조정할 수 있습니다. 그리고 SysInternals의 Cacheset.exe라는 유틸리티를 사용하여 변경 확인 가능합니다.
그런데, 여기서 좀 더 생각해보면, 64비트 Windows는 약 8TB라는 엄청난 메모리 주소공간을 가지기 때문에 64비트 OS나 어플리케이션이 한꺼번에 많은 물리메모리를 사용할 가능성은 얼마든지 있다는 것 입니다. (32비트 프로그램은 64비트 윈도우즈에서 4GB의주소공간을 가짐)
그럼 128GB를 가진 64비트 윈도우즈가 있다고 합시다. 처음드는 생각은 엄청난 메모리라는 것인데, 단순히 메모리 주소공간을 생각하면, 이는 32비트 윈도우즈에 48MB의 메모리를 설치한 정도 밖에는 되지 않습니다. 128GB 메모리는 거대 공룡에게 사과 한 쪽을 먹으라고 주는 것에 불과합니다. 물론, 아직 이렇게 많은 메모리를 사용할 프로그램은 드물 것이라 생각할 수도 있지만, 위의 파일서버 문제와 같이 윈도우즈가 파일 시스템 캐쉬를 계속 메모리에 쌓아두거나, 어떤 64비트 프로그램이 의도했든 아니면 버그이든 메모리를 많이 사용하기 시작하면 128GB는 아무 것도 아니라는 것 입니다.
여기서, 얻을 수 있는 점은 64비트 운영체제와 64비트 어플리케이션을 제작 (특히 서버 프로그램)함에 있어, 시스템메모리의 크기에 따라 실제 최대 얼마 만큼의 메모리를 사용할 것인지, 미리 잘 정해야만 한다는 것 입니다. 특히 파일 액세스가 많은 프로그램의 경우 윈도우즈 시스템의 파일 캐쉬도 염두해 두어야만 합니다. 하나에 1TB 싸이즈의 DIMM 메모리가 나온다면 상황은 달라지겠지만 말입니다.
Trackback Address :: http://devnote.net/trackback/103
