Windows 10에서 메모리/커밋 요금은 어떻게 작동하나요?

Question

커밋 요금이 단지잠재적인- 그러나 "원하는 경우 사용 가능" 보장 - 가상 메모리를 사용하는 반면, 본질적으로 "커밋된" 메모리에서 사용되는 RAM인 "개인 작업 세트"는실제페이지 파일 공간과 마찬가지로 사용합니다. (그러나 RAM을 사용하는 다른 것들이 있기 때문에 이것이 RAM 사용의 전부는 아닙니다.)

32비트 시스템에 대해 이야기하고 있다고 가정해 보겠습니다. 따라서 각 프로세스에서 사용할 수 있는 최대 가상 주소 공간은 일반적으로 2GiB입니다. (실질적인 차이는 없습니다.어느64비트 시스템의 경우 다음 중 주소와 크기가 더 클 수 있다는 점을 제외하면 훨씬 더 커질 수 있습니다.)

이제 프로세스에서 실행되는 프로그램이 VirtualAlloc(Win32 API)을 사용하여 2MiB의 가상 메모리를 "커밋"한다고 가정합니다. 예상한 대로 이는 추가 2MiB의 커밋 요금으로 표시되며 향후 할당을 위해 프로세스에서 사용할 수 있는 가상 주소 공간이 2MiB 더 적습니다.

하지만 실제로는 아직 실제 메모리(RAM)를 사용하지 않습니다!

VirtualAlloc 호출은 할당된 영역의 시작 주소를 호출자에게 반환합니다. 영역은 0x10000에서 0x7FFFFFFF 사이, 즉 약 2GiB 범위에 있습니다. (각 프로세스의 vas의 첫 번째와 마지막 64KiB 또는 0x10000(16진수)은 할당되지 않습니다.)

하지만 다시 말하지만 2MiB의 실제 물리적 사용은 없습니다.저장아직! RAM에도 없고 페이지 파일에도 없습니다. (개인 커밋 영역의 시작 값과 길이를 설명하는 "가상 주소 설명자"라는 작은 구조가 있습니다.)

그래서 거기에 있습니다! 커밋 요금은 증가했지만 실제 메모리 사용량은 증가하지 않았습니다.

이는 sysinternals 도구를 사용하면 쉽게 확인할 수 있습니다 testlimit.

나중에 프로그램이 해당 영역(어디는 중요하지 않음)에 무언가(예: 메모리 쓰기 작업)를 저장한다고 가정해 보겠습니다. 해당 영역 아래에는 아직 실제 메모리가 없으므로 이러한 액세스에는페이지 오류. 이에 대한 응답으로 OS의 메모리 관리자, 특히 페이지 오류 처리기 루틴(줄여서 "페이저"... MmAccessFault라고 함)은 다음을 수행합니다.

이전에 "사용 가능한" 물리적 페이지를 할당합니다.
가상 페이지 번호를 새로 할당된 물리적 페이지 번호와 연결하기 위해 액세스된 가상 페이지에 대한 페이지 테이블 항목을 설정합니다.
프로세스 비공개에 실제 페이지를 추가합니다.작업 세트
그리고 페이지 오류를 무시하여 오류를 발생시킨 명령이 재시도되도록 합니다.

이제 프로세스에서 한 페이지(4KiB)가 "오류"되었습니다. 그리고 물리적 메모리 사용량은 그에 따라 증가하고 "사용 가능한" RAM은 감소합니다. 커밋 요금은 변경되지 않습니다.

나중에 해당 페이지가 한동안 참조되지 않았고 RAM에 대한 수요가 높으면 다음과 같은 일이 발생할 수 있습니다.

OS는 프로세스 작업 세트에서 페이지를 제거합니다.
작업 세트로 가져온 이후에 기록되었기 때문에 수정된 페이지 목록에 배치됩니다(그렇지 않으면 대기 페이지 목록에 위치하게 됩니다). 페이지 테이블 항목은 여전히 RAM 페이지의 물리적 페이지 번호를 반영하지만 이제 "유효한" 비트가 지워져 다음에 참조될 때 페이지 오류가 발생합니다.
수정된 페이지 목록이 작은 임계값에 도달하면수정된 페이지 작성자"시스템" 프로세스의 스레드가 깨어나서 수정된 페이지의 내용을 페이지 파일에 저장합니다(페이지 파일이 있다고 가정).
수정된 목록에서 해당 페이지를 제거하고 대기 목록에 넣습니다. 이제 "사용 가능한" RAM의 일부로 간주됩니다. 그러나 현재로서는 해당 프로세스의 원본 콘텐츠가 여전히 남아 있습니다. 다시 말하지만 커밋 요금은 변경되지 않지만 RAM 사용량과 프로세스 개인 작업 세트는 감소합니다.
이제 대기 목록에 있는 페이지를용도 변경즉, 시스템의 모든 프로세스에서 페이지 오류를 해결하거나 SuperFetch에서 사용하는 것과 같은 다른 용도로 사용됩니다. 하지만...
수정된 목록이나 대기 목록에서 페이지를 잃은 프로세스가 물리적 페이지의 용도가 변경되기 전에(즉, 원래 콘텐츠가 여전히 남아 있음) 해당 페이지에 다시 액세스하려고 시도하는 경우 디스크에서 읽지 않고도 페이지 오류가 해결됩니다. 페이지는 프로세스 작업 세트로 다시 돌아가고 페이지 테이블 항목은 "유효"해집니다. 이는 "소프트" 또는 "저렴한" 페이지 오류의 예입니다. 대기 목록과 수정 목록은 곧 다시 필요할 가능성이 있는 시스템 전체의 페이지 캐시를 형성한다고 말합니다.

페이지 파일이 없으면 3~5단계가 다음과 같이 변경됩니다.

내용을 쓸 곳이 없기 때문에 페이지는 수정된 목록에 있습니다.
내용을 쓸 곳이 없기 때문에 페이지는 수정된 목록에 있습니다.
내용을 쓸 곳이 없기 때문에 페이지는 수정된 목록에 있습니다.

수정된 목록의 페이지는 "소프트" 페이지 오류로 손실된 프로세스로 다시 오류가 발생할 수 있으므로 6단계는 동일하게 유지됩니다. 그러나 그런 일이 발생하지 않으면 프로세스가 해당 가상 메모리 할당을 취소할 때까지 페이지가 수정된 목록에 남아 있습니다(프로세스가 종료되기 때문일 수 있음).

개인용 커밋 메모리 외에 가상 주소 공간과 RAM의 다른 용도도 있습니다. 있다매핑된백업 저장소가 페이지 파일이 아닌 지정된 파일인 가상 주소 공간. 페이징된 매핑된 Vas의 페이지는 RAM 사용량에 반영되지만 매핑된 파일이 백업 저장소를 제공하기 때문에 매핑된 메모리는 커밋 요금에 기여하지 않습니다. RAM에 없는 매핑된 영역의 모든 부분은 단순히 매핑된 파일. 또 다른 차이점은 대부분의 파일 매핑이 프로세스 간에 공유될 수 있다는 것입니다. 한 프로세스의 메모리에 이미 있는 공유 페이지는 다시 디스크로 이동하지 않고도 다른 프로세스에 추가될 수 있습니다(또 다른 소프트 페이지 오류).

그리고 거기에페이징할 수 없는vas는 항상 RAM에 상주하기 때문에 백업 저장소가 없습니다. 이는 보고된 RAM 사용량과 "커밋 요금" 모두에 영향을 미칩니다.

이는 압축 때문인 것 같습니다. 질문은 다음과 같이 변환됩니다. 왜 제한을 커밋하지 않고 올라가나요? 즉, 메모리 사용에 도움이 되지 않는다면 압축의 요점은 무엇입니까?

아니요. 압축과는 아무 관련이 없습니다. Windows의 메모리 압축은 페이지 파일에 기록될 페이지에서 중간 단계로 수행됩니다. 실제로는 다음을 허용합니다.수정된 페이지 목록CPU 시간은 어느 정도 희생되지만 페이지 파일 I/O(SSD에서도)보다 훨씬 빠른 속도로 더 많은 내용을 포함하기 위해 더 적은 RAM을 사용합니다. 커밋 제한은 다음에서 계산되므로총RAM 사용량 + 페이지 파일 사용량이 아닌 RAM + 페이지 파일 크기는 커밋 제한에 영향을 미치지 않습니다. 커밋 제한은 사용 중인 RAM의 양이나 사용 용도에 따라 변경되지 않습니다.

커밋 요금이 가득 차고 창에서 작업을 닫으라는 메시지가 표시되기 시작하면 대부분의 경우 실제 메모리는 약 60%입니다. 이것은 끔찍하게 비효율적인 것 같습니다.

Windows가 비효율적이라는 것은 아닙니다. 실행중인 앱입니다. 그들은 실제로 사용하는 것보다 훨씬 더 많은 vas를 저지르고 있습니다.

전체 "요금 커밋" 및 "커밋 제한" 메커니즘의 이유는 다음과 같습니다. VirtualAlloc을 호출할 때 반환 값이 0이 아닌지 확인해야 합니다. 0이면 할당 시도가 실패했음을 의미합니다. 커밋 요금이 커밋 한도를 초과했기 때문일 수 있습니다. 커밋을 줄이거나 프로그램을 완전히 종료하는 등 합리적인 조치를 취해야 합니다.

VirtualAlloc이 0이 아닌 주소, 즉 주소를 반환한 경우 이는 시스템이 해당 주소에서 시작하여 내가 요청한 바이트 수에 관계없이 약속을 했다는 것을 의미합니다.될거야내가 액세스하기로 선택한 경우 사용할 수 있습니다. RAM이나 페이지 파일 등 모든 것을 넣을 수 있는 곳이 있다는 것입니다. 즉, 해당 지역 내의 모든 항목에 액세스하는 데 어떤 종류의 실패도 예상할 이유가 없습니다. 좋습니다. 왜냐하면 제가 "작동했습니까?"를 확인하기를 기대하는 것은 합리적이지 않기 때문입니다. 할당된 지역에 접근할 때마다

"현금 대출 은행" 비유

이는 신용을 제공하는 은행과 약간 비슷하지만 엄밀히 말하면 현금 기반입니다. (물론 실제 은행의 업무 방식은 그렇지 않습니다.)

은행이 백만 달러의 현금을 가지고 시작한다고 가정해 보겠습니다. 사람들은 은행에 가서 다양한 금액의 신용 한도를 요청합니다. 은행이 나에게 $100,000의 신용 한도를 승인했다고 가정해 보겠습니다. (개인 커밋 영역을 생성합니다.) 그렇다고 현금이 실제로 금고를 떠났다는 의미는 아닙니다. 나중에 실제로 20,000달러(나는 해당 지역의 일부에 액세스함)에 대한 대출을 받으면 은행에서 현금이 제거됩니다.

그러나 대출을 받든 안 받든, 내가 최대 $100,000까지 승인받았다는 사실은 은행이 이후에 모든 고객에 대해 총 $900,000 상당의 신용 한도를 추가로 승인할 수 있다는 것을 의미합니다. 은행은 현금 준비금을 초과하는 신용대출을 승인하지 않습니다.과도하게 커밋하다(그들), 이는 은행이 이전에 승인된 차용인이 나중에 대출을 받으려고 나타날 때 그를 돌려보내야 할 수도 있다는 것을 의미하기 때문입니다.그들의대출. 은행이 이미헌신적인이러한 대출을 허용하지 않으면 은행의 평판이 급락하게 됩니다.

예, 이는 은행이 해당 현금을 사용한다는 측면에서 "비효율적"입니다. 그리고 고객이 승인한 신용 한도와 실제 대출 금액 간의 차이가 클수록 효율성이 떨어집니다. 그러나 이러한 비효율성은 은행의 잘못이 아닙니다. 이렇게 높은 신용한도를 요구하면서도 소액대출만 받는 것은 고객의 '잘못'이다.

은행의 비즈니스 모델은 이전에 승인된 차용인이 대출을 받으러 나타날 때 단순히 거절할 수 없다는 것입니다. 그렇게 하면 고객에게 "치명적"이 될 것입니다. 그렇기 때문에 은행은 대출 자금 중 얼마나 많은 금액이 "확정"되었는지 주의 깊게 추적합니다.

페이지 파일을 확장하거나 다른 파일을 추가하는 것은 은행이 나가서 더 많은 현금을 확보하고 이를 대출 자금에 추가하는 것과 같을 것이라고 생각합니다.

이 비유에서 매핑된 메모리와 페이징 불가능한 메모리를 모델링하려면... 페이징 불가능한 메모리는 계좌를 개설할 때 인출하고 보관해야 하는 소액 대출과 같습니다. (각각의 새로운 프로세스를 정의하는 페이징 불가능한 구조입니다.) 매핑된 메모리는 자신의 현금(매핑되는 파일)을 가져와 은행에 예치한 다음 한 번에 그 일부만 꺼내는(페이징) 것과 같습니다. 한 번에 모두 페이지를 작성해 보는 것은 어떨까요? 어쩌면 지갑에 현금을 모두 담을 공간이 없을 수도 있습니다. :) 입금하신 현금은 일반대출자금이 아닌 본인계좌에 있기 때문에 타인의 대출에 영향을 미치지 않습니다. 이 비유는 특히 공유 메모리에 대해 생각하기 시작할 때부터 무너지기 시작하므로 너무 멀리 밀어붙이지 마십시오.

Windows OS로 돌아가서: "사용 가능한" RAM이 많다는 사실은 커밋 요금 및 커밋 제한과 아무 관련이 없습니다. 커밋 제한에 가까워지면 OS가 이미 커밋했음을 의미합니다. 즉 제공할 것을 약속함요청했을 때 - 그만큼의 저장 공간. 제한을 적용하기 위해 아직 모두 사용 중일 필요는 없습니다.

실제로 물리적 메모리를 효과적으로 활용할 수 있도록 공간이 부족한 SSD가 처리할 수 없는 수준까지 페이지 파일을 인위적으로 확장하지 않을 수 있습니까? (또는 꽉 차 있지 않더라도. 즉, "페이지 파일에 X/Y/Z를 수행하세요"와 같은 제안은 피하고 싶습니다.)

죄송합니다. 커밋 제한에 도달한 경우 수행할 수 있는 작업은 세 가지뿐입니다.

RAM을 늘리세요.
페이지 파일 크기를 늘리십시오.
한 번에 더 적은 작업을 실행하세요.

옵션 2: 하드 드라이브에 두 번째 페이지 파일을 넣을 수 있습니다. 앱이 실제로 커밋된 메모리를 모두 사용하지 않는 경우(사용 가능한 RAM이 너무 많기 때문에 분명히 그렇지는 않습니다) 실제로 해당 페이지 파일에 많이 액세스하지 않을 것이므로 하드 드라이브에 저장하면 성능 저하. 하드 드라이브의 느린 속도가 여전히 귀찮다면, 또 다른 옵션은 작고 저렴한 두 번째 SSD를 구입하여 두 번째 페이지 파일을 거기에 넣는 것입니다. 하나의 "쇼스토퍼"는 두 번째 "비분리형" 드라이브를 추가할 수 있는 방법이 없는 노트북입니다. (Windows에서는 USB로 연결된 드라이브와 같은 이동식 드라이브에 페이지 파일을 넣을 수 없습니다.)

여기는내가 쓴 또 다른 답변그것은 다른 방향에서 사물을 설명합니다.

ps: Windows 10에 대해 질문하셨는데, NT 제품군의 모든 버전, NT 3.1 및 시험판 버전에서도 동일한 방식으로 작동한다는 점을 말씀드리고 싶습니다. 변경된 점은 페이지 파일 크기에 대한 Windows의 기본 설정(1.5x 또는 1x RAM 크기에서 훨씬 작은 크기)입니다. 나는 이것이 실수였다고 믿는다.

Answer 1