Windows 2008R2에서 SQL 2008R2에 권장되는 페이지 파일 크기

이 Microsoft 기사 -64 비트 버전의 Windows Server 2008 및 Windows 2008 R2에 적합한 페이지 파일 크기를 결정하는 방법 은 64 비트 Windows 2008 및 Windows 2008R2의 페이지 파일 크기를 계산하기위한 지침을 제공합니다. 의심 할 여지없이 범용 서버에 적합합니다. Windows 2008 / R2 64 비트에서 실행되는 SQL Server 2008R2에 대한 지침이 무엇인지 궁금합니다.

메모리 데이터가 부족하여 페이지 파일에 도달하지 않기를 원한다고 가정합니다. 그렇지 않으면 SQL이 데이터에 대해 디스크를 두 번 칠 수 있습니다. SQL Server는 메모리의 데이터가 페이지 파일에 도달하도록 허용합니까? 나는 통해 사냥 한 SQL 서버 2008 R2 온라인 지침은 아직 페이지 파일 사용에 대한 언급을 발견하지 않았습니다.

잠재적 인 사용 시나리오는 다음과 같습니다. 64GB의 RAM이있는 실제 서버를 고려하면 전체 64GB의 RAM에 페이지 파일이 필요합니까? 우리는 96GB의 페이지 파일을 준비해야합니까? 단일 파일에는 약간 과도하게 보입니다. RAM에서 응용 프로그램을 쉽게 교체하기 위해 Windows가 페이지 파일을 메모리에 결합한다는 것이 일반적인 지혜라는 것을 알고 있지만 사실입니까? 64GB 미만의 페이지 파일로 인해 성능이 저하됩니까?

실제 메모리 만 정상적으로 사용하는 SQL Server에는 특별한 설정이 없습니다.

MS가 Windows에 대해 말한 것을 수행하십시오.

어쨌든 우리가 하나의 주제 인 동안 더 많은 RAM을 사십시오 ... ;-)

을 살펴보십시오 lock pages in memory. 이렇게하면 SQL 서비스 계정에 디스크 페이징 대신 사용 가능한 RAM을 사용하도록 기본 설정을 지정할 수 있습니다. 메모리의 잠금 페이지에 대한 자세한 내용을 보려면이 링크를 확인 하십시오 . 스 니펫은 다음과 같습니다.

Windows 정책 메모리의 페이지 잠금 옵션은 기본적으로 비활성화되어 있습니다. AWE (Address Windowing Extensions)를 구성하려면이 권한을 활성화해야합니다. 이 정책은 프로세스를 사용하여 데이터를 실제 메모리에 보관할 수있는 계정을 결정하여 시스템이 디스크의 데이터를 가상 메모리로 페이징하지 못하게합니다. 32 비트 운영 체제에서 AWE를 사용하지 않을 때이 권한을 설정하면 시스템 성능이 크게 저하 될 수 있습니다. 64 비트 운영 체제에서는 메모리에 페이지를 잠글 필요가 없습니다.

시스템에서 사용하기 전에이 기능을 테스트하십시오.

예, 64GB RAM의 경우 64GB 이상의 스왑 파일 이 필요 합니다 (96GB 권장). 스와핑 가능성이 아니라 Windows 메모리 관리자의 디자인 때문입니다. RAM이 큰 컴퓨터의 시스템 페이지 파일 크기 에서이 문제에 대해 이전에 썼습니다 .

프로세스가 / MEM_COMMIT를 통해 메모리를 요청하면 요청 된 크기를 페이지 파일에 예약해야합니다. 이것은 최초의 승리 NT 시스템에서 사실, 아직도 참조 오늘 사실 Win32에서의 가상 메모리 관리 :VirtualAllocVirtualAllocEx

메모리가 커밋되면 실제 메모리 페이지가 할당되고 페이지 파일에 공간이 예약됩니다.

대안은 oom_killer 와 같은 것 입니다 .

따라서 권장 사항을 따르십시오. 때로는 상황이 약간 복잡합니다. 그리고 AWE와 잠금 페이지 권한으로 인한 합병증도 만지지 않았습니다 ...