Windows가 최대 절전 모드 파일에서 전체 RAM을 어떻게 그렇게 빨리 덤프 할 수 있습니까?


65

Microsoft Windows의 최대 절전 모드 절차를 설명 하는 기사 를 살펴 보았습니다. 내가 얻는 주요 요점은

  1. Windows는 hiberfil.sys파일에 전체 RAM을 처리합니다 (처리 후) .
  2. 부팅하는 동안 최대 절전 모드 파일을 읽고 내용이 RAM에로드됩니다.

내 질문은 보통 1GB 크기의 파일을 복사 할 때 완료 하는 데 약 2 분이 걸립니다 .

그러나 Windows에서 최대 절전 모드 파일을 작성하는 경우 (최대 절전 모드 절차 중) 전체 프로세스에 10-15 초가 소요될 수 있습니다. 쓰기 속도가 왜 다른가요?

내 RAM 크기는 4GB입니다. (빠른 부팅 기술에 대해서는 이야기하지 않습니다.)

벤치 마크 :

  1. 디스크 1에서 디스크 2로 1GB 파일 복사 (외부) : 2.3 분.
  2. 시스템 최대 절전 모드 : 15 초

3
답을 모르겠지만 Windows Internals "제 13 장 : 시작 및 종료"책을 확인하면 (내가 책을 가지고 있다면 내가 확인하겠다) 책이 표시됩니다.
Scott Chamberlain

2
좋은 질문입니다. 1998 년에 최대 절전 모드가 처음 구현되었을 때 그리 빠르지는 않았습니다.
Gabe

22
@coder : NT 시스템은 hyberfil.sys에 전체 공간이 할당되어 있고 전체 파일이 조각화되지 않았는지 확인합니다. 이 상태에서는 작업 중에 하드 드라이브에서 헤드 점프가 발생하지 않습니다. 따라서 150Mo / s와 같은 효과적인 속도를 얻을 수 있습니다. 내가 말한 내용을 다시 확인할 수 있습니다 fsutil.
user2284570

3
외장 디스크도 일반적으로 내장 디스크보다 느립니다.
Harry Johnston

2
@EricLippert-RAM을 모두 저장하지는 않지만 여전히 설명하지는 않습니다. 정기적으로 저장해야 할 기가 바이트의 활성 RAM이 있습니다 (VS2013 또는 Eclipse + 더 많은 램이 필요합니다). 비 SSD의 이론적 쓰기 속도보다 더 큰 속도로 저장됩니다. 드라이브.
Davor

답변:


45

이것은 아마도 세 가지 답입니다.

여기서 할 수있는 한 가지는 응용 프로그램을 효과적으로 닫고 로그 오프 한 다음 운영 체제의 핵심을 최대 절전 모드로 전환하는 Windows의 새로운 하이브리드 종료입니다. 이 데이터를 이미 저장하면 잠재적으로 "재 동면"할 필요가 없습니다.

두 번째 것은 최대 절전 모드 중 하나를 스왑 파일에 페이징 또는 사용하지 않을되는 메모리 페이지를 저장할 필요가없는 것이 될 것이다 (이 적극적으로 스왑 파일을 채우기 위해 하나의 이유가 될 것입니다 뿐만 아니라 메모리에 데이터를 유지) .

세 번째는 최대 절전 모드 파일 데이터도 압축되는 것 입니다. 두 번째 포인트와 결합하면 압축률이 높은 데이터 (실행 파일이 일반적으로 잘 압축 됨)가 포함 된 내보낼 작은 데이터 세트 만 있으면 최대 절전 모드 파일로 보내는 데이터 양이 작업 세트보다 상당히 작을 수 있습니다 데이터 주석에서 언급 한 바와 같이, 파일 캐시 및 기타 불필요한 버퍼 데이터는 최대 절전 모드 파일에 덤프 될 데이터의 양을 줄이는 부작용없이 쉽게 폐기 될 수 있습니다.

또한 현재 하드 드라이브는 매우 빠릅니다. 100MB / s의 연속 쓰기가있는 디스크를 사용하면 1 분 안에 4GB의 RAM을 쓸 수 있습니다 (압축되지 않음). 최대 절전 모드는 모든 사용자 프로세스를 일시 중단 한 후와 CPU를 일시 중단하기 전에 마지막으로 수행 할 수 있으므로 일반적으로 OS는 디스크의 전체 쓰기 속도를 갖습니다. 이것은 간단한 벤치 마크에없는 한 가지 요소이며 디스크에서 디스크로 복사하는 것은 단순히 RAM을 디스크에 쓰는 것보다 속도가 느릴 수 있습니다.

이러한 것들을 결합하면 최대 절전 모드 파일에 기록 될 데이터의 양은 1GB 정도의 매우 작을 수 있으며 10 초 안에 하나의 큰 연속 블록에 기록 될 수 있습니다.


37
또는 더 명확하게하기 위해 : RAM이 가득 차 있지 않을 수 있습니다. 최대 절전 모드에서 버퍼가 플러시되고 캐시가 삭제됩니다. 실제로 응용 프로그램에서 사용중인 메모리 만 디스크에 기록해야합니다. 하이브리드 종료는 사용자를 로그 아웃하여 사용중인 메모리의 양을 줄입니다.
Daniel B

2
더럽지 않은 페이지는 "스왑 파일로 페이지 아웃 됨"에 대한보다 일반적인 설명이며 여기에는 실행 파일이 포함됩니다. (실행 파일이 디스크에서 다소 조각화되어 있기 때문에 깨우기가 느려질 수 있습니다.) 또한 클린 파일 버퍼는 메모리 매핑 파일의 일부가 아닌 경우에도 삭제 될 수 있습니다.
Paul A. Clayton

3
이 답변에 링크 된 문서의 @ user2284570 "Windows는 메모리의 내용을 디스크에 복사하여 최대 절전 모드를 지원합니다. 시스템은 메모리 내용을 디스크에 보존하기 전에 압축하여 필요한 디스크 공간을 총 실제 메모리보다 작게 줄입니다. "
Mokubai

4
@ user2284570 : 최악의 시나리오는 1 : 1 압축이기 때문입니다. Windows는 특정 최대 절전 모드에서 10 분의 1의 RAM 크기 만 필요한 경우에도 가능한 메모리 구성을 위해 hyberfil.sys에 충분한 (예약 된) 공간이 있는지 확인해야합니다. RAM 사용의 적절한 부분은 메모리에로드 된 파일 (실행 파일, 리소스 ...)이지만 여전히 HDD에서 매핑되므로 실제로 많은 글을 저장할 수 있습니다. 프로그램이 RAM에 4GiB의 암호화 랜덤 데이터를 생성하게하고 최대 절전 모드는 상당히 오래 걸리며 심지어 그 중 일부는 스왑 상태 일 수 있습니다.
Luaan

3
@ user2284570 : 파일이 너무 커서 디스크에 모든 메모리를 저장할 공간이 확보됩니다. 이 공간 전부가 실제로 최대 절전 모드에서 사용되는 것은 아닙니다. 때때로 파일은 7 % 압축 된 메모리 내용, 93 % 정크입니다.
psmears

31

첫째, 저장해야 할 RAM의 양이 놀라 울 정도로 적습니다. 실제로, 맵핑 된 더티 페이지 세트 ( "게으른 쓰기 저장") 만 플러시해야하며, 실행 가능 코드에 쓰여지고 재배치 된 모든 개인 페이지를 작성해야합니다.

  • 실행 파일의 .text 세그먼트는 항상 파일 매핑에 의해 지원됩니다. 그것은 적어도 일부 DLL에 대해서도 마찬가지입니다 (그러나 전부는 아니지만 재배치 해야하는지 여부에 달려 있습니다).
  • 유사 파일 매핑에 의해 백업 메모리가 폐기 될 수있다 (이 소 또는 RW 아니다 추정 하고 더러운).
  • 지연 쓰기 저장은 여전히 ​​발생해야하지만 그 이외의 캐시는 버릴 수 있습니다.
  • 할당되었지만 기록되지 않은 메모리 (일반적으로 응용 프로그램 데이터의 대부분)는 제로 페이지에 의해 백업되어 버릴 수 있습니다.
  • 에있는 메모리 페이지의 큰 부분은 "대기"상태 (실제 프로세스 당 주민이 Windows에서 작업 집합은 놀랍게도 어떤 점에서 백그라운드에서 페이지 파일에 복사 된 것이며, 폐기 될 수있다, 단순한 16메가바이트 작은) .
  • 그래픽 카드와 같은 특정 장치에서 매핑 한 메모리 영역을 저장하지 않아도 될 수 있습니다. 사용자는 때때로 8GiB 또는 16GiB를 컴퓨터에 연결한다는 사실에 놀랐으며 1GiB 또는 2GiB는 명백한 이유없이 "사라졌습니다". 주요 그래픽스 API를 사용하려면 버퍼 내용이 "일부 조건에서"유효하지 않게 될 수있는 응용 프로그램이 필요합니다 (이것이 의미하는 바를 정확히 밝히지 않음) 따라서 그래픽 드라이버에 의해 고정 된 메모리도 폐기 될 것으로 예상하는 것은 무리가 없습니다. 어쨌든 화면이 어두워 질 것입니다.

둘째, 파일을 복사하는 것과는 달리 디스크를 저장해야하는 RAM 페이지 세트를 덤프하는 것은 드라이브의 관점에서 연속 된 단일 쓰기입니다. Win32 API는 이러한 작업을 위해 사용자 수준 기능 도 제공 합니다. 쓰기는 하드웨어에서 직접 지원되며 디스크가 물리적으로 데이터를 수용 할 수있는 한 빨리 작동합니다 (컨트롤러는 DMA를 통해 데이터를 직접 가져옵니다).
이 작업을 수행하기위한 여러 가지 전제 조건 (예 : 정렬, 블록 크기, 고정)이 있으며 캐싱과 함께 잘 작동하지 않으며 "지연된 쓰기 저장"(정상적인 작업에서 매우 바람직한 최적화)과 같은 것은 없습니다. ).
그것이 모든 쓰기가 아닌 이유입니다항상 그렇게 작동합니다. 그러나 시스템이 최대 절전 모드 파일을 저장하는 경우 모든 전제 조건이 자동으로 충족되고 (모든 데이터가 페이지 정렬, 페이지 크기 및 고정됨) 컴퓨터가 잠시 꺼지기 때문에 캐싱이 부적절 해졌습니다.

셋째, 단일 연속 쓰기는 디스크 회전 및 솔리드 스테이트 디스크 모두에 매우 유리 합니다.

스왑 파일과 최대 절전 모드 파일은 일반적으로 디스크에서 만들어지고 예약 된 가장 빠른 파일 중 일부입니다. 그들은 보통 하나, 최대 두 개의 조각을 가지고 있습니다. 따라서 섹터가 손상되고 디스크가 물리 섹터를 재할 당하지 않는 한 논리 순차 쓰기 는 회전 디스크 의 물리 순차 쓰기로 변환됩니다 .

대량의 연속적이고 연속적인 데이터가 기록 될 때 디스크에서 읽기-수정-쓰기 작업이 필요하지 않습니다. 이 문제는 매우 작은 단일 섹터를 쓸 수있는 회전하는 하드 디스크에서 덜 두드러집니다 (캐시를 방지하는 단일 바이트를 쓰지 않으면 일반적으로 장치는 원래 내용을 가져 오지 않고 수정 된 버전을 다시 쓸 필요가 없습니다). .
그러나 이것은 모든 쓰기가 512kB 블록 (일반적인 숫자이지만 더 클 수 있음)을 컨트롤러가 읽고 수정하고 다른 것으로 다시 써야한다는 것을 의미하는 SSD에서 매우 눈띄는 것입니다. 블록. 원칙적으로 쓸 수는 있지만 덮어 쓸 수는 없습니다.) 플래시 디스크의 작은 단위는 큰 블록 만 지울 수 있으며 하드웨어가 작동하는 방식입니다. 이것이 대량 순차 쓰기에서 SSD가 훨씬 더 나은 이유입니다.


DLL을 재배치하더라도 재배치 된 주소 만 있으면됩니다. 재배치는 결정 론적 과정이며 반복 될 수 있습니다.
MSalters

"쓰기"? "대신 쓰기"를 의미합니까?
피터 Mortensen

3
@PeterMortensen : 아니, 난 정말 의미 수집 (읽기 흩어 반대) 쓰기. 이는 여러 위치에서 데이터 를 수집 하는 동안 단일 파일에 쓰는 것을 의미 합니다. 시작 주소와 길이가 포함 된 구조의 배열을 제공합니다 (엄격한 정렬 요구 사항 포함). 운영 체제는이를 컨트롤러로 전달하고 하드웨어는 나머지를 수행합니다.
Damon

1
@MSalters : 그러나 재배치하면 페이지의 개인 복사본이 만들어 지므로 개인 복사본에 대한 다른 수정 사항이 있는지 확인하는 것은 매우 어렵습니다. 수정이 필요하지 않은 맵핑과 대조하고 기록시 복사를 사용하십시오. 다른 수정이 이루어지면 개인 사본이 있습니다. 그렇지 않은 경우 페이지는 여전히 CoW로 구성됩니다.
Ben Voigt

1
@MSalters 결정 론적 프로세스 일 수도 있지만, 최대 절전 모드 코드가 링커와 동일한 소프트웨어 스택 계층에서 작동한다는 것을 의미하지는 않습니다. 최대 절전 모드가 커널 계층에 있고 연결이 사용자 계층 인 경우 최대 절전 모드는 링커의 기능에 대한 가정을 할 수 없습니다.
kasperd

10

최대 절전 모드에서 전체 RAM을 덤프하지 않습니다.

디스크에 이미 많은 양의 RAM이 이미 복제되어 있습니다. 이를 통해 최대 절전 모드를 빠르게 수행 할 수있을뿐만 아니라 새 프로그램에서 메모리를 빠르게 사용할 수 있으므로 빠르게 시작할 수 있습니다.

따라서 4GB의 작은 부분 만 작성하면되고 10-15 초 안에 수행 할 수 있습니다.

에서 마이크로 소프트 :

RAM이 부족한 경우 (예 : 커밋 된 바이트가 설치된 RAM보다 큼) 운영 체제는 사용되지 않는 가상 메모리 페이지를 페이지 파일에 복사하여 설치된 RAM의 일부를 즉시 사용할 수 있도록합니다. . 따라서이 카운터는 0에 도달하지 않으며 시스템의 RAM이 부족한지 여부를 나타내는 것이 아닙니다.


2

위의 모든 것 외에도 몇 가지 다른 요소가 있다고 생각합니다.

하나는 파일을 복사 할 때 파일을 읽고 써야한다는 것입니다. 최대 절전 모드에서는 파일 만 작성하면됩니다. 정의상 이미 메모리에 있습니다!

이와 관련하여 파일을 읽고 동시에 쓸 때 메모리를 절약하기 위해 프로세스는 다음과 같습니다. 청크 읽기, 청크 쓰기, 디렉토리 업데이트 (새 크기 표시); 청크를 읽고, 청크를 쓰고, 디렉토리를 업데이트하십시오.

디스크의 한 부분에서 다른 부분으로 이동할 때마다 (예를 들어, 파일 a를 읽고 파일 b를 쓰고, 파일 b를 작성하여 디렉토리를 쓰고, 다음 청크를 읽을 디렉토리를 쓰고) 디스크를 찾아야합니다. 헤드가 안정되도록하고 디스크의 오른쪽 부분이 올 때까지 기다리십시오. 이것은 솔리드 스테이트 디스크의 장점 중 하나입니다. 탐색에는 시간이 전혀 걸리지 않습니다. 최대 절전 모드에서는 데이터가 엔드 투 엔드로 작성됩니다. 최대 절전 모드 (스왑) 파일은 미리 할당되므로 디렉토리를 업데이트 할 필요가 없습니다 (최대 절전 모드 파일의 크기를 변경하지 않고 내용 만 변경).

그리고 마지막으로, 컴퓨터가 다른 모든 작업을 일시 중지했습니다.이 작업은 유일한 작업입니다. 메모리 관리 및 작업 전환과 같은 작업도 일시 중단됩니다.


차이 를 만들어 내야 합니다!
궤도에서 가벼운 경주

@LightnessRacesinOrbit : CPU 경합은 거의 차이가 없습니다. I / O 경합 부족은 큰 문제이지만이 답변은 이미 성능을 저하시키고 전체 대역폭이 부족하지 않은 탐색은 I / O 경합의 주요 문제라고 언급했습니다.
벤 Voigt

@ BenVoigt : 예, 동의합니다. 그리고 40 개의 프로세스가 모두 디스크에서 작업을 수행하려고하면 디스크 검색이 크게 증가합니다. (tl; dr 저는 CPU 경합에 대해 이야기하지 않았습니다)
Orbit in Lightbit Races

@LightnessRacesinOrbit : 정상적인 작동 중에도 (최대 절전 모드를 시작하고 나가는 것을 제외하고는) 비정상적 인 것 같습니다. 디스크를 때리는 백그라운드 작업을 잡으면 빨판을 제거하고 디스크를 무언가를 요청할 때만 디스크에 액세스하는 것으로 바꿉니다.
Ben Voigt

@ BenVoigt : 그럴 것 같지 않습니다. 데몬 로깅은 가장 명백한 반례이며, ntpd의 드리프트 파일 업데이트와 같은 것들입니다. 필자는 이러한 예제 중 하나가 여기에 큰 영향을 미쳤다고 주장하지는 않지만 백그라운드 작업이 디스크를 자율적으로 건드리지 않을 것으로 기대하는 것이 합리적이라고 생각하지 않습니다.
궤도

0

RAM이 하드 디스크보다 입출력 속도가 훨씬 빠르기 때문에 RAM이 하드 디스크를 읽을 수있는 속도만큼 RAM에있는 내용을 출력 할 수 있기 때문일 수 있습니다.

파일을 복사 할 때 디스크 속도, 동일한 디스크에서 읽고 디스크에 읽어야하는 경우 연결 속도 (외부 드라이브 인 경우)의 제한 속도, 검사 시간 등 여러 가지 요인에 의해 제한됩니다. 등을 덮어 쓰지 않습니다


9
하지만 여전히 OS는 I / O 병목 현상이 적용됩니다 디스크에 4GB의 RAM에 데이터를 기록 할 필요가
코더

또한 유리한 매개 변수를 가정하면 최대 절전 모드에서 디스크의 쓰기 속도가 40MB / s에서 ~ 260MB / s로 증가했음을 나타냅니다. 맞습니까?
코더

1
아마도-데이터를 쓰기 만하면되기 때문에 너무 많은 I / O 병목 현상이 없어야합니다. 디스크를 너무 많이 읽어야합니다). 내 (리눅스 듀얼 부팅) 랩톱에서 사용 dd if=/dev/zero of=/tmp/output.img bs=8k count=256k하고 얻을 수 1862606848 bytes (1.9 GB) copied, 1.81605 s, 1.0 GB/s있으므로 가능한 것 같습니다 (파일을 복사하는 Windows는 불필요하게 오래 걸리는 것 같습니다).
Wilf

로컬 인터넷을 통해 파일을 복사 할 때 훨씬 더 빨리 전송할 수도 있습니다. 또한 RAM에있는 모든 내용을 복사 할 필요는 없습니다. RAM에있는 일부 데이터는 캐시되어 최대 절전 모드에서 깨어날 때 시스템을 복원 할 필요가 없습니다.
Wilf

방금 시스템에서 dd 벤치 마크를 시도했습니다. 절대로 52MB / s를 넘지 않았습니다 : / (오래된 컴퓨터) 그러나 "어딘가에 무언가있을 것이므로 데이터를 덮어 쓰지 않고 디스크를 읽을 필요가 없도록 데이터를 어디에 두어야하는지 알고 있습니다." 너무 많이 " 빠른 속도의 열쇠입니다.
코더
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.