짧은 답변

Question 1

짧은 답변

"메모리 부족" 팝업에는 메모리 한도가 부족하다고 표시됩니다.개인 커밋메모리 - 가상 메모리의 한 유형입니다. RAM(물리적 메모리)이 부족한 것은 아닙니다. 얼마나 중요한지는 중요하지 않습니다.사용 가능가지고 있는 RAM. 사용 가능한 RAM이 많아도 커밋 제한을 초과할 수 없습니다. 커밋 한도는 총RAM(사용 중인지 여부!)에 현재 페이지 파일 크기를 더한 값입니다.

반대로, 커밋 제한을 "사용"하는 것(주로 프로세스 전용 가상 주소 공간 생성)이 반드시 RAM을 사용하는 것은 아닙니다! 그러나 OS는 필요한 경우 저장할 장소가 있다는 것을 알지 않는 한 생성을 허용하지 않습니다. 따라서 RAM 전체 또는 대부분의 RAM을 사용하지 않고도 커밋 제한에 도달할 수 있습니다.

이것이 페이지 파일 없이 실행하면 안되는 이유입니다. 페이지 파일은 실제로 기록되지 않을 수도 있습니다! 하지만 여전히 "메모리 부족" 및 "메모리 부족" 오류를 방지할 수 있습니다.

중간 답변

Windows에는 실제로 RAM 부족에 대한 오류 메시지가 없습니다. 부족한 것은 "커밋 제한"입니다.

해당 버전의 Process Explorer에 있는 "시스템" 그래프의 이름이 잘못되었습니다. "commit Charge"라고 라벨이 붙어 있어야 합니다. (내가 가지고 있는 버전에서는 이를 "시스템 커밋"이라고 합니다. 더 좋지만 여전히 완전히 일관성이 없습니다.) 어쨌든 그래프의 "현재" 높이는 텍스트 섹션에서 "Commit Charge" - "로 표시됩니다. Current'이고, 그래프의 최대 높이는 'Commit Charge' - 'Limit'을 나타냅니다.

"커밋 요금"은 페이지 파일이 지원하는 가상 주소 공간(있는 경우)을 의미합니다. 즉, RAM에 모두 들어갈 수 없는 경우 나머지는 페이지 파일에 저장됩니다. (다른 파일에 의해 지원되거나("매핑된" vas라고 함) 항상 RAM에 있어야 하는 다른 유형의 vas가 있습니다. 후자를 "페이지 불가능"이라고 합니다.) "커밋 제한"은 최대값입니다. "커밋 요금"이 될 수 있습니다. 이는 RAM 크기에 페이지 파일 크기를 더한 것과 같습니다.

분명히 페이지 파일이 없으므로(커밋 제한이 RAM 크기와 같기 때문에 알 수 있습니다) 커밋 제한은 단순히 RAM 크기입니다.

분명히 다양한 프로그램과 OS가 가능한 최대 커밋을 거의 모두 사용했습니다.

이는 RAM이 얼마나 남아 있는지 또는 사용 가능한지와 직접적인 관련이 없습니다. 예, 약 4.5GB RAM을 사용할 수 있습니다. 그렇다고 커밋 제한을 초과할 수 있다는 의미는 아닙니다. 커밋된 메모리는 반드시 RAM을 사용하는 것은 아니며 사용 가능한 RAM 용량에 의해 제한되지 않습니다.

페이지 파일을 다시 활성화해야 합니다. 이렇게 많은 커밋을 사용하면 16GB 페이지 파일을 제안합니다. 왜냐하면 OS가 RAM에 너무 많은 항목을 유지하도록 강제하고 싶지 않고 페이지 파일이 가장 잘 작동하기 때문입니다. 여유 공간이 많거나 RAM을 더 추가하세요. 훨씬 더. 좋은 성능을 위해서는 페이지 파일에 의해 지원되지 않지만 다른 파일로 페이지 아웃될 수 있는 코드 및 기타 항목을 위한 RAM 공간이 충분해야 합니다.

매우 긴 답변

(그러나 여전히 메모리 관리 장보다 훨씬 짧습니다.Windows 내부...)

프로그램이 100MB의 프로세스 전용 가상 메모리를 할당한다고 가정합니다. 이는 "commit" 옵션을 사용하여 VirtualAlloc 호출을 통해 수행됩니다. 이로 인해 "커밋 요금"이 100MB 증가합니다. 하지만 이 "할당"은 실제로 RAM을 사용하지 않습니다! RAM은 새로 커밋된 일부 경우에만 사용됩니다.가상 주소 공간처음으로 액세스됩니다.

RAM이 최종적으로 사용되는 방식

(그렇다면)

새로 커밋된 공간에 대한 최초 액세스는 거의 항상 메모리 쓰기입니다(새로 할당된 개인 vas를 쓰기 전에 읽는 것은 초기 내용이 엄밀히 말하면 정의되지 않았기 때문에 거의 항상 프로그래밍 오류입니다). 그러나 읽거나 쓰는 결과는 새로 할당된 vas의 페이지를 처음 터치할 때입니다.페이지 오류. "오류"라는 단어가 나쁘게 들리더라도 페이지 오류는 가상 메모리 OS에서 완전히 예상되는 이벤트이자 필수 이벤트이기도 합니다.

이러한 특정 유형의 페이지 오류에 대한 응답으로 호출기(때때로 "Mm"으로 약칭하는 OS 메모리 관리자의 일부)는 다음을 수행합니다.

RAM의 물리적 페이지를 할당합니다(이상적으로는 제로 페이지 목록에서 나오지만 어떤 경우에도 Windows에서 "사용 가능"이라고 부르는 것, 즉 선호하는 순서대로 제로, 여유 또는 대기 페이지 목록에서 나옵니다).
~을 채우다페이지 테이블 항목물리적 페이지를 가상 페이지와 연결합니다. 그리고 마지막으로
페이지 결함 예외를 닫습니다.

그런 다음 메모리 참조를 수행한 코드는 페이지 오류를 일으킨 명령을 다시 실행하고 이번에는 참조가 성공합니다.

우리는 페이지가 프로세스 작업 세트와 RAM에 "장애"가 발생했다고 말합니다. 작업 관리자에서는 프로세스의 "개인 작업 세트"가 한 페이지(4KB) 증가한 것으로 나타납니다. 그리고 사용 가능한 실제 메모리가 한 페이지로 줄어듭니다. (후자는 바쁜 컴퓨터에서는 알아차리기 어려울 수 있습니다.)

참고 1:이 페이지 오류에는 디스크에서 읽은 내용이 포함되지 않았습니다. 이전에 액세스한 적이 없는 커밋된 가상 메모리 페이지는 디스크에서 생명을 시작하지 않습니다. 디스크에 읽을 수 있는 공간이 없습니다.~에서. 이는 이전에 사용 가능한 RAM 페이지에서 간단히 "구체화"됩니다. 실제로 통계적으로 대부분의 페이지 오류는 다른 프로세스를 위해 이미 RAM에 있는 공유 페이지나 페이지 캐시(대기 또는 수정된 목록) 또는 이와 같은 "요구 0" 페이지로 RAM에서 해결됩니다.

노트 2:"Available"에서 단 한 페이지, 즉 4096바이트가 필요합니다. 커밋되기 전에는 건드리지 않은 주소 공간은 일반적으로 각 페이지가 처음으로 "접속"되므로 한 번에 한 페이지씩만 실현됩니다. 한 번에 더 많은 일을 한다고 해서 개선이나 이점이 없을 것입니다. 시간은 n배만 걸릴 것입니다. 이와 대조적으로 디스크에서 페이지를 읽어야 하는 경우 디스크 읽기 시간의 대부분이 실제 데이터 전송이 아닌 작업별 오버헤드에 있기 때문에 어느 정도 "미리 읽기"가 시도됩니다. "커밋된" 양은 100MB로 유지됩니다. 하나 이상의 페이지에 오류가 발생했다고 해서 커밋 요금이 줄어들지는 않습니다.

노트 3:4GB의 "사용 가능한" RAM이 있다고 가정해 보겠습니다. 이는 이미 할당되었지만 이전에 참조된 적이 없는 커밋된 메모리를 RAM이 부족해지기 전에 약 백만 번 더(4GB/4096) 참조할 수 있음을 의미합니다. David Cutler와 Lou Perazzoli가 의도한 대로 페이지 파일이 있는 경우 RAM에서 가장 오래 전에 참조된 페이지 중 일부가 디스크에 저장된 다음 이러한 최신 페이지 오류를 해결하는 데 사용할 수 있게 됩니다. (실제로 OS는 그보다 먼저 "작업 세트 트리밍"과 같은 RAM 회수 방법을 시작하고 페이지 파일에 대한 실제 쓰기는 효율성을 위해 수정된 페이지 목록에 캐시되고 일괄 처리되며...) 그 중 어느 것도 영향을 미치지 않습니다. "커밋된" 개수. 그러나 "커밋 제한"과 관련이 있습니다. RAM에 "커밋된" 메모리 전체를 위한 공간이 없으면 초과분을 페이지 파일에 보관할 수 있습니다. 따라서 페이지 파일의 크기는 "커밋 제한"에 영향을 줍니다.

그리고 그런 일이 계속 일어나고 있습니다 ...

하지만 우리가 그 백만 개 이상의 참조를 수행하지 않았고 여전히 "사용 가능한" 페이지가 약 4GB에 해당한다고 가정해 보겠습니다. 이제 동일한 프로세스(또는 다른 프로세스가 중요하지 않음)가 또 다른 VirtualAlloc(이번에는 200MB 커밋됨)을 수행한다고 가정해 보겠습니다. 다시 말하지만, 이 200MB는 커밋 요금에 추가되며 사용 가능한 RAM은 제거되지 않습니다. 단순히 VirtualAlloc'ing 주소 공간은 해당하는 양의 RAM을 사용하지 않으며, "사용 가능한" RAM이 낮다고 해서 VirtualAlloc이 수행할 수 있는 주소 공간의 양이 제한되지는 않습니다(또한 사용 가능한 RAM이 많아도 증가하지 않습니다).

(글쎄요... 약간의 오버헤드가 있습니다. 이는 2MB(PAE가 아닌 x86 시스템을 사용하는 경우 4MB)마다 페이지 테이블에 사용되는 하나의 (페이지 가능!) 페이지에 해당합니다. 가상 주소 공간이 할당되며, 사실상 연속적으로 할당된 각 범위에 대해 수십 바이트의 "가상 주소 설명자"가 있습니다.)

이런 식으로 가능하며 일반적입니다! - 적은 양의 RAM만 사용하면서 많은 "커밋 요금"을 소모합니다.

그렇다면 가상 주소 공간을 "커밋"해도 RAM을 사용하지 않는다면 왜 제한이 있어야 할까요?

"커밋 요금"은 잠재력을 나타내기 때문입니다.미래저장공간 활용. "커밋 제한"은 이러한 할당을 보유하는 데 사용할 수 있는 총 저장소 크기(RAM + 페이지 파일 공간)를 나타냅니다.실제로 참조되어 어딘가에 저장되어야 합니다.

Mm이 VirtualAlloc 요청을 승인하면 할당된 영역에 대한 모든 후속 메모리 액세스가 성공할 것이라고 약속합니다("약속"). 페이지 오류가 발생할 수 있지만 오류는 모두 해결될 수 있습니다. RAM이든 페이지 파일이든 모든 페이지의 내용을 보관할 수 있는 적절한 저장소가 있기 때문입니다. Mm은 저장 공간의 양(커밋 제한)과 이미 "커밋된" 양(현재 커밋 요금)을 알고 있기 때문에 이를 알고 있습니다.

(그러나 아직 모든 페이지에 액세스할 필요는 없으므로 주어진 시간에 커밋된 양에 따른 실제 스토리지가 반드시 필요한 것은 아닙니다.)

그럼... "시스템 메모리 부족"은 어떻습니까?

VirtualAlloc을 시도하고 현재 커밋 요금과 요청된 할당 크기를 더하면 커밋 제한을 초과하게 되고 OS는 커밋 제한을 늘리기 위해 페이지 파일을 확장할 수 없습니다. "메모리 부족" 팝업이 표시됩니다. 실행되고 프로세스는 VirtualAlloc 호출 FAIL을 확인합니다. 대부분의 프로그램은 그 시점에서 손을 내밀고 죽습니다. 일부는 호출이 성공했다고 가정하고 맹목적으로 계속 진행하다가 나중에 자신이 할당했다고 생각한 영역을 참조하려고 시도할 때 실패합니다.

다시 한 번(반복해서 죄송합니다): 사용 가능한 RAM의 양은 중요하지 않습니다. OS는 RAM 또는 페이지 파일 공간을 약속했습니다.~ 할 것이다필요할 때 사용할 수 있지만 해당 약속은 "사용 가능"에서 제외되지 않습니다. 사용 가능한 RAM은 커밋된 VM에서만 사용됩니다.참조됨처음으로 이것이 "결함"을 일으키는 원인이 됩니다... 즉, 물리적 메모리에서 실현됩니다. 그리고 단순히 가상 메모리를 커밋(=할당)하는 것만으로는 그렇게 되지 않습니다. 무료 가상 주소 공간만 가져와서 사용 가능한 가상 주소 공간을 만듭니다.

그러나 "메모리 부족"의 경우 커밋된 메모리에 대한 할당 요청이 있었고 OS는 이 새로운 요청의 크기에 현재 커밋 요금을 추가했으며 총합은 다음과 같습니다.더커밋 한도보다 따라서 OS가 이 새로운 것을 승인했다면,그리고그 이후에는 모든 공간이 참조되므로 이를 모두 저장할 실제 장소(RAM + 페이지 파일)가 없습니다.

OS에서는 이를 허용하지 않습니다. 최악의 경우에 보관할 수 있는 공간보다 더 많은 VAS가 할당되는 것을 허용하지 않습니다. 모든 VAS가 "오류"가 발생하더라도 마찬가지입니다. 이것이 "커밋 제한"의 목적입니다.

내가 세 번 말하노니 세 번 말하노라 내가 세 번 말하노라"사용 가능한" RAM의 양은 중요하지 않습니다. 커밋된 가상 공간이 실제로 아직 모든 저장 공간을 사용하고 있지 않다는 점은 중요하지 않습니다. Windows는 나중에 모든 오류가 발생할 수 있는 경우가 아니면 가상 할당에 "커밋"할 수 없습니다.

주로 코드 및 대용량 데이터 파일에 대한 액세스에 사용되는 "매핑된" vas라는 또 다른 유형의 vas가 있지만 "커밋 요금"에 대해 요금이 부과되지 않으며 "커밋 한도"에 의해 제한되지 않습니다. 이는 자체 저장 영역, 즉 여기에 "매핑"된 파일이 함께 제공되기 때문입니다. "매핑된" vas의 유일한 제한은 매핑된 파일을 위해 가지고 있는 디스크 공간의 양과 이를 매핑할 프로세스의 여유 vas의 양입니다.

그런데 시스템을 보면 아직 커밋 한도에 도달하지 못한 것 같죠?

이는 기본적으로 측정 및 기록 유지 문제입니다. VirtualAlloc 호출이 이미 시도되고 실패한 후 시스템을 보고 있습니다.

커밋 제한이 500MB만 남았고 일부 프로그램에서 VirtualAlloc 600MB를 시도했다고 가정해 보겠습니다. 시도가 실패합니다. 그런 다음 시스템을 보고 "뭐야? 아직 500MB가 남았어!"라고 말합니다. 실제로 그때까지 훨씬 더 많은 것이 남아 있을 수 있습니다. 문제의 프로세스가 해당 시점에 완전히 사라질 가능성이 높기 때문에 이전에 할당된 커밋된 메모리가 모두 해제되었기 때문입니다.

문제는 시간을 되돌아보고 커밋 요금이 무엇인지 확인할 수 없다는 것입니다.~였다할당 시도가 이루어진 순간. 그리고 당신은 또한 그 시도가 얼마나 많은 공간을 차지했는지 모릅니다. 따라서 시도가 실패한 이유나 시도가 작동하려면 얼마나 더 많은 "커밋 제한"이 필요했는지 확실히 알 수 없습니다.

나는 "시스템은부족기억에". 그게 뭐죠?

위의 경우 OS가 페이지 파일을 확장할 수 있는 경우(예: 기본 "시스템 관리" 설정으로 두거나 관리하지만 최대값을 초기 값보다 크게 설정하고 여유 디스크 공간이 충분함) 이러한 확장은 VirtualAlloc 호출이 성공할 수 있을 만큼 커밋 제한을 늘린 다음... Mm이 페이지 파일을 확장하고 VirtualAlloc 호출이 성공합니다.

그러면 "시스템이 메모리 부족으로 실행되고 있습니다"라는 메시지가 표시됩니다. 이는 완화 없이 상황이 계속되면 곧 "메모리 부족" 경고를 보게 될 것이라는 조기 경고입니다. 일부 앱을 종료할 시간입니다. 브라우저 창부터 시작하겠습니다.

그리고 그게 좋은 일이라고 생각하시나요? 페이지 파일 확장은 사악합니다 !!!

아니요, 그렇지 않습니다. OS는 실제로 기존 파일을 "확장"하지 않습니다. 단지 새로운 범위를 할당합니다. 효과는 다른 비연속 파일과 매우 유사합니다. 이전 페이지 파일 내용은 현재 위치에 그대로 유지됩니다. 새로운 장소나 그와 비슷한 곳으로 복사할 필요가 없습니다. 대부분의 페이지 파일 IO는 페이지 파일 크기에 비해 상대적으로 작은 청크로 구성되어 있기 때문에 특정 전송이 범위 경계를 넘을 가능성은 매우 드뭅니다. 따라서 조각화가 너무 과도하지 않는 한 크게 문제가 되지 않습니다.

마지막으로 확장에 "커밋된" 공간이 있는 모든 프로세스가 종료되면(더 빠르지 않으면 OS 종료 시) 익스텐트가 자동으로 해제되고 페이지 파일은 이전 크기와 할당으로 돌아갑니다. 이전에 연속되어 있었다면 또 그렇습니다.

따라서 페이지 파일 확장을 허용하는 것은 완전히 자유로운 안전망 역할을 합니다. 이를 허용했지만 시스템에 전혀 필요하지 않은 경우 시스템은 흔히 주장하는 것처럼 "페이지 파일을 지속적으로 확장 및 축소"하지 않으므로 비용이 발생합니다.아무것도 아님. 그리고 꼭 필요한 경우 "가상 메모리 부족" 오류로 인해 앱이 충돌하는 것을 방지할 수 있습니다.

하지만 하지만 하지만...

나는 수십 개의 웹 사이트에서 페이지 파일 확장을 허용하면 Windows가 페이지 파일을 지속적으로 확장하고 축소하며 이로 인해 조각 모음을 할 때까지 페이지 파일이 조각화된다는 내용을 읽었습니다.

그들은 단지 틀렸습니다.

"메모리 부족"(또는 이전 버전에서는 "가상 메모리 부족") 팝업을 본 적이 없다면 OS가 페이지 파일을 확장한 적이 없는 것입니다.

해당 팝업이 표시되면 초기 페이지 파일 크기가 너무 작다는 의미입니다. (나는 관찰된 최대 사용량의 약 4배로 설정하고 싶습니다. 즉, "%pagefile use peak" 성능 카운터는 25% 미만이어야 합니다. 이유: 페이지 파일 공간은 다른 힙처럼 관리되며 여유 공간이 많을 때 가장 잘 작동합니다. 놀러 가세요.)

그런데 왜 그들은 그냥...

OS가 할당이 발생하도록 허용한 다음 할당을 허용해야 한다고 주장할 수도 있습니다.참고자료페이지 결함을 해결하는 데 사용할 수 있는 RAM이 없으면 실패합니다. 즉, 위에서 초기 페이지 오류가 어떻게 작동하는지 설명했는데, 사용 가능한 RAM이 없어서 "사용 가능한 RAM의 물리적 페이지 할당"(1단계)을 수행할 수 없다면 어떻게 될까요?그리고사용할 수 있도록 페이지를 표시할 수 있는 공간이 더 이상 남아 있지 않습니까?

그러면 호출기는 페이지 오류를 해결할 수 없습니다. 예외(페이지 오류)가 오류가 발생한 스레드에 다시 보고되도록 허용해야 하며 아마도 다른 예외 코드로 변경되었을 수 있습니다.

설계 철학은 VirtualAlloc이 커밋 제한을 초과한 경우 주소 대신 0(기술적으로는 NULL 포인터)을 반환한다는 것입니다. 그리고 프로그래머가 VirtualAlloc 호출이 실패할 수 있다는 것을 알 것으로 기대하는 것은 전적으로 합리적입니다. 따라서 프로그래머는 해당 사례를 확인하고 이에 대한 합리적인 조치를 취해야 합니다(예: 해당 지점까지 작업을 저장한 다음 프로그램을 "정상적으로" 종료할 수 있는 기회 제공). (프로그래머: malloc, new 등에서 NULL 포인터 반환을 확인합니까? 그렇다면 왜 여기서 확인하지 않겠습니까?)

그러나 프로그래머는 다음과 같은 간단한 메모리 참조가

i = 0;             // initialize loop counter

실패할 수 있습니다. 성공적으로 커밋된 주소 공간 영역에 있는 경우에는 그렇지 않습니다. (또는 매핑된 주소 공간도 마찬가지입니다.) 그러나 "오버 커밋된 할당을 허용하고 메모리 참조는 실패하도록 합니다"라는 철학을 따른다면 이런 일이 발생할 수 있습니다.

불행하게도 위의 코드 줄에 있는 것과 같은 메모리 참조에는 잘못된 상태를 반환하는 편리한 방법이 없습니다! 그들은 단지 그래야만 해일하다, 덧셈과 뺄셈과 같습니다. 그러한 실패를 보고하는 유일한 방법은 예외로 보는 것입니다. 따라서 이를 처리하려면 프로그래머는 전체 프로그램을 예외 처리기로 래핑해야 합니다. (시도해 보세요...잡아 보세요.)

그렇게 할 수 있습니다... 그러나 예외가 발생할 수 있는 지점이 코드에 너무 많기 때문에 핸들러가 이러한 예외에 대한 응답으로 "올바른 일을 수행"하는 방법을 아는 것은 어려울 것입니다. (구체적으로는 다음과 같은 경우에 발생할 수 있습니다.모든VirtualAlloc'd 메모리에 대한 메모리 참조, malloc 또는 new로 할당된 메모리... 그리고 스택도 VirtualAlloc'd이므로 모든 로컬 변수에 대한 메모리 참조입니다.

간단히 말해서, 이러한 경우에 프로그램이 정상적으로 실패하도록 만드는 것은 매우 어려울 것입니다.

반면에 VirtualAlloc(또는 malloc이나 new, 정확히 똑같지는 않지만)에서 NULL 포인터 반환을 확인한 다음 합리적인 작업을 수행하는 것은 매우 쉽습니다... 계속해서 프로그램에 필요한 가상 공간이 무엇이든 수행하세요. 그리고 사용자에게 지금까지의 작업을 저장할 것인지 물어볼 수도 있습니다. (물론, 너무 많은 앱이 그 정도의 작업도 수행하지 않습니다.)

다른 커밋 사용자

또한 "커밋 제한"은 페이징 및 비페이징 풀, PFN 목록 등과 같은 OS의 다양한 할당에 의해 줄어들지 않습니다. 이것들은 발생하는 대로 요금이 부과됩니다. 커밋 요금이나 커밋 제한은 비디오 RAM이나 비디오 RAM "창" 크기에도 영향을 받지 않습니다.

직접 테스트해보세요

SysInternals 사이트의 testlimit 도구를 사용하여 이 모든 것을 데모할 수 있습니다. 옵션 -m은 커밋된 주소 공간을 할당하지만 이를 "접촉"하지 않으므로 RAM 할당이 발생하지 않습니다. 반면 -d 옵션은 페이지를 할당하고 참조하므로 커밋 요금이 증가하고 사용 가능한 RAM이 감소합니다.

참고자료

Windows 내부루시노비치(Russinovich), 솔로몬(Solomon), 이오네스쿠(Ionescu). testlimit 도구를 사용하여 이러한 모든 사항을 증명할 수 있는 데모도 있습니다. 그러나 이 내용이 길다고 생각하신다면 주의하시기 바랍니다. Mm 장만 해도 200페이지에 달합니다. 위의 내용은 매우 단순화된 버전입니다. (소개 부분의 "감사의 말씀" 섹션도 살펴보시기 바랍니다.)

또한보십시오MSDN VirtualAlloc 설명서

Answer

짧은 답변

"메모리 부족" 팝업에는 메모리 한도가 부족하다고 표시됩니다.개인 커밋메모리 - 가상 메모리의 한 유형입니다. RAM(물리적 메모리)이 부족한 것은 아닙니다. 얼마나 중요한지는 중요하지 않습니다.사용 가능가지고 있는 RAM. 사용 가능한 RAM이 많아도 커밋 제한을 초과할 수 없습니다. 커밋 한도는 총RAM(사용 중인지 여부!)에 현재 페이지 파일 크기를 더한 값입니다.

반대로, 커밋 제한을 "사용"하는 것(주로 프로세스 전용 가상 주소 공간 생성)이 반드시 RAM을 사용하는 것은 아닙니다! 그러나 OS는 필요한 경우 저장할 장소가 있다는 것을 알지 않는 한 생성을 허용하지 않습니다. 따라서 RAM 전체 또는 대부분의 RAM을 사용하지 않고도 커밋 제한에 도달할 수 있습니다.

이것이 페이지 파일 없이 실행하면 안되는 이유입니다. 페이지 파일은 실제로 기록되지 않을 수도 있습니다! 하지만 여전히 "메모리 부족" 및 "메모리 부족" 오류를 방지할 수 있습니다.

중간 답변

Windows에는 실제로 RAM 부족에 대한 오류 메시지가 없습니다. 부족한 것은 "커밋 제한"입니다.

해당 버전의 Process Explorer에 있는 "시스템" 그래프의 이름이 잘못되었습니다. "commit Charge"라고 라벨이 붙어 있어야 합니다. (내가 가지고 있는 버전에서는 이를 "시스템 커밋"이라고 합니다. 더 좋지만 여전히 완전히 일관성이 없습니다.) 어쨌든 그래프의 "현재" 높이는 텍스트 섹션에서 "Commit Charge" - "로 표시됩니다. Current'이고, 그래프의 최대 높이는 'Commit Charge' - 'Limit'을 나타냅니다.

"커밋 요금"은 페이지 파일이 지원하는 가상 주소 공간(있는 경우)을 의미합니다. 즉, RAM에 모두 들어갈 수 없는 경우 나머지는 페이지 파일에 저장됩니다. (다른 파일에 의해 지원되거나("매핑된" vas라고 함) 항상 RAM에 있어야 하는 다른 유형의 vas가 있습니다. 후자를 "페이지 불가능"이라고 합니다.) "커밋 제한"은 최대값입니다. "커밋 요금"이 될 수 있습니다. 이는 RAM 크기에 페이지 파일 크기를 더한 것과 같습니다.

분명히 페이지 파일이 없으므로(커밋 제한이 RAM 크기와 같기 때문에 알 수 있습니다) 커밋 제한은 단순히 RAM 크기입니다.

분명히 다양한 프로그램과 OS가 가능한 최대 커밋을 거의 모두 사용했습니다.

이는 RAM이 얼마나 남아 있는지 또는 사용 가능한지와 직접적인 관련이 없습니다. 예, 약 4.5GB RAM을 사용할 수 있습니다. 그렇다고 커밋 제한을 초과할 수 있다는 의미는 아닙니다. 커밋된 메모리는 반드시 RAM을 사용하는 것은 아니며 사용 가능한 RAM 용량에 의해 제한되지 않습니다.

페이지 파일을 다시 활성화해야 합니다. 이렇게 많은 커밋을 사용하면 16GB 페이지 파일을 제안합니다. 왜냐하면 OS가 RAM에 너무 많은 항목을 유지하도록 강제하고 싶지 않고 페이지 파일이 가장 잘 작동하기 때문입니다. 여유 공간이 많거나 RAM을 더 추가하세요. 훨씬 더. 좋은 성능을 위해서는 페이지 파일에 의해 지원되지 않지만 다른 파일로 페이지 아웃될 수 있는 코드 및 기타 항목을 위한 RAM 공간이 충분해야 합니다.

매우 긴 답변

(그러나 여전히 메모리 관리 장보다 훨씬 짧습니다.Windows 내부...)

프로그램이 100MB의 프로세스 전용 가상 메모리를 할당한다고 가정합니다. 이는 "commit" 옵션을 사용하여 VirtualAlloc 호출을 통해 수행됩니다. 이로 인해 "커밋 요금"이 100MB 증가합니다. 하지만 이 "할당"은 실제로 RAM을 사용하지 않습니다! RAM은 새로 커밋된 일부 경우에만 사용됩니다.가상 주소 공간처음으로 액세스됩니다.

RAM이 최종적으로 사용되는 방식

(그렇다면)

새로 커밋된 공간에 대한 최초 액세스는 거의 항상 메모리 쓰기입니다(새로 할당된 개인 vas를 쓰기 전에 읽는 것은 초기 내용이 엄밀히 말하면 정의되지 않았기 때문에 거의 항상 프로그래밍 오류입니다). 그러나 읽거나 쓰는 결과는 새로 할당된 vas의 페이지를 처음 터치할 때입니다.페이지 오류. "오류"라는 단어가 나쁘게 들리더라도 페이지 오류는 가상 메모리 OS에서 완전히 예상되는 이벤트이자 필수 이벤트이기도 합니다.

이러한 특정 유형의 페이지 오류에 대한 응답으로 호출기(때때로 "Mm"으로 약칭하는 OS 메모리 관리자의 일부)는 다음을 수행합니다.

RAM의 물리적 페이지를 할당합니다(이상적으로는 제로 페이지 목록에서 나오지만 어떤 경우에도 Windows에서 "사용 가능"이라고 부르는 것, 즉 선호하는 순서대로 제로, 여유 또는 대기 페이지 목록에서 나옵니다).
~을 채우다페이지 테이블 항목물리적 페이지를 가상 페이지와 연결합니다. 그리고 마지막으로
페이지 결함 예외를 닫습니다.

그런 다음 메모리 참조를 수행한 코드는 페이지 오류를 일으킨 명령을 다시 실행하고 이번에는 참조가 성공합니다.

우리는 페이지가 프로세스 작업 세트와 RAM에 "장애"가 발생했다고 말합니다. 작업 관리자에서는 프로세스의 "개인 작업 세트"가 한 페이지(4KB) 증가한 것으로 나타납니다. 그리고 사용 가능한 실제 메모리가 한 페이지로 줄어듭니다. (후자는 바쁜 컴퓨터에서는 알아차리기 어려울 수 있습니다.)

참고 1:이 페이지 오류에는 디스크에서 읽은 내용이 포함되지 않았습니다. 이전에 액세스한 적이 없는 커밋된 가상 메모리 페이지는 디스크에서 생명을 시작하지 않습니다. 디스크에 읽을 수 있는 공간이 없습니다.~에서. 이는 이전에 사용 가능한 RAM 페이지에서 간단히 "구체화"됩니다. 실제로 통계적으로 대부분의 페이지 오류는 다른 프로세스를 위해 이미 RAM에 있는 공유 페이지나 페이지 캐시(대기 또는 수정된 목록) 또는 이와 같은 "요구 0" 페이지로 RAM에서 해결됩니다.

노트 2:"Available"에서 단 한 페이지, 즉 4096바이트가 필요합니다. 커밋되기 전에는 건드리지 않은 주소 공간은 일반적으로 각 페이지가 처음으로 "접속"되므로 한 번에 한 페이지씩만 실현됩니다. 한 번에 더 많은 일을 한다고 해서 개선이나 이점이 없을 것입니다. 시간은 n배만 걸릴 것입니다. 이와 대조적으로 디스크에서 페이지를 읽어야 하는 경우 디스크 읽기 시간의 대부분이 실제 데이터 전송이 아닌 작업별 오버헤드에 있기 때문에 어느 정도 "미리 읽기"가 시도됩니다. "커밋된" 양은 100MB로 유지됩니다. 하나 이상의 페이지에 오류가 발생했다고 해서 커밋 요금이 줄어들지는 않습니다.

노트 3:4GB의 "사용 가능한" RAM이 있다고 가정해 보겠습니다. 이는 이미 할당되었지만 이전에 참조된 적이 없는 커밋된 메모리를 RAM이 부족해지기 전에 약 백만 번 더(4GB/4096) 참조할 수 있음을 의미합니다. David Cutler와 Lou Perazzoli가 의도한 대로 페이지 파일이 있는 경우 RAM에서 가장 오래 전에 참조된 페이지 중 일부가 디스크에 저장된 다음 이러한 최신 페이지 오류를 해결하는 데 사용할 수 있게 됩니다. (실제로 OS는 그보다 먼저 "작업 세트 트리밍"과 같은 RAM 회수 방법을 시작하고 페이지 파일에 대한 실제 쓰기는 효율성을 위해 수정된 페이지 목록에 캐시되고 일괄 처리되며...) 그 중 어느 것도 영향을 미치지 않습니다. "커밋된" 개수. 그러나 "커밋 제한"과 관련이 있습니다. RAM에 "커밋된" 메모리 전체를 위한 공간이 없으면 초과분을 페이지 파일에 보관할 수 있습니다. 따라서 페이지 파일의 크기는 "커밋 제한"에 영향을 줍니다.

그리고 그런 일이 계속 일어나고 있습니다 ...

하지만 우리가 그 백만 개 이상의 참조를 수행하지 않았고 여전히 "사용 가능한" 페이지가 약 4GB에 해당한다고 가정해 보겠습니다. 이제 동일한 프로세스(또는 다른 프로세스가 중요하지 않음)가 또 다른 VirtualAlloc(이번에는 200MB 커밋됨)을 수행한다고 가정해 보겠습니다. 다시 말하지만, 이 200MB는 커밋 요금에 추가되며 사용 가능한 RAM은 제거되지 않습니다. 단순히 VirtualAlloc'ing 주소 공간은 해당하는 양의 RAM을 사용하지 않으며, "사용 가능한" RAM이 낮다고 해서 VirtualAlloc이 수행할 수 있는 주소 공간의 양이 제한되지는 않습니다(또한 사용 가능한 RAM이 많아도 증가하지 않습니다).

(글쎄요... 약간의 오버헤드가 있습니다. 이는 2MB(PAE가 아닌 x86 시스템을 사용하는 경우 4MB)마다 페이지 테이블에 사용되는 하나의 (페이지 가능!) 페이지에 해당합니다. 가상 주소 공간이 할당되며, 사실상 연속적으로 할당된 각 범위에 대해 수십 바이트의 "가상 주소 설명자"가 있습니다.)

이런 식으로 가능하며 일반적입니다! - 적은 양의 RAM만 사용하면서 많은 "커밋 요금"을 소모합니다.

그렇다면 가상 주소 공간을 "커밋"해도 RAM을 사용하지 않는다면 왜 제한이 있어야 할까요?

"커밋 요금"은 잠재력을 나타내기 때문입니다.미래저장공간 활용. "커밋 제한"은 이러한 할당을 보유하는 데 사용할 수 있는 총 저장소 크기(RAM + 페이지 파일 공간)를 나타냅니다.실제로 참조되어 어딘가에 저장되어야 합니다.

Mm이 VirtualAlloc 요청을 승인하면 할당된 영역에 대한 모든 후속 메모리 액세스가 성공할 것이라고 약속합니다("약속"). 페이지 오류가 발생할 수 있지만 오류는 모두 해결될 수 있습니다. RAM이든 페이지 파일이든 모든 페이지의 내용을 보관할 수 있는 적절한 저장소가 있기 때문입니다. Mm은 저장 공간의 양(커밋 제한)과 이미 "커밋된" 양(현재 커밋 요금)을 알고 있기 때문에 이를 알고 있습니다.

(그러나 아직 모든 페이지에 액세스할 필요는 없으므로 주어진 시간에 커밋된 양에 따른 실제 스토리지가 반드시 필요한 것은 아닙니다.)

그럼... "시스템 메모리 부족"은 어떻습니까?

VirtualAlloc을 시도하고 현재 커밋 요금과 요청된 할당 크기를 더하면 커밋 제한을 초과하게 되고 OS는 커밋 제한을 늘리기 위해 페이지 파일을 확장할 수 없습니다. "메모리 부족" 팝업이 표시됩니다. 실행되고 프로세스는 VirtualAlloc 호출 FAIL을 확인합니다. 대부분의 프로그램은 그 시점에서 손을 내밀고 죽습니다. 일부는 호출이 성공했다고 가정하고 맹목적으로 계속 진행하다가 나중에 자신이 할당했다고 생각한 영역을 참조하려고 시도할 때 실패합니다.

다시 한 번(반복해서 죄송합니다): 사용 가능한 RAM의 양은 중요하지 않습니다. OS는 RAM 또는 페이지 파일 공간을 약속했습니다.~ 할 것이다필요할 때 사용할 수 있지만 해당 약속은 "사용 가능"에서 제외되지 않습니다. 사용 가능한 RAM은 커밋된 VM에서만 사용됩니다.참조됨처음으로 이것이 "결함"을 일으키는 원인이 됩니다... 즉, 물리적 메모리에서 실현됩니다. 그리고 단순히 가상 메모리를 커밋(=할당)하는 것만으로는 그렇게 되지 않습니다. 무료 가상 주소 공간만 가져와서 사용 가능한 가상 주소 공간을 만듭니다.

그러나 "메모리 부족"의 경우 커밋된 메모리에 대한 할당 요청이 있었고 OS는 이 새로운 요청의 크기에 현재 커밋 요금을 추가했으며 총합은 다음과 같습니다.더커밋 한도보다 따라서 OS가 이 새로운 것을 승인했다면,그리고그 이후에는 모든 공간이 참조되므로 이를 모두 저장할 실제 장소(RAM + 페이지 파일)가 없습니다.

OS에서는 이를 허용하지 않습니다. 최악의 경우에 보관할 수 있는 공간보다 더 많은 VAS가 할당되는 것을 허용하지 않습니다. 모든 VAS가 "오류"가 발생하더라도 마찬가지입니다. 이것이 "커밋 제한"의 목적입니다.

내가 세 번 말하노니 세 번 말하노라 내가 세 번 말하노라"사용 가능한" RAM의 양은 중요하지 않습니다. 커밋된 가상 공간이 실제로 아직 모든 저장 공간을 사용하고 있지 않다는 점은 중요하지 않습니다. Windows는 나중에 모든 오류가 발생할 수 있는 경우가 아니면 가상 할당에 "커밋"할 수 없습니다.

주로 코드 및 대용량 데이터 파일에 대한 액세스에 사용되는 "매핑된" vas라는 또 다른 유형의 vas가 있지만 "커밋 요금"에 대해 요금이 부과되지 않으며 "커밋 한도"에 의해 제한되지 않습니다. 이는 자체 저장 영역, 즉 여기에 "매핑"된 파일이 함께 제공되기 때문입니다. "매핑된" vas의 유일한 제한은 매핑된 파일을 위해 가지고 있는 디스크 공간의 양과 이를 매핑할 프로세스의 여유 vas의 양입니다.

그런데 시스템을 보면 아직 커밋 한도에 도달하지 못한 것 같죠?

이는 기본적으로 측정 및 기록 유지 문제입니다. VirtualAlloc 호출이 이미 시도되고 실패한 후 시스템을 보고 있습니다.

커밋 제한이 500MB만 남았고 일부 프로그램에서 VirtualAlloc 600MB를 시도했다고 가정해 보겠습니다. 시도가 실패합니다. 그런 다음 시스템을 보고 "뭐야? 아직 500MB가 남았어!"라고 말합니다. 실제로 그때까지 훨씬 더 많은 것이 남아 있을 수 있습니다. 문제의 프로세스가 해당 시점에 완전히 사라질 가능성이 높기 때문에 이전에 할당된 커밋된 메모리가 모두 해제되었기 때문입니다.

문제는 시간을 되돌아보고 커밋 요금이 무엇인지 확인할 수 없다는 것입니다.~였다할당 시도가 이루어진 순간. 그리고 당신은 또한 그 시도가 얼마나 많은 공간을 차지했는지 모릅니다. 따라서 시도가 실패한 이유나 시도가 작동하려면 얼마나 더 많은 "커밋 제한"이 필요했는지 확실히 알 수 없습니다.

나는 "시스템은부족기억에". 그게 뭐죠?

위의 경우 OS가 페이지 파일을 확장할 수 있는 경우(예: 기본 "시스템 관리" 설정으로 두거나 관리하지만 최대값을 초기 값보다 크게 설정하고 여유 디스크 공간이 충분함) 이러한 확장은 VirtualAlloc 호출이 성공할 수 있을 만큼 커밋 제한을 늘린 다음... Mm이 페이지 파일을 확장하고 VirtualAlloc 호출이 성공합니다.

그러면 "시스템이 메모리 부족으로 실행되고 있습니다"라는 메시지가 표시됩니다. 이는 완화 없이 상황이 계속되면 곧 "메모리 부족" 경고를 보게 될 것이라는 조기 경고입니다. 일부 앱을 종료할 시간입니다. 브라우저 창부터 시작하겠습니다.

그리고 그게 좋은 일이라고 생각하시나요? 페이지 파일 확장은 사악합니다 !!!

아니요, 그렇지 않습니다. OS는 실제로 기존 파일을 "확장"하지 않습니다. 단지 새로운 범위를 할당합니다. 효과는 다른 비연속 파일과 매우 유사합니다. 이전 페이지 파일 내용은 현재 위치에 그대로 유지됩니다. 새로운 장소나 그와 비슷한 곳으로 복사할 필요가 없습니다. 대부분의 페이지 파일 IO는 페이지 파일 크기에 비해 상대적으로 작은 청크로 구성되어 있기 때문에 특정 전송이 범위 경계를 넘을 가능성은 매우 드뭅니다. 따라서 조각화가 너무 과도하지 않는 한 크게 문제가 되지 않습니다.

마지막으로 확장에 "커밋된" 공간이 있는 모든 프로세스가 종료되면(더 빠르지 않으면 OS 종료 시) 익스텐트가 자동으로 해제되고 페이지 파일은 이전 크기와 할당으로 돌아갑니다. 이전에 연속되어 있었다면 또 그렇습니다.

따라서 페이지 파일 확장을 허용하는 것은 완전히 자유로운 안전망 역할을 합니다. 이를 허용했지만 시스템에 전혀 필요하지 않은 경우 시스템은 흔히 주장하는 것처럼 "페이지 파일을 지속적으로 확장 및 축소"하지 않으므로 비용이 발생합니다.아무것도 아님. 그리고 꼭 필요한 경우 "가상 메모리 부족" 오류로 인해 앱이 충돌하는 것을 방지할 수 있습니다.

하지만 하지만 하지만...

나는 수십 개의 웹 사이트에서 페이지 파일 확장을 허용하면 Windows가 페이지 파일을 지속적으로 확장하고 축소하며 이로 인해 조각 모음을 할 때까지 페이지 파일이 조각화된다는 내용을 읽었습니다.

그들은 단지 틀렸습니다.

"메모리 부족"(또는 이전 버전에서는 "가상 메모리 부족") 팝업을 본 적이 없다면 OS가 페이지 파일을 확장한 적이 없는 것입니다.

해당 팝업이 표시되면 초기 페이지 파일 크기가 너무 작다는 의미입니다. (나는 관찰된 최대 사용량의 약 4배로 설정하고 싶습니다. 즉, "%pagefile use peak" 성능 카운터는 25% 미만이어야 합니다. 이유: 페이지 파일 공간은 다른 힙처럼 관리되며 여유 공간이 많을 때 가장 잘 작동합니다. 놀러 가세요.)

그런데 왜 그들은 그냥...

OS가 할당이 발생하도록 허용한 다음 할당을 허용해야 한다고 주장할 수도 있습니다.참고자료페이지 결함을 해결하는 데 사용할 수 있는 RAM이 없으면 실패합니다. 즉, 위에서 초기 페이지 오류가 어떻게 작동하는지 설명했는데, 사용 가능한 RAM이 없어서 "사용 가능한 RAM의 물리적 페이지 할당"(1단계)을 수행할 수 없다면 어떻게 될까요?그리고사용할 수 있도록 페이지를 표시할 수 있는 공간이 더 이상 남아 있지 않습니까?

그러면 호출기는 페이지 오류를 해결할 수 없습니다. 예외(페이지 오류)가 오류가 발생한 스레드에 다시 보고되도록 허용해야 하며 아마도 다른 예외 코드로 변경되었을 수 있습니다.

설계 철학은 VirtualAlloc이 커밋 제한을 초과한 경우 주소 대신 0(기술적으로는 NULL 포인터)을 반환한다는 것입니다. 그리고 프로그래머가 VirtualAlloc 호출이 실패할 수 있다는 것을 알 것으로 기대하는 것은 전적으로 합리적입니다. 따라서 프로그래머는 해당 사례를 확인하고 이에 대한 합리적인 조치를 취해야 합니다(예: 해당 지점까지 작업을 저장한 다음 프로그램을 "정상적으로" 종료할 수 있는 기회 제공). (프로그래머: malloc, new 등에서 NULL 포인터 반환을 확인합니까? 그렇다면 왜 여기서 확인하지 않겠습니까?)

그러나 프로그래머는 다음과 같은 간단한 메모리 참조가

i = 0;             // initialize loop counter

실패할 수 있습니다. 성공적으로 커밋된 주소 공간 영역에 있는 경우에는 그렇지 않습니다. (또는 매핑된 주소 공간도 마찬가지입니다.) 그러나 "오버 커밋된 할당을 허용하고 메모리 참조는 실패하도록 합니다"라는 철학을 따른다면 이런 일이 발생할 수 있습니다.

불행하게도 위의 코드 줄에 있는 것과 같은 메모리 참조에는 잘못된 상태를 반환하는 편리한 방법이 없습니다! 그들은 단지 그래야만 해일하다, 덧셈과 뺄셈과 같습니다. 그러한 실패를 보고하는 유일한 방법은 예외로 보는 것입니다. 따라서 이를 처리하려면 프로그래머는 전체 프로그램을 예외 처리기로 래핑해야 합니다. (시도해 보세요...잡아 보세요.)

그렇게 할 수 있습니다... 그러나 예외가 발생할 수 있는 지점이 코드에 너무 많기 때문에 핸들러가 이러한 예외에 대한 응답으로 "올바른 일을 수행"하는 방법을 아는 것은 어려울 것입니다. (구체적으로는 다음과 같은 경우에 발생할 수 있습니다.모든VirtualAlloc'd 메모리에 대한 메모리 참조, malloc 또는 new로 할당된 메모리... 그리고 스택도 VirtualAlloc'd이므로 모든 로컬 변수에 대한 메모리 참조입니다.

간단히 말해서, 이러한 경우에 프로그램이 정상적으로 실패하도록 만드는 것은 매우 어려울 것입니다.

반면에 VirtualAlloc(또는 malloc이나 new, 정확히 똑같지는 않지만)에서 NULL 포인터 반환을 확인한 다음 합리적인 작업을 수행하는 것은 매우 쉽습니다... 계속해서 프로그램에 필요한 가상 공간이 무엇이든 수행하세요. 그리고 사용자에게 지금까지의 작업을 저장할 것인지 물어볼 수도 있습니다. (물론, 너무 많은 앱이 그 정도의 작업도 수행하지 않습니다.)

다른 커밋 사용자

또한 "커밋 제한"은 페이징 및 비페이징 풀, PFN 목록 등과 같은 OS의 다양한 할당에 의해 줄어들지 않습니다. 이것들은 발생하는 대로 요금이 부과됩니다. 커밋 요금이나 커밋 제한은 비디오 RAM이나 비디오 RAM "창" 크기에도 영향을 받지 않습니다.

직접 테스트해보세요

SysInternals 사이트의 testlimit 도구를 사용하여 이 모든 것을 데모할 수 있습니다. 옵션 -m은 커밋된 주소 공간을 할당하지만 이를 "접촉"하지 않으므로 RAM 할당이 발생하지 않습니다. 반면 -d 옵션은 페이지를 할당하고 참조하므로 커밋 요금이 증가하고 사용 가능한 RAM이 감소합니다.

참고자료

Windows 내부루시노비치(Russinovich), 솔로몬(Solomon), 이오네스쿠(Ionescu). testlimit 도구를 사용하여 이러한 모든 사항을 증명할 수 있는 데모도 있습니다. 그러나 이 내용이 길다고 생각하신다면 주의하시기 바랍니다. Mm 장만 해도 200페이지에 달합니다. 위의 내용은 매우 단순화된 버전입니다. (소개 부분의 "감사의 말씀" 섹션도 살펴보시기 바랍니다.)

또한보십시오MSDN VirtualAlloc 설명서

Question 2

아마 더하면훌륭하게 받아 들여진 대답:

Windows와 대부분의 프로그램은 필요한 만큼의 (가상) 메모리를 커밋할 수 있다고 가정합니다. 이것이 페이지 파일을 비활성화해서는 안 되는 가장 큰 이유 중 하나입니다. 제안된 내용을 참조하세요.사실 2.2~에내 슈퍼유저 질문.

나도 링크해이 훌륭한 서버 오류 답변페이지 파일이 어떻게 작동하는지 명확하게 알 수 있습니다.

많은 사람들은 Windows가 요청 시 페이지 파일에 데이터를 푸시한다고 가정하는 것 같습니다. EG: 무언가가 많은 메모리를 원하지만 그 요구를 충족할 만큼 RAM이 충분하지 않기 때문에 Windows는 마지막 순간에 RAM에서 디스크로 데이터를 쓰기 시작하여 새로운 요구 사항에 맞게 RAM을 확보할 수 있습니다.

이것은 잘못된 것입니다. 후드 아래에는 더 많은 일이 진행되고 있습니다. 일반적으로 Windows는백업 저장소, 이는 메모리에 있는 모든 내용을 디스크 어딘가에서 보고 싶다는 의미입니다. 이제 어떤 일이 발생하여 많은 메모리가 필요할 때 Windows는 RAM을 매우 빠르게 지울 수 있습니다.이미디스크에 저장되어 있으며 요청 시 RAM으로 다시 페이징될 준비가 되어 있습니다. 따라서 페이지 파일에 있는 내용의 대부분이 RAM에도 있다고 말할 수 있습니다. 데이터는선제적으로새로운 메모리 할당 요구를 가속화하기 위해 페이지 파일에 배치됩니다.

추가 읽기제공된다여기

Answer

아마 더하면훌륭하게 받아 들여진 대답:

Windows와 대부분의 프로그램은 필요한 만큼의 (가상) 메모리를 커밋할 수 있다고 가정합니다. 이것이 페이지 파일을 비활성화해서는 안 되는 가장 큰 이유 중 하나입니다. 제안된 내용을 참조하세요.사실 2.2~에내 슈퍼유저 질문.

나도 링크해이 훌륭한 서버 오류 답변페이지 파일이 어떻게 작동하는지 명확하게 알 수 있습니다.

많은 사람들은 Windows가 요청 시 페이지 파일에 데이터를 푸시한다고 가정하는 것 같습니다. EG: 무언가가 많은 메모리를 원하지만 그 요구를 충족할 만큼 RAM이 충분하지 않기 때문에 Windows는 마지막 순간에 RAM에서 디스크로 데이터를 쓰기 시작하여 새로운 요구 사항에 맞게 RAM을 확보할 수 있습니다.

이것은 잘못된 것입니다. 후드 아래에는 더 많은 일이 진행되고 있습니다. 일반적으로 Windows는백업 저장소, 이는 메모리에 있는 모든 내용을 디스크 어딘가에서 보고 싶다는 의미입니다. 이제 어떤 일이 발생하여 많은 메모리가 필요할 때 Windows는 RAM을 매우 빠르게 지울 수 있습니다.이미디스크에 저장되어 있으며 요청 시 RAM으로 다시 페이징될 준비가 되어 있습니다. 따라서 페이지 파일에 있는 내용의 대부분이 RAM에도 있다고 말할 수 있습니다. 데이터는선제적으로새로운 메모리 할당 요구를 가속화하기 위해 페이지 파일에 배치됩니다.

추가 읽기제공된다여기

짧은 답변

답변1

짧은 답변

중간 답변

매우 긴 답변

RAM이 최종적으로 사용되는 방식

그리고 그런 일이 계속 일어나고 있습니다 ...

그렇다면 가상 주소 공간을 "커밋"해도 RAM을 사용하지 않는다면 왜 제한이 있어야 할까요?

그럼... "시스템 메모리 부족"은 어떻습니까?

그런데 시스템을 보면 아직 커밋 한도에 도달하지 못한 것 같죠?

나는 "시스템은부족기억에". 그게 뭐죠?

그리고 그게 좋은 일이라고 생각하시나요? 페이지 파일 확장은 사악합니다 !!!

하지만 하지만 하지만...

그런데 왜 그들은 그냥...

다른 커밋 사용자

직접 테스트해보세요

참고자료

답변2

관련 정보