문제

SQL Server를 실행하는 Windows 2003 서버의 적절한 페이지 파일 크기에 대한 좋은 경험 법칙을 아는 사람이 있습니까?

도움이 되었습니까?

해결책

RAM 크기와 관계없이 물리적 RAM 크기의 최소 1.5배에 해당하는 페이지 파일이 필요합니다.이는 1TB RAM 머신이 있더라도 디스크에 1.5TB의 페이지 파일이 필요하다는 사실입니다(이상하게 들리지만 사실입니다).

프로세스가 VirtualAlloc/VirtualAllocEx를 통해 MEM_COMMIT 메모리를 요청할 때 요청된 크기를 페이지 파일에 예약해야 합니다.이는 최초의 Win NT 시스템에서도 마찬가지였으며 오늘날에도 여전히 그렇습니다. Win32에서 가상 메모리 관리:

메모리가 커밋되면 물리적 메모리 페이지가 할당됩니다. 공간은 페이지 파일로 예약되어 있습니다.

극단적인 이상한 경우를 제외하면 SQL Server는 항상 MEM_COMMIT 페이지를 요청합니다.그리고 SQL이 동적 메모리 관리 가능한 한 많은 버퍼 풀을 미리 예약하는 정책(예약 및 커밋하다 VAS 측면에서) SQL Server는 시작 시 페이지 파일에 대량의 공간 예약을 요청합니다.페이지 파일의 크기가 적절하지 않으면 오류 801/802가 SQL의 ERRORLOG 파일 및 작업에 표시되기 시작합니다.

관리자는 대용량 RAM이 있으면 페이지 파일이 필요하지 않다고 잘못 가정하기 때문에 항상 혼란을 야기합니다.실제로는 Windows NT 메모리 관리자의 내부 작동으로 인해 RAM이 크면 페이지 파일의 필요성이 증가합니다.예약된 페이지 파일은 사용되지 않기를 바랍니다.

다른 팁

(내가 크게 존경하는) 리무스에 대한 모든 존경심에 대해 나는 강력하게 동의하지 않습니다.페이지 파일이 전체 덤프를 지원할 만큼 충분히 크면 매번 전체 덤프를 수행합니다.RAM 용량이 매우 큰 경우 작은 문제가 심각한 중단으로 이어질 수 있습니다.

일회성 일시적인 문제가 있는 경우 서버가 디스크에 1TB의 RAM을 써야 하는 것을 원하지 않습니다.문제가 반복되는 경우 페이지 파일을 늘려 전체 덤프를 캡처할 수 있습니다.PSS(또는 전체 덤프를 분석할 수 있는 자격을 갖춘 다른 사람)가 전체 덤프를 캡처하라는 요청을 받을 때까지 이 작업을 기다릴 것입니다.극히 소수의 DBA만이 전체 덤프를 분석하는 방법을 알고 있습니다.미니 덤프는 어쨌든 나타나는 대부분의 문제를 해결하는 데 충분합니다.

또한 서버가 1TB 전체 덤프를 허용하도록 구성되어 있고 문제가 반복적으로 발생하는 경우 보유하고 있는 여유 디스크 공간은 얼마나 됩니까?주말이면 전체 SAN을 채울 수 있습니다.

운이 좋게도 3GB 또는 4GB RAM이 탑재된 SQL Server를 보유하고 있던 시절에는 페이지 파일 1.5*RAM이 표준이었습니다.더 이상 그렇지 않습니다.모든 프로덕션 서버(메모리 부족을 겪고 있는 SSAS 서버 제외)에서 페이지 파일을 Windows 기본 크기 및 설정으로 그대로 둡니다.

그리고 명확히 하기 위해 저는 2GB RAM에서 2TB RAM까지의 서버를 사용하여 작업했습니다.11년이 넘은 후에는 전체 덤프를 캡처하기 위해 페이징 파일을 한 번만 늘리면 되었습니다.

Microsoft에 따르면 "컴퓨터의 RAM의 양이 증가함에 따라 페이지 파일의 필요성이 줄어 듭니다." 그런 다음 기사는 계속해서 성능 로그를 사용하여 페이지 파일의 양을 결정하는 방법을 설명합니다. 실제로 사용되고 있습니다.처음에는 페이지 파일을 1.5X 시스템 메모리로 설정한 다음 권장 모니터링을 수행하고 거기서부터 조정해 보세요.

64비트 버전의 Windows에 적합한 페이지 파일 크기를 결정하는 방법

수익이 감소하기 시작하는 애플리케이션의 작업 세트 크기가 클수록 더 좋습니다.캐시 적중률이 크게 변할 때까지 크기를 천천히 늘리거나 줄여서 이를 찾아볼 수 있습니다.그러나 캐시 적중률이 90% 이상이면 괜찮을 것입니다.일반적으로 프로덕션 시스템에서 이를 주의 깊게 관찰하여 RAM 할당량을 초과하지 않았는지 확인해야 합니다.

최근에 SQL Server 중 하나에서 완전히 범위를 좁힐 수 없는 일부 성능 문제가 발생했으며 실제로 Microsoft 지원 티켓 중 하나를 사용하여 문제 해결에 도움을 받았습니다.SQL Server에서 사용할 최적의 페이지 파일 크기가 나타났으며 Microsoft에서는 이를 권장합니다. RAM 용량의 1 1/2배.

고성능을 찾고 있다면 페이징을 완전히 피하려고 하므로 페이지 파일 크기가 덜 중요해집니다.DB 서버에 가능한 한 많은 RAM을 투자하십시오.

많은 연구 끝에 Windows 2003 Enterprise x64에서 Enterprise x64를 실행하는 전용 SQL Server에는 페이지 파일이 없습니다.

간단히 말해서 페이지 파일은 OS에서 관리하는 파일에 대한 캐시이며 SQL에는 자체 내부 메모리 관리 시스템이 있습니다.

참조된 MS 기사는 해당 조언이 파일 공유와 같은 기본 서비스를 실행하는 OS에 대한 것이라는 점을 인정하지 않습니다.

SQL OS만이 작업을 수행할 수 있는데 Windows가 도움을 주려고 하기 때문에 페이지 파일이 있으면 단순히 디스크 I/O에 부담이 됩니다.

이 경우 총 물리적 RAM의 1.5배라는 일반적인 권장 사항은 최선이 아닙니다.이 매우 일반적인 권장 사항은 "일반" 프로세스에서 모든 메모리를 사용하고 있다는 가정 하에 제공됩니다. 이 프로세스에서는 일반적으로 메모리가 속한 응용 프로그램 프로세스에 막대한 성능 문제를 일으키지 않고 가장 적게 사용된 페이지를 디스크로 이동할 수 있습니다.

SQL Server를 실행하는 서버(일반적으로 대용량 RAM 포함)의 경우 실제 RAM의 대부분은 SQL Server 프로세스에 커밋되며 (올바르게 구성된 경우) 실제 메모리에 잠겨 페이지 파일로 페이지 아웃되는 것을 방지해야 합니다. .SQL Server는 디스크 I/O를 줄이기 위해 프로세스에 할당된 RAM의 상당 부분을 데이터 캐시로 사용하여 성능을 염두에 두고 자체 메모리를 매우 신중하게 관리합니다.해당 데이터를 RAM에 저장하는 유일한 목적은 디스크 I/O를 줄이는 것이기 때문에 해당 데이터 캐시 페이지를 페이지 파일로 페이지아웃하는 것은 의미가 없습니다.(Windows OS는 시스템 작동 속도를 높이기 위해 디스크 캐시와 유사하게 사용 가능한 RAM도 사용합니다.) SQL Server는 이미 자체 메모리 공간을 관리하므로 이 메모리 공간은 "페이징 가능한" 것으로 간주되어서는 안 되며 페이지 파일 계산에 포함되어서도 안 됩니다. 크기.

Remus가 언급한 MEM_COMMIT과 관련하여 가상 메모리 용어에서 "예약"은 실제 할당을 의미하는 것이 아니라 다른 프로세스에서 주소 공간(물리적 공간이 아님)을 사용하는 것을 방지하기 때문에 용어가 혼란스럽습니다."커밋"할 수 있는 메모리는 기본적으로 물리적 RAM과 페이지 파일 크기의 합과 동일하며 MEM_COMMIT를 수행하면 커밋된 풀에서 사용 가능한 양이 감소합니다.그렇습니다 ~ 아니다 그 당시 페이지 파일에 일치하는 페이지를 할당합니다.커밋된 메모리 페이지가 실제로 기록되면 가상 메모리 시스템이 물리적 메모리 페이지를 할당하고 물리적 RAM의 다른 메모리 페이지를 페이지 파일로 범프할 수 있습니다.MSDN 참조 VirtualAlloc 기능 참조.

Windows OS는 애플리케이션 프로세스와 자체 디스크 캐시 메커니즘 간의 메모리 부족을 추적하고 잠기지 않은 메모리 페이지를 실제 페이지에서 페이지 파일로 이동해야 하는 시기를 결정합니다.제가 이해한 바에 따르면, 잠기지 않은 실제 메모리 공간에 비해 페이지 파일이 너무 크면 Windows에서 응용 프로그램 메모리를 페이지 파일로 과도하게 페이징하여 해당 응용 프로그램이 페이지 누락(성능 저하)의 결과를 겪게 될 수 있습니다.

서버가 메모리를 많이 사용하는 다른 프로세스를 실행하지 않는 한 페이지 파일 크기는 4GB이면 충분합니다.메모리의 페이지 잠금을 허용하도록 SQL Server를 설정한 경우 OS 자체 및 다른 프로세스에 대해 일부 물리적 RAM을 사용할 수 있도록 SQL Server의 최대 메모리 설정을 설정하는 것도 고려해야 합니다.

SQL Server의 802 오류는 시스템이 데이터 캐시에 더 이상 페이지를 커밋할 수 없음을 나타냅니다.페이지 파일 크기를 늘리면 Windows가 SQL Server 이외의 프로세스에서 메모리를 페이지 아웃할 수 있는 경우에만 이 상황에 도움이 됩니다.이 상황에서 SQL Server 메모리가 페이지 파일로 증가하도록 허용하면 오류 메시지가 제거될 수 있지만, 처음에 데이터 캐시의 이유에 대해 앞서 언급한 점으로 인해 비생산적입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top