페이지 파일 크기 최적화: 최대 커밋과 물리적 RAM에 대해 명확히 하고 싶습니다.

페이지 파일 크기 최적화: 최대 커밋과 물리적 RAM에 대해 명확히 하고 싶습니다.

실제 요구 사항에 맞게 페이지 파일 크기를 최적화하고 싶습니다. 그리고 저는 Mark Russinovich가 제안한 공식을 따르고 싶습니다.최소값은 최대 커밋에서 물리적 RAM을 뺀 값이어야 하며 최대값은 그 두 배가 되어야 합니다.

모든 일을 올바르게 수행하기 위해 다음 사항을 명확히 하고 싶습니다.

1) 이 빨간색 숫자는 Mr. Russinovich가 언급한 Peak Commit입니까?

화면에는 시스템 정보 창이 있습니다.프로세스 탐색기

여기에 이미지 설명을 입력하세요

2)제어판 > 시스템에 내설치된 RAM은 4GB이고 2,45GB만 사용할 수 있습니다.. 그리고 분명히 작업 관리자에서 총 실제 메모리도 2509MB입니다. 내 OS가 32비트이기 때문이다. 그래서,이 2509(4GB가 아님)가 페이지 파일 크기 계산에 사용해야 하는 숫자라는 것을 올바르게 이해하고 있습니까?

이것이 어리석은 질문일 수도 있다는 것을 알지만, 이미 말했듯이, 나는 그것이 제대로 되었는지 확인하고 싶습니다.

매우 감사합니다.

답변1

당신은 의심할 여지없이"Windows의 한계 확장: 가상 메모리"마크 러시노비치(Mark Russinovich).

  1. 네, 바로 그 번호입니다.
  2. 예, 사용할 수 있는 RAM은 2.5GB뿐입니다(대략 - 여기에서는 과도한 정밀도가 필요하지 않습니다).

그런데.. "제대로 한다"고 쓰시네요. Mark의 기사는 "한계 확장"에 관한 것이며 그 공식은 다음과 같은 결과를 제공한다는 점을 지적해야 합니다.절대 최소한의페이지 파일 크기에 대한 것입니다. 시스템이 잘 작동하기를 원한다면 "한계를 뛰어넘는" 것을 원하지 않을 것입니다.

그 기사에는 당신을 추천하는 글이 없습니다~해야 한다설정을 작게 하세요. 당신이 정말로 원한다면 그것으로부터 벗어날 수 있다는 것뿐입니다. (실제로 더 이상 커밋된 메모리가 필요하지 않다고 가정합니다.)

(그리고 더 필요할 수도 있습니다. 여기서 본 이 "피크"는 Process Explorer 실행 기간 동안의 최고치일 뿐이라는 점을 기억하십시오. 이는 해당 시간 동안 최대 앱 작업 ​​부하를 실행하는 경우에만 의미가 있습니다. 이는 단지 한 번에 실행될 것이라고 생각되는 모든 앱을 시작한다는 의미가 아닙니다. 또한 각 앱이 요청한 최대 개인 메모리("커밋된" 메모리)를 사용하도록 해야 합니다. 설정하고 테스트하기가 어렵습니다. 그리고 일반적인 작업 부하에 다른 앱을 추가하지 않을 것이라고 누가 말할 수 있겠습니까? 따라서 모니터링 도구를 통해 얻은 정보가 더 이상 필요하지 않을 것이라는 보장은 없습니다.

실제로 다시 최고점에 도달해야 하고 그런 식으로 계산한 최소값으로 페이지 파일을 설정한 경우 RAM에 매핑된 파일(예: exe 및 dll과 같은 코드 파일)에서 사용하는 RAM을 위한 공간이 없게 됩니다. . (이는 "커밋된" 가상 메모리 수에 코드 페이지나 매핑된 파일이 지원하는 다른 페이지가 포함되지 않기 때문입니다.) 코드를 실행하려면 RAM에 있어야 하므로 문제가 됩니다.

좋아, 페이지 파일 확장을 활성화했기 때문에 이는 "쇼스토퍼" 문제가 아닙니다. 그러나 그것은 확실히 성능 저하가 될 것입니다.

따라서 성능 문제에 관계없이 앱 충돌을 일으키지 않는 절대 최소 페이지 파일 크기를 입증하려는 학문적 이유가 없다면 그렇게 하지 않을 것입니다. (그렇게 해야 할 실질적인 이유가 생각나지 않습니다.)

정말로 내용을 잘라내고 싶다면현실적인즉, 코드에 사용 가능한 RAM을 제한하지 않고 페이지 파일 최소 크기를 관찰된 최대 커밋 요금으로 설정하기만 하면 됩니다. 이는 앱과 OS가 그만큼의 커밋된 메모리를 생성하고 이를 모두 참조하더라도 코드에 사용할 수 있는 RAM이 여전히 있다는 것을 의미합니다.

디스크 사용량을 크게 고려하지 않는 한 최대 크기를 최소의 2배로 제한할 이유도 없습니다.

알다시피, 시스템에 필요한 것보다 더 큰 페이지 파일을 갖는 것은 디스크 공간 사용량 외에는 해를 끼치지 않습니다. 특히 필요한 것보다 큰 페이지 파일은 더 많은 페이징을 "유인"하지 않습니다. 그리고 겨우 충분히 크게 만드는 것에는 이점이 없습니다(다시 말하지만, 디스크 공간 사용량 제외). 그럼 왜 귀찮게? 즉, 이 연습에서 차지하는 디스크 공간을 제외하고는 아무것도 "최적화"하지 않습니다.

커밋 제한이 부족하면 앱 충돌(따라서 데이터 손실)이 발생할 수 있고 드문 경우지만 시스템 충돌이 발생한다는 점을 고려하면 페이지 파일을 가능한 한 작게 만드는 데는 별로 관심이 없습니다.

반면에 시스템이 페이지 파일에 많이 써야 하고 사용 가능한 RAM이 2.5GB만 있는 Windows 7 시스템에서 시스템이 사용하는 것보다 상당히 큰 페이지 파일을 갖게 되면 그렇게 될 것이라고 생각합니다. 속도를 높이세요. 왜? 여유 공간이 많으면 페이지 파일에 사용되는 공간 할당 알고리즘이 훨씬 더 빨라질 수 있기 때문입니다.

이 때문에 나는 Pagefile %usage에 대한 PerfMon 카운터가 25% 미만으로 유지되는 것을 보고 싶습니다.

관련 정보