내 페이지 테이블이 왜 그렇게 많은 메모리를 차지합니까?

내 64 비트 Windows 7 PC는 매우 느립니다. 작업 관리자에서 내 메모리 사용량이 100 %에 가깝다는 것을 알았습니다. 그러나 각 프로세스에 대해보고 된 사용량은 총 6GB에 미치지 않습니다 (Firefox는 약 500MB, 나머지는 훨씬 적음). RAMMap을 다운로드 하여 Page Table 이 상당한 양의 메모리 (2.5GB)를 차지하고 있음 을 발견했습니다 .

나는 이것을 봤는데 아무데도 없었다-분명히 페이지 테이블이 조각화 될 수있다. 분명히 나는 ​​기계를 재부팅하고 그것이 도움이되는지 볼 것입니다. 그러나 그것을 고치는 더 좋은 방법이 있습니까?

편집 : 재부팅되었으며 페이지 테이블이 30MB로 줄었습니다.

편집 2 : 며칠간의 가동 시간 후에 페이지 테이블 사용이 다시 증가하고 있습니다. 이 답변 의 @ magicandre1981의 지침에 따라 페이지 테이블 사용법의 출처를 찾습니다. 불행히도 나는 공백을 그렸다-페이지 테이블은 "알 수 없음"에 의해 사용된다!

누구든지 밝은 아이디어가 있습니까?

질문에 대한 의견, 특히 "페이지 테이블"과 "페이지 파일"의 혼동에 대해 의견을 말해야합니다. 이것은 답변이 아니지만 주석이 허용되는 공간에 맞지 않습니다.

"페이지 테이블"은 실제로 페이지 파일과는 매우 다릅니다. 갖는 n 개의 페이지 테이블에 사용되는 RAM의 MB 것은 당신이 사용하는 것을 의미하지 않는다 N 페이지 파일 공간 메가바이트 그리고 일부 페이지 테이블 항목 (페이지 테이블이 구성되는 PTE)이 페이지 파일 내용을 참조하지만 모두는 아닙니다.

페이지 테이블을 수행하기 위해 CPU의 MMU에 의해 사용되는 메모리 구조입니다 주소 변환 가상 주소 공간과 도움 해결 페이지 결함을 추적하기 위해 물리적 주소로 가상 주소 (다시 아닌 페이지 파일)에서, 그리고 운영 체제에 의해. 페이지 테이블은 페이지 테이블 항목 (PTE)으로 구성됩니다. 각 PTE는 8 바이트를 차지하고 4K 바이트의 가상 주소 공간 (즉, 하나의 가상 페이지)을 정의합니다. 가상 주소 공간의 비어 있지 않은 각 페이지마다 대략 하나의 PTE가 있습니다.

그런데 페이지 파일은 외부 및 내부 조각화를 모두 경험할 수 있지만 (전자는 일반적으로 큰 문제가 아니며 후자는 필요에 따라 4 배 정도 크게 만들어서 개선 할 수 있지만) 페이지 테이블은 불가능합니다. 그것들은 항상 이미 조각난 것이므로 조금이라도 중요하지 않습니다.

각 PTE에는 "유효한"비트가 있습니다. "거주"(일명 "거주"페이지)의 경우, PTE는 PTE와 연관된 가상 페이지 번호에 해당하는 실제 페이지 번호를 포함합니다. MMU에서 직접 사용합니다.

"유효하지 않은"페이지의 경우 MMU에서 페이지 오류가 발생하고 PTE는 가능한 많은 형식과 해석을 갖습니다.

참고 : 위의 모든 내용은 x86 / x64에서 페이징을 활성화하는 모든 운영 체제에 적용됩니다. 다음은 주로 Windows에만 적용되지만 구현 개념에 차이가있는 많은 개념이 다른 OS에 적용됩니다.

페이지 캐시에있는 페이지의 경우 PTE는 여전히 실제 페이지 번호를 포함합니다. RAM에서 손실되어 페이지 파일에 기록 된 페이지의 경우 PTE에는 페이지 파일 번호 및 페이지 내용이 기록 된 페이지 파일 내의 오프셋이 포함됩니다. 다른 가능한 PTE 내용은 가상 주소 디스크립터 , "프로토 타입 PTE", 제로 페이지 를 요구하는 참조 등입니다. PTE 중 일부만 페이지 파일의 위치를 ​​참조한다고 말하면 충분합니다.

나는 페이지 파일과 페이지 테이블이 관련되어 있지만 분명히 같은 것은 아니라는 것을 보여주기 위해 대부분이 언급합니다.

페이지 테이블은 트리 구조로 구성됩니다. 각 프로세스마다 다른 트리 또는 페이지 테이블 모음이 있습니다. 이는 각 프로세스가 고유 한 가상 주소 공간 인스턴스를 정의 할 수있게하는 것입니다. 트리의 루트에있는 페이지 테이블은 항상 RAM에 있어야합니다. 나머지는 페이징 가능합니다. 이들은 정의되지 않은 또는 비어있는 가상 주소 공간의 넓은 (최소 2MB) 영역에 해당하는 경우에도 존재하지 않습니다.

트리의 "잎"에있는 테이블의 페이지 테이블 항목은 가상 주소 공간의 페이지에 해당합니다. 상위 테이블의 PTE (루트 (및 루트 자체)에 더 가까운 PTE)는 다음 하위 테이블이 어디에 있는지를 알려줍니다.

RAMmap으로 표시되는 숫자는 모든 프로세스와 OS를위한 모든 상주 (RAM 내) 페이지 테이블이 차지하는 실제 메모리 (RAM)입니다.

여기서 중요한 것은 OQ의 시스템에 페이지 테이블과 연결된 2.5GB의 RAM이 있다는 것입니다. 즉, 최소한 2.5GB의 페이지 테이블이 정의되어 있습니다. 페이지 테이블 자체는 페이징 가능하기 때문에 가상 크기는 실제 크기보다 훨씬 클 수 있으며, 이는 모든 RAMmap이 우리에게 보여줄 수 있습니다. 그러나 "2.5GB"만 가정합니다. PTE 당 8 바이트에서 약 3 억 3 천만 PTE입니다. 각 PTE는 가상 주소 공간의 한 페이지 (4K 바이트)를 정의하므로 1.2 테라 바이트 이상의 가상 주소 공간이 메모리 내 페이지 테이블에 의해 정의됩니다 .

그것은 불가능하지 않지만 오히려 많은 것입니다.

참고로 내 시스템 atm에는 페이지 테이블에 약 125MB의 RAM이 있습니다. 이것은 약 65GB의 가상 주소 공간만을 나타냅니다. 실제 가상 사용량은 프로세스의 경우 125TB로 훨씬 높지만 대부분의 페이지 테이블이 RAM에 없기 때문입니다. 여기서 다루지 말아야 할 또 다른 "큰 페이지"는 페이지 테이블 크기와 사용중인 가상 주소 공간 크기 간의 비율을 다르게 설명하는 데 도움이 될 수 있습니다.

따라서 범인을 찾기 위해 먼저 "가상 바이트"카운터 값이 높은 프로세스의 프로세스 범주에서 성능 모니터를 살펴 보겠습니다.

Lenovo "RapidBoot Shield" 는 저의 범인이었습니다.

재부팅하지 않고 일주일 후 내 "페이지 테이블"은 4GB 이상을 사용하고있었습니다. RamMap의 "Processes"탭에 표시된 것처럼 종료 된 모든 프로세스가 20K RAM (4K private, 16K Page Table)을 사용하여 멈췄으며 그 중 약 200,000 개가있었습니다!

다시 부팅하면 목록이 줄어들었지만 다시 커지기 시작했습니다. 메모장을 열고 죽이고 RamMap 프로세스 목록에 남아있는 것을 관찰하여 재현 할 수있었습니다.

이 테크넷 스레드 에 대한 제안을 바탕으로 "RapidBoot Sheild"를 제거하고 컴퓨터를 재부팅 한 다음 프로세스가 종료 될 때 더 이상 프로세스가 유지되지 않았습니다. 문제 해결됨!

제 경우에는 Aladdin Knowledge Systems Aladdin 드라이버의 Aksdf.sys 및 Hardlock.sys 필터 드라이버 입니다. RAMMap을 사용하여 그 대답을 찾았습니다. 종료 된 프로세스에서 소비 한 메모리를 표시했습니다. 프로세스는 Windows 프로세스 목록에서 제거되었지만 메모리 맵에는 계속 남아 있습니다. 드라이버는 프로세스가 완전히 종료되지 않는 것 같습니다.

나는 내 IT 부서에 이것에 대해 물었고, 그들은 대나무로 비슷했습니다. DriverEasy 를 사용하여 드라이버를 업데이트했습니다. 이상하게도 차이를 만들어 낸 것으로 보이는 것은 모니터 드라이버였습니다. 이전에는 표준 Windows "Generic PnP Monitor"드라이버가있었습니다. 그러나 그것들을 모니터의 올바른 제조사와 모델로 업데이트했을 때 문제가 사라지는 것처럼 보였습니다.

RamMap에서 "프로세스"탭을 열고 이름별로 정렬하십시오. 의심 할만한 많은 수의 동일한 프로세스를 찾으십시오. 내 컴퓨터에서 "SynTPEnh.exe"는 범인 (터치 패드 드라이버의 일부)이었습니다. 가동 시간이 일주일이 지난 후 페이지 테이블의 크기는 각각 32kb입니다.

내 페이지 테이블 크기는 1GB이고 재부팅 후 50MB입니다.