메모리가 가득 차기 전에 Windows 2008에서 스왑을 사용하는 이유는 무엇입니까?

IIS와 .NET4 웹앱을 실행하는 Windows 2008 서버 (Amazon EC2)를 관리합니다. 나는 다른 날에 메모리 경고를 받고 가서 보았고, 프로세스 메모리가 느린 누수를 통해 시간이 지남에 따라 충분히 커 졌는지 확인하십시오. 60M에서 200M과 같이 크게 성장하지는 않았지만 모니터를 시작하기 위해 매우 낮은 임계 값 (75 %)을 초과하는 상자와 함께 계속 진행되었습니다.

나는 앱의 풀을 재활용하고 메모리가 비워졌으며 스왑 공간이 많이 사용되고 있고 1GB 이상이 그 리사이클로 비워 졌다는 통계를 검토했을 때 나타났습니다.

어쩌면 이것은 기본적인 질문 일 수도 있지만 저는 유닉스 사람이며 메모리가 부족해질 때까지 사용하지 않는 것으로 바꾸는 데 익숙합니다. 이 상자는 메모리 사용량이 75 %를 넘지 않았습니다. 이것은 Windows 또는 .NET 또는 Amazon입니까? 의심되는 것보다이 앱에서 메모리 누수가 훨씬 더 크다고 생각합니다. 60M에서 200M로 누출되지 않고, 60M에서 1.2GB로 누출되고 있지만, 그 중 많은 부분이 "콜드 (cold)"되어 스왑으로 밀려 나고 있습니까?

응용 프로그램 풀에 메모리 재활용이 설정되어 있지만 상자 전체 메모리를 트리거 하므로이 응용 프로그램은 자동으로 재활용되기 전에 실제로 커질 수 있습니다.

정기적 인 "시간 제한"재활용을 설정할 수는 있지만 해결 방법은 개발자가 앱을 수정하도록하지만 스왑 사용량으로 여기에서 무슨 일이 일어나고 있는지 이해해야이를 올바르게 이해할 수 있습니다.

추가 정보로 편집 : 인스턴스 메모리 : 1.7GB 스왑 : 4.5GB

taskmgr에 w3wp.exe 프로세스가 메모리 : 211,000k를 표시하는 것을 볼 수 있습니다. 그러나 다시 시작했을 때 (자체 앱 풀에 있고 상자에있는 유일한 앱입니다), 메모리 사용량은 정상적인 시작 지점 인 60M으로 내려 갔고 1GB 이상의 스왑도 해제되었습니다. taskmgr에서 나는 일반적인 메모리 (Private Working Set) 통계를 얻었지만 다른 모니터링 (Cloudkick)을 통해 스왑 변경을 보았습니다. 되돌아 가서 오늘 살펴보면, 프로세스에서 메모리는 최대 195M (총 1.2GB)이고 스왑은 1.0GB에서 1.1GB로 줄었습니다. 시간이 지남에 따라 백업하지 않았습니다. 느린 크립).

나는이 특정 응용 프로그램에 대해 덜 걱정하고 Windows 스왑 시간과 사용 방법, 일반적으로 주어진 Windows 메모리 및 스왑 사용에 대해 고려해야 할 사항을 이해하는 데 더 관심이 있습니다.

Windows와 Linux에는 서로 다른 두 가지 페이지 / 스왑 전략이 있습니다.

리눅스

리눅스는 스왑 공간을 전혀 사용하지 않기를 원하며 마지막 순간까지 기다립니다. Linux에서 많은 양의 스왑이 표시되면 시스템에 문제가 있거나 문제가있을 수 있습니다. 이 전략은 시스템의 가장 느린 부분 인 전체 디스크 i / o를 최소화하는 데 좋지만 가볍고 무거운 부하가 번갈아 나타나는 시스템 (그리고 솔직히 우리 대부분)에 대해서는 약합니다. "추가"디스크 i / o로 인해 이미로드가 과중한 시간에 부담이되거나, 다시 말해서, 서버를 구축하는 동안에도 교환 할 수없는 충분한 램을 갖도록 설계해야합니다. 가장 높은 예상로드 시간.

윈도우

Windows는 메모리를 페이지 파일의 단순한 캐시로 취급하려고합니다. 귀하의 실제 메모리는 디스크에 항상 있지만, 먼저이 할 수있는 경우 "캐시"에서 읽기 / 쓰기됩니다. 이 전략은 시간이 지남에 따라 부하를 해결하는 데 좋습니다. 시스템이 사용 중이 어서 페이지를 교환해야하는 경우 현재 페이지가 이미 디스크에 있고 작업의 절반이 이미 완료되었습니다. 이 접근 방식은 Windows가 어렸을 때 32MB (GB를 잊어 버렸습니다)는 여전히 많은 RAM이었고 스왑 공간을 자주 사용해야하는 경우가 많았습니다. 오늘날에도 이것은 시간이 지남에 따라 디스크 i / o를보다 고르게 분산시키는 데 도움이되므로 경부 하와 사용량이 많은 부하를 번갈아 가며 작업 부하에 적합합니다.

최신 Windows 버전에는 SuperFetch와 같은 추가 최적화 기능이있어 디스크와 RAM에 메모리 페이지를 미리로드하고 준비 할 수 있습니다.로드가 적을 때 프로그램을 처음로드 할 때 추가 디스크 쓰기가 필요하지 않습니다. 이 모든 기능을 통해 예상되는 최고로드보다 적은 용량의 RAM 만 필요로하도록 시스템을 설계 할 수 있으므로 비용을 줄이면서도 항상 수용 가능한 성능을 유지할 수 있습니다.

수렴

테스트 환경에서 먼저로드를 측정 또는 예측 한 다음로드가 알려진 경우 프로덕션 자원을 할당하는이 개념은 가상 및 클라우드 서버의 출현과 관련하여 시스템 구축에서 비교적 최근에 개발 된 것이거나 가능하거나 적어도 실용적입니다. . 부하에 따라 전혀 교체 할 필요가 없도록 시스템을 설계 할 수도 있습니다. 이 경우 Windows에서는 페이징을 해제하고 Linux 시스템처럼 작동하도록 할 수 있습니다. 그러나 조심해야합니다. 시스템 설계에 예상보다 많은 메모리가 필요한 경우 이러한 방식으로 문제가 발생할 수 있습니다.

다른 한편으로, 현대 리눅스 커널은 예전보다 디스크를 디스크로 바꾸려고합니다. 따라서 두 시스템 간의 메모리 관리 전략의 차이는 여전히 존재하지만 이전보다 덜 명확합니다. 두 시스템 모두 장점이 있으며, 각각의 시스템은 복사 할 수있는 기능을 확인합니다.

Windows (및 Linux 및 기타 Unix와 유사한 OS)는 일정 시간 동안 사용되지 않은 페이지를 디스크로 이동하여 버퍼 및 캐시를위한 공간을 확보하여 활성 I / O 활동 속도를 높입니다. 또한 응용 프로그램은 종종 즉시 사용하는 것보다 더 많은 메모리를 할당합니다. 이렇게하면 커널이 백그라운드에서 최근에 건드리지 않은 일부를 페이징하도록하여 해당 응용 프로그램이 갑자기 시작될 때 페이징 지연이 표시되지 않도록 할 수 있습니다 해당 할당을 사용합니다.

Linux에서는 /proc파일 시스템 에서 관련 "스왑"값을 변경하여이 동작을 조정 (또는 차단) 할 수 있습니다. 의심 할 여지없이 레지스트리 값이있어서 Windows가 이와 관련하여 동작하는 방식을 변경할 수도 있습니다.

알아야 할 또 다른 사항은 페이지 아웃 된 후 나중에 다시 읽을 때 파일이 가득 찼거나 RAM의 페이지가 변경 될 때까지 커널이 페이지 파일에서이를 제거하지 않는다는 것입니다. 이 방법으로 해당 청크를 다시 페이징해야하는 경우 실제로 페이지를 디스크에 쓰지 않아도됩니다. 내용이 이미 있습니다. 이렇게하면 메모리 초과 커밋이 나빠서 페이지 파일이 스 래싱 될 수있는 상황 (많은 수의 페이지가 지속적으로 매핑 및 출력)에서 성능이 크게 향상 될 수 있습니다. 메모리 누수로 인해 일부 데이터가 푸시 된 후 나중에 다시 공간을 확보하기 위해 해당 페이지를 매핑해야하거나 RAM이 필요한 경우 다시 읽었으나 디스크에서 삭제되지 않았 음을 알 수 있습니다. Linux에서 "SwapCached"값은/proc/meminfoRAM과 디스크에 동일한 사본이있는 페이지에 얼마나 많은 데이터가 있는지 표시합니다. Windows는 의심 할 여지없이 동일한 최적화 (또는 유사한 것)를 사용하지만 이것이 얼마나 발생하는지 확인할 정확한 위치는 아닙니다 (의심 할 수있는 관련 성능 모니터 카운터가 있는지 의심의 여지가 없습니다).

tl; dr : 이것은 정상입니다. 최신 OS 커널은 영리하고 노력을 기울여 I / O 작업을 저장하기 위해 캐시로 사용할 수있는 RAM의 양을 최대화하며, 비트를 페이징해야하는 경우 데이터를 디스크 및 RAM에 복사하여 I / O를 저장하는 경우가 있습니다 RAM의 나중에. 현재로서는 RAM이 부족하지 않더라도 이러한 두 가지 방식으로 페이지 파일을 사용하면 전체 성능이 저하되는 것이 아니라 전체적인 성능이 향상 될 수 있습니다.