RAM이 많은 경우 스왑 파일을 비활성화해야합니까, 아니면 가상 RAM 드라이브로 이동해야합니까?

많은 양의 RAM이 있다고 상상해보십시오. 64GB를 가정 해 봅시다. 그것은 심지어 게임용 PC에도 많은 영향을 미칩니다. 이제 Windows에서 페이지 파일의 기본 위치는 기본 OS 드라이브에 있습니다. HDD 또는 SSD는 일반적으로 빠르지 만 여전히 RAM만큼 빠르지 않습니다.

하드 드라이브에서 페이지 파일을 비활성화하거나 가상 RAM 드라이브를 만들고 페이지 파일을 그대로두면 Windows가 모든 가상 메모리를 RAM으로 옮길 수 있으므로 시스템 성능을 향상시킬 수는 있지만 지역이 아니므로 전혀 사실이 아닐 수도 있습니다.

나는 두 가지를 모두 시도했지만 기억에 관한 지식 수준으로 확실한 결론에 도달하기 위해 결과를 분석 할 수 없었습니다.

이게 효과가 있을까요? 그렇지 않다면 왜?

RAM 용량에 관계없이 시스템에서 효율적으로 사용할 수 있기를 원합니다. 페이징 파일이 없으면 운영 체제가 두 가지 이유로 RAM을 비효율적으로 사용하게됩니다. 첫째, 페이지에 오랫동안 액세스하거나 수정하지 않은 경우에도 페이지를 버릴 수 없어 디스크 캐시가 더 작아집니다. 둘째, 물리적 RAM을 예약 할 필요가 거의없는 할당을 백업해야합니다 (예 : 수정 가능한 개인 파일 매핑 등) 초과 커밋을 피하십시오.

예를 들어, 프로그램이 4GB 파일의 쓰기 가능한 개인 메모리 맵핑을 작성하는 경우를 고려하십시오. OS는이 매핑을 위해 4GB의 RAM을 예약해야합니다. 프로그램은 모든 바이트를 수정하는 것이 가능하고 RAM 외에는 저장할 공간이 없기 때문입니다. 따라서 즉시 4GB의 RAM이 낭비됩니다 (클린 디스크 페이지를 캐시하는 데 사용할 수 있지만 그 정도입니다).

사용하지 않더라도 RAM을 최대한 활용하려면 페이지 파일이 있어야합니다. 이 정책은 운영 체제가 RAM을 실제로 사용할 수 있도록 허용하는 보험 정책의 역할을하며, 가능성이 거의없는 가능성을 위해 예약하지 않아도됩니다.

운영 체제의 동작을 디자인 한 사람들은 바보가 아닙니다. 페이징 파일이 있으면 운영 체제에 더 많은 선택권이 부여되며 나쁜 선택은 아닙니다.

페이징 파일을 RAM에 넣는 것은 아무 의미가 없습니다. 그리고 RAM이 많은 경우 페이징 파일을 사용하지 않을 가능성이 높기 때문에 (그냥 있어야만 함) 장치의 속도가 중요하지는 않습니다.

당신은 전적으로 당신의 가정에 맞습니다.

메모리 관리 알고리즘은 매우 복잡하며 어떤 방법으로도 완벽하지 않습니다. 여분의 RAM이 충분한 경우에도 스와핑이 발생합니다. 와 같은 일부 시스템에서는 교환 불가능을 Linux제어 할 수 있고 다른 시스템에서는 교환 할 수 없습니다. 여전히 많은 양의 RAM이있을 때 데이터를 교체함으로써 시스템 자체의 방식으로 RAM이 부족한 상황에 대비합니다.

따라서 스와핑 기능을 비활성화하면 이미 말한 것보다 더 빠른 RAM 만 사용하므로 성능이 향상 될 수 있습니다.

고려해야 할 한 가지 (그리고 이미 언급했듯이)- 실행중인 모든 프로그램을 수용 하기에 충분한 RAM 이 있어야합니다 . 그렇지 않으면 메모리가 부족 할 위험이 있습니다 . 이 경우 성능이 저하되고 일부 프로세스가 OS에 의해 종료 될 수 있으며 시스템 충돌 / 동결이 발생할 수 있습니다. (자세한 내용은 여기를 참조 하십시오 )

일부 시스템, 특히 SSD가 아닌 HDD에 스왑 파일을 유지하는 시스템에서는 스와핑 비활성화로 인한 영향이 매우 두드러집니다. 다른 사람들에게는 그렇게 분명하지 않습니다. 그러나 눈에 띄게 개선되지 않더라도 다른 방법으로 생각하십시오. 스와핑을 비활성화하면 SSD의 디스크 공간이 절약됩니다.

스와핑을 비활성화하면 메모리 알고리즘이 불필요한 작업 (예 : RAM에서 스왑으로 또는 그 반대로 데이터 이동)을 수행하지 못하게되며 SSD의 경우 과도한 마모를 방지 할 수 있습니다. 어쨌든 불필요한 작업을 제거하여 성능을 향상시킵니다.

또한 다음을 읽으십시오.

• Windows 스왑 (페이지 파일) : 활성화 또는 비활성화?
• https://askubuntu.com/questions/157793/why-is-swap-being-used-even-though-i-have-plenty-of-free-ram

페이지 파일을 안전하게 비활성화 할 수 있습니까?

가상 메모리를 포함하여 사용 가능한 메모리가 부족하면 시스템은 결정적 실행을 계속 보장 할 수 없으며 자체 종료됩니다. 그 전에 운영 체제는 너무 많은 메모리를 사용하는 프로그램 종료와 같은 다양한 다른 작업을 수행합니다. 내가 말하고 싶은 것은 메모리가 항상 유한하며 모든 OS가 이것을 다룰 수 있다는 것입니다. 따라서 총 가용 메모리를 64GB로 제한해도 Windows에는 해가되지 않습니다. 많은 시스템은 페이지 파일이 있어도 8GB를 초과 할 수 없습니다. 1GB 또는 2GB RAM의 경우 페이지 파일은 대개 6GB 또는 7GB보다 훨씬 작기 때문입니다. 사용하지 않은 RAM이 너무 많으면 페이지 파일을 유지 관리하는 OS의 오버 헤드를 측정 할 수 없습니다.

페이지 파일을 램 디스크에 넣는 것이 합리적입니까?

사용 가능한 메모리를 늘리기 위해 대부분의 고급 운영 체제는 RAM에 있고 한동안 액세스하지 않은 메모리를 가져 와서 하드 디스크에 메모리를 쓰십시오 (swapfile aka pagefile ). 더 빠른 메모리를 사용할 수 있도록 RAM에서 메모리를 삭제하십시오. 스왑 파일은 사용 가능한 RAM 크기를 초과하여 메모리의 최대 크기를 확장하는 데 사용됩니다.

따라서 램 디스크 (램 디스크 크기로 사용 가능한 메모리를 줄임)를 사용하여 스왑 파일 (스왑 파일의 크기로 사용 가능한 메모리를 늘리는)을 호스트하면 효과가 있지만, 의미가 없습니다. 페이지 파일을 비활성화하는 것보다 더 많은 메모리를 제공하지는 않지만 시스템에서 페이징 알고리즘을 실행해야합니다.

다른 사람들이 말한 것을 반복하기 위해 스왑을 직선 RAM 디스크로 옮기는 것은 무의미합니다 (가장 일반적인 경우 아래 참조). 특정 시점에서 시스템에 사용 가능한 메모리가 부족하면 일부 데이터가 다소 비효율적 인 방식으로 RAM에서 RAM으로 이동됩니다.

HDD / SSD를 교체하면 OS에서 완전히 사용되지 않은 RAM 페이지를 지우고 파일 캐시 또는 기타 시스템 버퍼와 같이 사용 가능한 공간을 사용할 수 있습니다. 페이지 파일이없는 사용 가능한 가상 메모리가 없기 때문에 시스템이 이러한 RAM 버퍼를 적게 할당한다는 것을 인식하지 못할 수 있습니다. 실제로 스왑을 비활성화하여 성능을 저하시킬 수 있습니다.

그러나 스왑 드라이브 인 "ZSWAP"드라이브 인 압축 된 RAM 디스크는 RAM 세그먼트의 공간 효율성을 향상시켜 HDD로 스왑을 피하기 위해 몇 개의 추가 MB RAM이 필요할 수있는 엣지 케이스에서 유용 할 수 있습니다. 어느 정도.

페이지 파일이없는 경우 BSOD (충돌)의 경우 Windows에서 충돌 덤프 파일을 쓸 수 없습니다. 따라서 적절한 도구를 사용하여 문제를 분석 할 수 없습니다.

페이지 파일이 RAM에 있으면 충돌로 인해 손실 될 수 있으므로 쓸모가 없습니다.

자세한 내용은 Microsoft 문서 크래시 덤프 파일 이해를 참조하십시오 .

Windows의 경우 말 입에서 :

페이징 파일이 없으면 성능이 향상된다는 느낌이 들지만 일반적으로 페이징 파일이 있으면 Windows가 수정 된 목록에 페이지를 쓸 수 있음을 의미합니다 (이 페이지는 활발하게 액세스되지 않지만 디스크에 저장되지 않은 페이지를 나타냄). 파일을 페이징하여 메모리를보다 유용한 목적 (프로세스 또는 파일 캐시)으로 사용할 수있게합니다. 따라서 페이징 파일없이 더 나은 성능을 발휘하는 워크로드가있을 수 있지만 일반적으로 시스템에 더 많은 사용 가능한 메모리 *를 사용할 수 있음을 의미합니다 (Windows는 페이징 파일 크기가 없으면 커널 크래시 덤프를 작성할 수 없습니다 그들을 잡을만큼 충분히).

https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/

• 사용 가능한 메모리-가상 메모리를 권장하지만 페이지 파일 / 가상 메모리가없는 이점을 얻으려면 실제로 많은 양의 RAM이 필요하다는 것을 나타냅니다. 페이지 파일이없는 4GB RAM 128GB SSD가 있지만 웹 탐색 및 단어 문서 입력에 사용합니다.

스왑 파일을 비활성화하지 마십시오 . 메모리가 부족할 때만 사용할 수 없습니다. 전원을 끄면 직접적인 성능 향상이 없으며 , 필요할 때만 창을 읽으며 필요할 때마다 언제든지 쓸 수 있습니다.

압축 된 메모리 이미지를 저장하기 때문에 4GB 이상인 경우 메모리 크기의 약 2/3로 줄일 수 있습니다. SSD에 공간이 없으면 다른 하드 디스크 액세스로 액세스하지 않는 느린 하드 드라이브에 넣을 수 있습니다. 그러나 어딘가에있는 것이 좋습니다.

이유에 대한 자세한 내용은이 답변을 참조하십시오. https://superuser.com/a/286476/4236

이론적으로 페이지 파일을 RAM에 넣는 것은 전혀 의미가 없습니다. 왜냐하면 당신이 생각하는 것을 고갈시키고 Windows는 페이지 파일이 그러한 목적으로 사용되지 않는다는 가정에 기반을두고 있기 때문입니다.

그러나 실제로는 결함이있는 디자인과 철학으로 인해 Windows 커널까지 만들 수 있으며 Microsoft의 메모리 관리가 반드시 완벽하지는 않습니다. 많은 사람들이 페이지 파일을 램 디스크에 넣는 것이 적절한 양의 메모리를 가지고 있다면 실제로 성능이 향상 된다는 것을 알게되었습니다 .

많은 양의 RAM이 없어도 페이지 파일이 여전히 사용되고 있음을 발견 한 단일 포럼 스레드 에서 이러한 사용자 모음을 보여주는 게시물을 작성했습니다 .

http://www.overclock.net/t/1193401/why-it-is-bad-to-store-the-page-file-on-a-ram-disk/290#post_23508589

스왑을 사용하지 않도록 핵심으로 설계된 OS를 변환하는 것은 소리보다 훨씬 어렵습니다.

최신 Mac에는 기본 파티션을 복구하거나 복구 할 수있는 제거 된 OS가있는 기본 드라이브의 일부인 복구 파티션이 있습니다. DVD-installer 시절에 사용자 정의 프로세스를 실행하면 설치 프로그램이 사용 가능한 디스크 공간을 확보 할 수 없으므로 시스템은 스왑 파티션을위한 RAMdisk를 작성합니다. OS에는 포함 된 유지 관리 소프트웨어를 실행하는 데 필요한 프레임 워크가 포함되어 있으며 설치 후 사용 가능한 유틸리티와 동일합니다. 모두를위한 일이 훨씬 적습니다.

시스템을 한 번에 하나의 응용 프로그램으로 제한하면 기본적으로 램 디스크 스왑이 사용되지 않지만 OS는 해당 응용 프로그램이있을 것으로 예상합니다.

메모리가 충분하면 스왑을 해제 할 수 있습니다. 스왑은 RAM의 한계를 극복하고보다 효율적으로 사용하기 위해 만들어졌습니다.

문제는 이제 충분한 RAM이 얼마나 많은 RAM입니까? 이에 대한 보편적 인 대답은 없으며 본질적으로 시스템은 메모리에 굶주리고 있습니다. 따라서 매우 구체적이고 통제 된 환경에서 실행하지 않는 한 스왑을 해제하지 마십시오.

RAM에 스왑을 배치하는 것과 같은 다른 종류의 스턴트는 추가 복잡성을 생성하고 직접 사용할 수있는 메모리를 소비합니다.

내 시스템에는 24GB의 RAM이 있으므로 이런 이유로 페이지 파일을 비활성화하여 아무런 문제없이 SSD의 마모를 방지했습니다. 최근에 4GB의 메모리를 사용하여 Chrome 캐시 파일을 저장하는 RAM 디스크를 만들었습니다. 온라인 플래시 플레이어 게임 및 일반 웹 서핑의 성능이 향상되는지 확인하기 위해. 이 실험에서 성능이 크게 향상되었습니다. RAM 디스크에 사용 가능한 공간이 더 많으므로 페이지 파일을 활성화하고 최소 및 최대 크기를 1GB로 설정 한 다음 RAM 디스크로 옮겼습니다. 성능 향상이 있다고 말할 수는 없지만 시스템이 더 안정적으로 실행되는 것 같습니다.

페이지 파일을 RAM으로 옮기는 것은 우스운 개념입니다. 그냥 끄고 RAM을 늘리십시오. :)

No matter how much RAM you have, you want the system to be able to use it efficiently. Having no paging file at all forces the operating system to use RAM inefficiently for two reasons. First, it can't make pages discardable, even if they haven't been either accessed or modified in a very long time, which forces the disk cache to be smaller. Second, it has to reserve physical RAM to back allocations that are very unlikely to ever require it (for example, a private, modifiable file mapping), leading to a case where you can have plenty of free physical RAM and yet allocations are refused to avoid overcommitting.

Consider, for example, if a program makes a writable, private memory mapping of a 4GB file. The OS has to reserve 4GB of RAM for this mapping, because the program could conceivably modify every byte and there's no place but RAM to store it. So immediately, 4GB of RAM is basically wasted (it can be used to cache clean disk pages, but that's about it).

메모리 관리는 CPU에 의해 처리되며 페이지 파일의 설정 여부는 페이지 처리 방식에 차이가 없습니다. Windows에 투명합니다.

페이지 우선 순위는 변경되지 않으며 페이지는 동일하게 폐기됩니다. 페이지 파일은 CPU가 OS가 아닌 보조 저장소로 사용합니다. 레벨 1 (RAM)이 떨어지면 레벨 2 캐시에 지나지 않습니다.

빠르고 더러운 예 : 내 컴퓨터에는 16GB의 RAM이 있고 페이지 파일이 없습니다. 5 분 전 대기 시간이 13GB이고 여유 공간이 2GB 인 경우 폴 아웃 4를로드했습니다. 우선 순위가 낮은 페이지는 폴 아웃이로드 될 때 삭제되었습니다.

부수적으로, Windows 메모리 제한을 추진하는 2008 Technet 블로그는 매우 오해의 소지가 있습니다. https://i.stack.imgur.com/wXkmi.png Mark조차도 글을 썼는지 여부는 의심 스럽지만 그에 대한 내 관점을 바꿀 수 있기를 바랍니다 .....

Foww는 내가 블로그를 얼마나 자주 참조했는지를 고려하지 않은 사람 중 누구도 골치 아픈 기사에 허점을 가지고있다.

• 페이지 파일과 그 위치는 Windows에 의해 처리되며, 디스크로 페이지 아웃 된 위치에 대한 메모리 액세스 트 랩핑은 CPU에 의해 잡히지 만 운영 체제로 전달되어 디스크에서 페이지를 검색하여로드합니다.

어쨌든 여기에 모호한 설명이 없습니다.

Windows가 CPU보다 높은 주소에 도달 할 수 없습니다. 불가능합니다.

OS가 무엇을 할 수 있더라도 OS가 실행되는 하드웨어에 의해 여전히 제한됩니다. OS는 실제로 CPU 자체 (내부 레지스터)이기 때문입니다.

따라서 페이지 파일은 HDD에서 물리적 또는 구조적으로 더 많은 RAM을 사용할 수 없을 때 확장 된 물리적 주소 공간에 사용하는 HDD의 영역입니다.

예를 들어, 세그먼트 x86 32 비트 아키텍처에는 2GB의 2GB RAM이 있습니다.

하나는 커널에 할당됩니다. 다른 2GB는 사용자 모드입니다. CPU가 32 개의 DRAM 핀과 함께 사용할 수있는 모든 RAM 이지만 32 비트 프로세스에는 4GB의 사용 가능한 공간이 있습니다. 운 좋게도 CPU는 2GB의 추가 페이지를 저장하기 위해 보조 스토리지 AKA 하드 드라이브를 사용할 수 있습니다. 내부 레지스터가 있기 때문에
프로세스가 참조하는 가상 페이지를 RAM에 저장할 필요가없는 물리적 위치입니다. 그러나 CPU에 의해 어딘가에 저장되어 있습니다.

CPU는 앱에 4GB RAM을 모두 제공 할 수 는 없지만 HDD를 보조 캐시로 사용하여 4GB의 주소를 제공 할 수 있습니다 (모든 HDD가 실제로 있습니다)

내부 페이징 메커니즘을 통해 페이지가 RAM 안팎으로 이동하지만 페이지 파일과 동일하지 않습니다. 페이징은 항상 발생합니다 ....

결론은 실제로 그렇게 복잡하지 않습니다. 지난 15 년 동안 많은 최종 사용자에게 페이지 파일이 운영 체제의 일부인 인상을 받았습니다. 한번도 없었습니다. 이 오해는 부분적으로 인텔 및 Microsoft와 같은 회사에서 비롯됩니다.

RAM은 빠른 저장 장치이고 하드 드라이브는 느린 저장 장치이므로 기본적으로 RAM은 레벨 1 캐시이고 하드 드라이브는 레벨 2입니다 (이 비유의 CPU 캐시는 무시). 둘 다 CPU에 의해 액세스 될 수 있습니다.

CPU가 필요한 페이지를 저장하기에 충분한 RAM을 사용할 수없는 경우 HDD를 오버플로로 사용할 수 있습니다. RAM이 충분하면 PF가 중복됩니다.

코어 2까지 인텔 프로세서에는 32 핀 DRAM 버스가 있으며 32 개의 레지스터는 CPU가 4GB의 RAM과 4GB의 HDD 공간 (페이지 파일)에 액세스 할 수 있음을 의미합니다. 이것은 Windows 제한이 아닌 아키텍처 하드웨어 제한입니다.

페이지 테이블은 512MB를 차지하므로 프로세스에 사용 가능한 총 용량은 3.5GB입니다. 그렇기 때문에 Intel CPU가 설치된 Windows에서 3.5GB가 표시됩니다 (Core 2까지). GPU를 추가하면 더 적은 용량을 사용할 수 있습니다.

Xeon은 HDD가 포함 된 총 32GB RAM, 64GB의 물리적 공간에 액세스 할 수 있습니다 (페이지 파일 다시). ( 이 ^는 PAE를 다루며, 링크가 추가되어 제공됩니다 .)

http://www.windowsdevcenter.com/pub/a/windows/2004/04/27/pagefile.html

세 번째 스크린 샷 소스 : System V Application Binary Interface AMD64 아키텍처 프로세서 보완 초안 버전 0.99.7

이 답변을 계속 개선하고 소스 자료 및 관련 정보를 추가하려고합니다. 정보가 충분하지 않고 너무 많은 기술 정보가 균형을 이루고 싶습니다. 제안을 환영합니다. 잘 작성되지 않았기 때문에 공감하지 마십시오.