가상 메모리와 실제 메모리의 차이점은 무엇입니까?


102

나는 종종 운영 체제의 가상화 개념과 혼동됩니다. RAM을 물리적 메모리로 고려할 때 프로세스를 실행하기 위해 가상 메모리가 필요한 이유는 무엇입니까?

이 가상 메모리는 외부 하드 드라이브의 프로세스 (프로그램)가 실행을 위해 주 메모리 (물리적 메모리)로 가져올 때 어디에 있습니까?

누가 가상 메모리를 관리하며 가상 메모리의 크기는 얼마입니까?

RAM의 크기가 4GB (즉, 2 ^ 32-1 주소 공간) 인 경우 가상 메모리의 크기는 얼마입니까?


2
512MB가 있고 4GB를 처리해야하는 경우 어떻게합니까?
Oded

프로그램의 필요한 부분 만 메인 메모리에 저장됩니다. 틀 렸으면 수정 해주세요. 감사합니다 ..
starkk92

3
"가상 기억"은 코끼리를 살펴 보는 시각 장애인과 같습니다. 누구나 다른 인상을 갖게 될 것입니다.
Hot Licks 2014

2
심층적 인 답변을 원하시는 분들은 -this- 답변 을 확인하세요 .
RickyA 2018 년

답변:


85

가상 메모리는 무엇보다도 프로그래머에게 시스템에서 무한 메모리를 사용할 수 있다는 환상을주는 추상화입니다.

가상 메모리 매핑은 실제 물리적 주소와 일치하도록 만들어집니다. 운영 체제를 만들고 이러한 매핑과 거래 - 다른 데이터 구조 중 페이지 테이블을 이용하여이 매핑을 유지하기 위해. 가상 메모리 매핑은 항상 페이지 테이블이나 유사한 데이터 구조에서 발견됩니다 (다른 가상 메모리 구현의 경우 "페이지 테이블"이라고 부르지 말아야합니다). 페이지 테이블은 실제 메모리에도 있습니다. 종종 사용자 프로그램이 덮어 쓸 수없는 커널 예약 공간에 있습니다.

가상 메모리는 일반적으로 실제 메모리보다 큽니다. 가상 메모리와 실제 메모리의 크기가 같으면 가상 메모리 매핑에 대한 이유가 많지 않습니다.

프로그램의 필요한 부분 만 메모리에 상주합니다. 일반적으로 이것은 "페이징"이라는 주제입니다. 가상 메모리와 페이징은 밀접하게 관련되어 있지만 같은 주제는 아닙니다 . 세분화와 같은 다른 가상 메모리 구현이 있습니다.

나는 여기서 틀렸다고 생각할 수 있지만 머리를 감싸기 어려운 것은 가상 메모리의 특정 구현, 대부분 페이징과 관련이 있다고 확신합니다. 페이징을 수행하는 한 가지 방법 은 없습니다. 구현 이 많고 교과서에서 설명하는 것이 Linux / Windows와 같은 실제 OS에 나타나는 것과 같지 않을 가능성이 높습니다. 미묘한 차이가있을 수 있습니다.

나는 페이징에 대해 천 문단을 비난 할 수 있지만, 그 주제를 구체적으로 대상으로하는 다른 질문에 맡기는 것이 더 낫다고 생각합니다.


4
가상 메모리와 실제 메모리의 크기가 같은 이유가 있습니다. VM을 사용하면 여러 프로세스가 고유 한 주소 공간을 가질 수 있습니다. 이는 한 프로세스의 데이터가 다른 프로세스에 의해 덮어 쓰이지 않도록 보호합니다. 또한 다른 주소 공간에 다른 권한을 부여 할 수 있으므로 시스템의 일부 사용자는 다른 사용자보다 더 높은 읽기 / 쓰기 권한을 가질 수 있습니다. 그러나 동일한 양의 가상 메모리와 물리적 메모리를 사용하면 VM의 저장 이점이 제거됩니다.
almel

1
almel의 의견에 추가하려면 : 물리적 메모리보다 작거나 같은 크기의 가상 메모리가있는 경우에도 보안 및 안정성 이점 외에도 여러 32 비트 프로그램이 다른 방법으로는 불가능한 메모리에서 모두 실행할 수 있습니다 (예 : 64 비트 시스템), 조각화와 관련된 일부 문제를 방지하기 위해 물리적 메모리를 더 잘 관리 할 수 ​​있으며, 투명한 copy-on-write 메모리 기술에는 VM 등이 필요합니다.
Kaganar

2
가상 메모리는 결코 "무한한"것이 아니며 그러한 디자인이 그러한 환상을 불러 일으키려는 의도도 아닙니다. AMD64 아키텍처는 현재 가상 메모리의 48 비트 주소 지정을 허용합니다 ( AMD APM Vol 2. pg. 120 ) 사용 사례는 다양하지만 한 가지 주요 이점은 주소 공간의 연속 실행을 훨씬 더 크게 예약 할 수 있다는 것입니다. 일반적으로 물리적 공간에서 가능합니다. 그런 다음이 예약 된 범위는 요청시 커밋되므로 연결된 구조와 재 할당이 필요하지 않을 수 있습니다.
awdz9nld

이런 종류의 것들에 대해 읽을 수있는 책이 있습니까? 즉, 가상 메모리, 레이아웃, 정교한 세부 사항의 페이징 기술에 대한 책이 있습니까? 이 모든 것의 기본을 어디서 배울 수 있습니까?
Water Cooler v2

@ WaterCoolerv2 저는 Umakishore Ramachandran의 "컴퓨터 시스템 : 아키텍처 및 운영 체제에 대한 통합 접근 방식"의 일부입니다. 교과서이지만 운영 체제에 관한 다른 책들과 비교하여 다소 철저하고 설명이 잘되어 있다고 생각합니다. 하지만 실제로는, 운영 체제의 주제에 가장 어떤 책은 가능성 등 페이징, 가상 메모리, 이상 갈 것입니다
PinkElephantsOnParade

85

소프트웨어는 매우 단순한 전제에서 OS에서 실행되며 메모리가 필요합니다. 장치 OS는이를 RAM의 형태로 제공합니다. 필요한 메모리 양은 다양 할 수 있습니다. 일부 소프트웨어에는 대용량 메모리가 필요하고 일부는 약한 메모리가 필요합니다. 대부분의 (모두는 아니지만) 사용자는 OS에서 여러 응용 프로그램을 동시에 실행하며 메모리가 비싸고 장치 크기가 한정되어 있으므로 사용 가능한 메모리 양은 항상 제한됩니다. 따라서 모든 소프트웨어에 일정량의 RAM이 필요하고 모든 소프트웨어가 동시에 실행되도록 할 수 있다는 점을 감안할 때 OS는 다음 두 가지를 처리해야합니다.

  1. 소프트웨어 는 사용자가 중단 할 때까지 항상 실행됩니다. 즉, OS의 메모리가 부족하여 자동 중단되지 않아야합니다.
  2. 위의 활동은 실행중인 소프트웨어에 대해 상당한 성능을 유지합니다.

이제 주요 질문은 메모리가 어떻게 관리되고 있는지로 귀결됩니다. 주어진 소프트웨어에 속한 데이터가 메모리에서 어디에 상주 할 것인지 정확히 결정하는 것은 무엇입니까?

가능한 해결 방법 1 : 개별 소프트웨어가 장치에서 사용할 메모리 주소를 명시 적으로 지정하도록합니다. Photoshop 이 항상 0~ 까지 범위의 메모리 주소를 사용 한다고 선언 한다고 가정 합니다 1023(메모리를 선형 바이트 배열로 상상하면 첫 번째 바이트는 위치에 0있고 1024첫 번째 바이트는 위치에 있음 1023) 1 GB. 즉, 메모리를 차지 합니다. 마찬가지로 VLC 는 메모리 범위 12441876, 등 을 차지할 것이라고 선언합니다 .

장점 :

  1. 모든 애플리케이션에는 메모리 슬롯이 미리 ​​할당되어 있으므로 설치 및 실행시 데이터를 해당 메모리 영역에 저장하기 만하면 모든 것이 정상적으로 작동합니다.

단점 :

  1. 이것은 확장되지 않습니다. 이론적으로 앱은 정말 무거운 작업을 수행 할 때 엄청난 양의 메모리가 필요할 수 있습니다. 따라서 메모리가 부족하지 않도록하려면 할당 된 메모리 영역이 항상 해당 메모리 양보다 크거나 같아야합니다. 이론상 최대 메모리 사용량 2 GB(따라서 2 GBRAM에서 메모리 할당 이 필요함) 인 소프트웨어 가 메모리 만있는 시스템에 설치되면 1 GB어떻게됩니까? 소프트웨어는 시작시 사용 가능한 RAM이보다 작다고 말하면서 중단해야합니까 2 GB? 아니면 계속해야하고 필요한 메모리가를 초과하는 순간 2 GB중단하고 사용할 수있는 메모리가 충분하지 않다는 메시지와 함께 구제 조치를 취해야 합니까?

  2. 메모리 맹 글링을 방지 할 수 없습니다. 수백만 개의 소프트웨어가 있습니다. 각각에 1 kB메모리 만 할당되어 있더라도 필요한 총 메모리 16 GB는 대부분의 장치에서 제공하는 것보다 많은. 그렇다면 서로 다른 소프트웨어에 서로의 영역을 침범하지 않는 메모리 슬롯을 어떻게 할당 할 수 있습니까? 첫째, 새로운 소프트웨어가 출시 될 때이 아직 사용되지 않은 영역 에서 이만큼의 메모리를 할당해야한다고 규제 할 수있는 중앙 집중식 소프트웨어 시장이 없습니다., 그리고 둘째로, 있었다고하더라도 불가능하기 때문에 불가능합니다. 소프트웨어의 수는 사실상 무한하며 (따라서 모든 소프트웨어를 수용하기 위해 무한한 메모리가 필요함) 모든 장치에서 사용 가능한 총 RAM은 필요한 것의 일부도 수용하기에 충분하지 않으므로 한 소프트웨어의 메모리 경계를 잠식 할 수 없습니다. 다른 것에. 그래서 어떻게하면 어떻게 포토샵 메모리 위치를 할당 11023VLC가 할당 10001676? 어떤 경우 포토샵 저장 위치에있는 일부 데이터는 1008다음 VLC는 덮어 그 자신의 데이터, 나중에와 포토샵이전에 저장된 데이터와 동일한 데이터라고 생각하고 액세스합니까? 상상할 수 있듯이 나쁜 일이 일어날 것입니다.

보시다시피이 아이디어는 다소 순진합니다.

가능한 해결책 2 : OS가 대부분의 메모리 관리를 수행하는 다른 방식을 시도해 봅시다. 소프트웨어는 메모리가 필요할 때마다 OS를 요청하고 OS는 그에 따라 수용합니다. OS가 새로운 프로세스가 메모리를 요청할 때마다 가능한 가장 낮은 바이트 주소에서 메모리를 할당하도록 보장한다고 가정 해 보겠습니다 (앞서 언급했듯이 RAM은 바이트의 선형 배열로 상상할 수 있으므로 4 GBRAM의 경우 주소 범위는 0~ 까지 바이트2^32-1) 프로세스가 시작 중이면 메모리를 요청하는 실행중인 프로세스이면 해당 프로세스가 여전히 상주하는 마지막 메모리 위치에서 할당됩니다. 소프트웨어는 데이터가 저장되는 실제 메모리 주소가 무엇인지 고려하지 않고 주소를 방출하므로 OS는 소프트웨어에서 실제 물리적 주소로 방출 된 주소의 매핑을 소프트웨어별로 유지해야합니다 (참고 : 이것이 우리가이 개념이라고 부르는 두 가지 이유 중 하나입니다 Virtual Memory. 소프트웨어는 데이터가 저장되는 실제 메모리 주소를 신경 쓰지 않고 즉시 주소를 뱉어 내고 OS가 적합한 위치를 찾아서 찾습니다. 나중에 필요한 경우).

장치가 방금 켜졌 고 OS가 방금 시작되었으며 현재 실행중인 다른 프로세스가 없으며 (프로세스이기도 한 OS 무시!) VLC 를 시작하기로 결정했다고 가정 합니다. 따라서 VLC 는 가장 낮은 바이트 주소에서 RAM의 일부에 할당됩니다. 좋은. 이제 비디오가 실행되는 동안 일부 웹 페이지를 보려면 브라우저를 시작해야합니다. 그런 다음 메모장 을 실행 하여 텍스트 를 작성해야 합니다. 그리고 나서 이클립스 에서 코딩을합니다. 곧 여러분의 메모리 4 GB가 모두 소모되고 RAM은 다음과 같이 보입니다.

                                   여기에 이미지 설명 입력

문제 1 : 이제 모든 RAM이 사용되어 다른 프로세스를 시작할 수 없습니다. 따라서 사용 가능한 최대 메모리를 염두에두고 프로그램을 작성해야합니다 (다른 소프트웨어도 병렬로 실행되므로 실제로 사용할 수있는 메모리는 더 적습니다!). 즉, 쓰러진 1 GBPC 에서 메모리를 많이 사용하는 앱을 실행할 수 없습니다 .

좋습니다. 이제 EclipseChrome 을 더 이상 열어 둘 필요가 없다고 결정한 다음 닫아서 메모리를 확보합니다. 이러한 프로세스가 RAM에서 차지하는 공간은 OS에 의해 회수되며 이제 다음과 같습니다.

                                    여기에 이미지 설명 입력

이 두 개를 닫으면 700 MB공간 (( 400+ 300) MB)이 확보된다고 가정합니다 . 이제 공간 을 차지하는 Opera 를 실행해야 450 MB합니다. 글쎄, 당신은 450 MB총 사용 가능한 공간 보다 더 많은 것을 가지고 있지만 ... 연속적이지 않고 개별 청크로 나뉘며 어느 것도 맞을만큼 크지 않습니다 450 MB. 그래서 당신은 훌륭한 아이디어를 발견했습니다. 아래의 모든 프로세스를 가능한 한 위로 이동 700 MB시켜서 바닥에 한 덩어리에 빈 공간을 남깁니다 . 이것은 ... 불리운다compaction. 훌륭합니다. 단 ... 모든 프로세스가 실행 중입니다. 그것들을 옮기는 것은 모든 콘텐츠의 주소를 이동하는 것을 의미합니다 (OS는 소프트웨어에 의해 메모리 스 패트를 실제 메모리 주소로 매핑을 유지한다는 것을 기억하십시오. 소프트웨어가 45데이터와 함께 주소를 스 패트 123하고 OS 가이 를 위치에 저장 했다고 가정 해보십시오. 2012지도에 항목을 생성하여에 매핑 45합니다 2012. 소프트웨어가 이제 메모리에서 이동되면 이전에 있던 위치 2012는 더 이상에 있지 않고 2012새 위치에 있으며 OS는 그에 따라지도를 업데이트 45해야합니다. 소프트웨어가 123메모리 위치를 쿼리 할 때 예상 데이터 ( )를 얻을 수 있도록 새 주소 45. 소프트웨어에 관한 한 소프트웨어가 아는 것은 해당 주소뿐입니다.45데이터가 들어 있습니다 123!)! 지역 변수를 참조하는 프로세스를 상상해보십시오 i. 다시 액세스 할 때 주소가 변경되어 더 이상 찾을 수 없습니다. 모든 함수, 객체, 변수에 대해 동일하게 유지되며 기본적으로 모든 것이 주소를 가지며 프로세스를 이동하면 모든 주소가 변경됩니다. 이는 다음과 같은 결과로 이어집니다.

문제 2 : 프로세스를 이동할 수 없습니다. 해당 프로세스 내의 모든 변수, 함수 및 개체의 값은 컴파일 중에 컴파일러에 의해 튀어 나온 하드 코딩 된 값을 가지며, 프로세스는 수명 동안 동일한 위치에 있는지에 따라 달라지며 변경하는 데 비용이 많이 듭니다. 결과적으로 프로세스는 holes종료 될 때 큰 " "을 남깁니다 . 이것을라고 External Fragmentation합니다.

좋아. 어떻게 든 기적적인 방식으로 프로세스를 위로 이동시킬 수 있다고 가정하십시오. 이제 700 MB하단에 여유 공간이 있습니다.

                        여기에 이미지 설명 입력

Opera 는 바닥에 부드럽게 맞습니다. 이제 RAM은 다음과 같습니다.

                                    여기에 이미지 설명 입력

좋은. 모든 것이 잘 보입니다. 그러나 남은 공간이별로 없기 때문에 이제 기억력 이 부족한 것으로 알려진 Chrome을 다시 실행해야합니다 ! 시작하는 데 많은 메모리가 필요하며 거의 남은 것이 없습니다 ... 제외하고는 .. 처음에는 큰 공간을 차지하던 일부 프로세스가 이제 많은 공간을 필요로하지 않는다는 것을 알 수 있습니다. VLC 에서 비디오를 중지 했기 때문에 여전히 일부 공간을 차지하고 있지만 고해상도 비디오를 실행하는 동안 필요한 만큼은 아닙니다. 메모장사진도 마찬가지입니다 . 이제 RAM은 다음과 같습니다.

                                        여기에 이미지 설명 입력

Holes, 다시 한번! 원점으로 돌아가다! 이전에는 프로세스가 종료되어 구멍이 발생했지만 이제는 이전보다 적은 공간을 필요로하는 프로세스 때문입니다! 그리고 다시 같은 문제가 있습니다. holes결합하면 필요한 것보다 더 많은 공간이 생성되지만, 분리되어 많이 사용되지는 않습니다. 따라서 프로세스는 수명 동안 크기가 자주 줄어들 기 때문에 이러한 프로세스를 다시 이동해야하고 비용이 많이 드는 작업을 수행해야합니다.

문제 3 : 프로세스는 수명 동안 크기가 줄어들 수 있으며 사용하지 않는 공간이 남게되며, 필요한 경우 많은 프로세스를 이동하는 비용이 많이 드는 작업이 필요합니다. 이것을라고 Internal Fragmentation합니다.

좋아, 이제 OS가 필요한 작업을 수행하고 프로세스를 이동하고 Chrome을 시작하면 얼마 후 RAM이 다음과 같이 보입니다.

여기에 이미지 설명 입력

멋있는. 이제 다시 VLC 에서 아바타 시청을 재개한다고 가정합니다 . 메모리 요구 사항이 증가합니다! 하지만 ... 메모장 이 바닥에 붙어 있기 때문에 성장할 공간이 없습니다 . 다시 말하지만, 모든 프로세스는 VLC 가 충분한 공간을 찾을 때까지 아래로 이동해야합니다 !

문제 4 : 프로세스를 확장해야하는 경우 작업 비용이 매우 많이 듭니다.

좋아. 이제 가정 사진은 외장 하드 디스크에서 일부 사진을로드하는 데 사용하고있다. 하드 디스크에 액세스하면 캐시 및 RAM 영역에서 디스크 영역으로 이동하며, 이는 몇 배 더 느립니다. 고통스럽고, 돌이킬 수없이, 초월 적으로 느립니다. 이는 I / O 작업으로, CPU 바운드 (정확히 반대 임)가 아니므로 지금 RAM을 차지할 필요가 없음을 의미합니다. 그러나 여전히 RAM을 완고하게 차지합니다. 그동안 Firefox 를 시작 하려면 사용할 수없는 메모리가 많지 않은 반면, I / O 바운드 활동 기간 동안 사진 이 메모리에서 제거 되면 많은 메모리를 확보 했을 것입니다. (비싼) 압축이 뒤 따르고 파이어 폭스가 적합합니다.

문제 5 : I / O 바운드 작업이 RAM을 계속 차지하여 그 동안 CPU 바운드 작업에서 사용되었을 수있는 RAM 사용률이 낮습니다.

그래서 우리가 볼 수 있듯이 가상 메모리의 접근 방식에도 많은 문제가 있습니다.


이 이러한 문제를 해결하기위한 방법은 두 가지입니다 - pagingsegmentation. 토론합시다 paging. 이 접근 방식에서 프로세스의 가상 주소 공간은라는 청크 단위로 실제 메모리에 매핑됩니다 pages. 일반적인 page크기는 4 kB입니다. 매핑은 page table가상 주소가 주어지면 이라는 무언가에 의해 유지됩니다. 이제 우리가해야 할 일은 page주소가 속한 주소를 찾은 다음에서 실제 물리적 메모리 (라고 함 ) 에서 page table해당 위치를 찾는 것입니다. (가)에서 상기 가상 어드레스의 오프셋 대한 동일 는 AS뿐만 아니라 상기에 의해 리턴 어드레스에 오프셋을 추가하여 실제 주소를 알아 . 예를 들면 :pageframepagepageframepage table

여기에 이미지 설명 입력

왼쪽에는 프로세스의 가상 주소 공간이 있습니다. 가상 주소 공간에 40 단위의 메모리가 필요하다고 가정 해 보겠습니다. 물리적 주소 공간 (오른쪽)에도 40 단위의 메모리가 있었다면 모든 위치를 왼쪽에서 오른쪽 위치로 매핑 할 수 있었을 것입니다. 우리는 정말 행복했을 것입니다. 그러나 운이 좋지 않으면 물리적 메모리에 사용할 수있는 메모리 유닛 (여기서는 24 개)이 적을뿐만 아니라 여러 프로세스간에 공유해야합니다! 좋아, 우리가 그것을 어떻게 만드는지 보자.

프로세스가 시작되면 위치 35에 대한 메모리 액세스 요청이 있다고 가정합니다 . 여기에서 페이지 크기는 다음과 같습니다 8(각각 page에는 8위치 가 포함 되며 위치의 전체 가상 주소 공간 40에는 5페이지 가 포함됩니다 ). 따라서이 위치는 페이지 번호에 속합니다. 4( 35/8). 이 내에서이 page위치의 오프셋은 3( 35%8)입니다. 따라서이 위치는 tuple (pageIndex, offset)= 로 지정할 수 있습니다 (4,3). 이것은 시작일 뿐이므로 프로세스의 일부는 아직 실제 물리적 메모리에 저장되지 않습니다. 따라서 page table왼쪽에있는 페이지와 오른쪽에있는 실제 페이지의 매핑을 유지하는.frames)은 현재 비어 있습니다. 따라서 OS는 CPU를 포기하고 장치 드라이버가 디스크에 액세스하고 페이지 번호를 가져올 수 있도록합니다. 4이 프로세스를 위해 (기본적으로 주소 범위가에서 32까지 인 디스크의 프로그램에서 메모리 청크 39). 도착하면 OS는 첫 번째 프레임과 같이 RAM의 어딘가에 페이지를 할당 page table하고이 프로세스의 경우 페이지 가 RAM의 4프레임 0에 매핑 된다는 점에 유의합니다 . 이제 데이터는 마침내 물리적 메모리에 있습니다. OS는 다시 페이지 테이블에 튜플을 쿼리하고 (4,3)이번에는 페이지 테이블이 페이지 4가 이미 0RAM의 프레임 에 매핑 되었다고 말합니다 . 따라서 OS 0는 RAM 의 첫 번째 프레임으로 이동하여 해당 프레임의 오프셋 3에서 데이터에 액세스합니다 (잠시 시간을내어 이해하십시오.page디스크에서 가져온은 (는)로 이동되었습니다 frame. 따라서 페이지에서 개별 메모리 위치의 오프셋이 무엇이든 프레임에서도 동일 할 것입니다. page/ 내 frame에서 메모리 유닛은 여전히 ​​상대적으로 동일한 위치에 있기 때문에 데이터를 반환합니다! 데이터가 첫 번째 쿼리 자체에서 메모리에서 발견되지 않고 오히려 메모리로로드되기 위해 디스크에서 가져와야했기 때문에 누락이 발생 합니다.

좋아. 이제 위치에 대한 메모리 액세스 28가 이루어 졌다고 가정 합니다. 그것은 (3,4). Page table지금은 페이지 4를 프레임으로 매핑하는 항목이 하나뿐입니다 0. 따라서 이것은 다시 미스 이며, 프로세스는 CPU를 포기하고, 장치 드라이버는 디스크에서 페이지를 가져오고, 프로세스는 CPU의 제어권을 다시 얻고, page table업데이트됩니다. 이제 페이지 31RAM의 프레임 에 매핑 되었다고 가정 해 보겠습니다. 따라서 (3,4)(1,4)되고 RAM의 해당 위치에있는 데이터가 반환됩니다. 좋은. 이런 식으로 다음 메모리 액세스가로 8변환되는 location 에 대한 것이라고 가정합니다 (1,0). 페이지 1가 아직 메모리에 없으며 동일한 절차가 반복 page되고 프레임에 할당됩니다.2RAM에서. 이제 RAM 프로세스 매핑은 위의 그림과 같습니다. 이 시점에서 사용 가능한 메모리가 24 개 밖에 없었던 RAM이 가득 차게됩니다. 이 프로세스에 대한 다음 메모리 액세스 요청이 주소에서 왔다고 가정합니다 30. 그것은에 매핑 (3,6)하고, page table해당 페이지는 말한다 3RAM에 있으며 프레임에 매핑 1. 예이! 따라서 데이터는 RAM 위치에서 가져 와서 (1,6)반환됩니다. 이것은 구성 타격을 필요한 데이터 따라서 매우 빠른 것으로, RAM에서 직접 얻을 수. 유사하게, 다음 몇 개의 액세스 요청 (예 : 위치 11에 대한 ,, 32) 2627모두 적중입니다 . 즉, 프로세스에서 요청한 데이터는 다른 곳을 볼 필요없이 RAM에서 직접 찾을 수 있습니다.

이제 위치에 대한 메모리 액세스 요청이 있다고 가정합니다 3. 그것은로 변환 (0,3)하고, page table현재 페이지 3 개 항목을 가지고이 과정을 위해 1, 3그리고 4이 페이지가 메모리에없는 것을 말한다. 이전 사례와 마찬가지로 디스크에서 가져 오지만 이전 사례와 달리 RAM이 가득 찼습니다! 이제 어떻게해야합니까? 여기에 가상 메모리의 아름다움이 있습니다. RAM에서 프레임이 제거됩니다! (다양한 요소가 제거 될 프레임을 결정합니다. LRU프로세스에 대해 가장 최근에 액세스 first-come-first-evicted한 프레임이 제거되는 위치를 기반으로 할 수 있습니다. 가장 오래 전에 할당 된 프레임이 제거되는 기반 등 이 될 수 있습니다. .) 따라서 일부 프레임이 제거됩니다. 프레임 1을 말하십시오 (무작위로 선택). 그러나 그것은 frame일부page! (현재 페이지 테이블에 의해 3하나의 프로세스 의 페이지로 매핑됩니다 .) 그래서 그 과정은이 비극적 인 소식 frame을 전해야합니다. 불행하게도 여러분에게 속한 하나 는 다른 사람을위한 공간을 만들기 위해 RAM에서 제거된다는 것 pages입니다. 프로세스는 page table이 정보로 업데이트되도록해야합니다 . 즉, 해당 페이지 프레임 듀오에 대한 항목을 제거하여 다음에 해당 요청을 할 pagepage더 이상 메모리에 없음을 프로세스에 알립니다. , 디스크에서 가져와야합니다. 좋은. 따라서 프레임 1이 제거되고 페이지 0가 가져 와서 RAM에 배치되고 페이지 항목 3이 제거 0되고 동일한 프레임에 대한 페이지 매핑으로 대체됩니다.1. 이제 매핑은 다음과 같습니다 ( frame오른쪽 두 번째 색상 변경에 유의하십시오 ).

여기에 이미지 설명 입력

방금 무슨 일이 일어 났는지 봤어? 프로세스를 확장해야했고 사용 가능한 RAM보다 더 많은 공간이 필요했지만 RAM의 모든 프로세스가 증가하는 프로세스를 수용하기 위해 이동해야하는 이전 시나리오와 달리 여기서는 단 한 번의 page교체 만으로 발생했습니다 ! 이것은 프로세스의 메모리가 더 이상 연속적 일 필요가없고 청크의 다른 위치에 상주 할 수 있고 OS가 해당 위치에 대한 정보를 유지하며 필요할 때 적절하게 쿼리된다는 사실에 의해 가능해졌습니다. 참고 : 대부분의 경우 miss이고 데이터가 디스크에서 메모리로 지속적으로로드되어야한다면 어떨까요? 예, 이론적으로는 가능하지만 대부분의 컴파일러는 다음과 같은 방식으로 설계되었습니다.locality of reference일부 메모리 위치에서 데이터가 사용되는 경우, 즉, 필요한 다음 데이터는 아마도 같은에서 매우 가까운 곳에 위치 할 page, page단지 메모리에로드 된. 결과적으로 다음 누락은 꽤 오랜 시간 후에 발생하며, 다가오는 메모리 요구 사항의 대부분은 방금 가져온 페이지 또는 최근에 사용 된 메모리에 이미있는 페이지에 의해 충족됩니다. 똑같은 원리는 우리가 page한동안 사용되지 않은 것은 한동안 사용되지 않을 것이라는 논리로 가장 최근에 사용 된 것도 제거 할 수있게 합니다. 그러나 항상 그런 것은 아니며 예외적 인 경우에는 성능이 저하 될 수 있습니다. 나중에 더 자세히 알아보세요.

문제 4에 대한 솔루션 : 이제 프로세스가 쉽게 확장 될 수 있습니다. 공간 문제가 발생 page하면 다른 프로세스를 이동하지 않고 간단한 교체 만 수행하면 됩니다.


문제 1 : 프로세스가 무제한 메모리에 액세스 할 수 있습니다. 사용 가능한 것보다 많은 메모리가 필요한 경우 디스크를 백업으로 사용하고 필요한 새 데이터를 디스크에서 메모리로로드하고 가장 최근에 사용 된 데이터 frame(또는 page)를 디스크로 이동합니다. 이것은 무한히 계속 될 수 있으며 디스크 공간이 저렴하고 사실상 무제한이므로 무제한 메모리의 환상을 제공합니다. 이름에 대한 또 다른 이유 Virtual Memory는 실제로 사용할 수없는 기억의 환상을 제공합니다!

멋있는. 이전에는 프로세스의 크기가 줄어들더라도 빈 공간을 다른 프로세스에서 회수하기 어려운 문제에 직면했습니다 (비용이 많이 드는 압축이 필요하기 때문). 이제 프로세스의 크기가 작아지면 많은 프로세스가 더 pages이상 사용되지 않으므로 다른 프로세스에 더 많은 메모리가 필요할 때 간단한 LRU기반 제거가 자동으로 pagesRAM에서 덜 사용되는 항목을 제거하고 새 페이지로 대체합니다. 다른 프로세스 (물론 page tables모든 프로세스와 이제 더 적은 공간을 필요로하는 원래 프로세스의 업데이트 ),이 모든 것은 비용이 많이 드는 압축 작업없이!

문제 3 해결 방법 : 프로세스의 크기가 감소 할 때마다이 그 frames간단한 있도록에서의 RAM이 덜 사용됩니다 LRU기반 퇴거 밖으로 해당 페이지를 축출하고 그들을 대체 할 수있는 pages, 따라서 피, 새로운 프로세스에 의해 요구 Internal Fragmentation에 대한 필요없이 compaction.

문제 2의 경우 잠시 시간을내어 이해하면 시나리오 자체가 완전히 제거됩니다! 새로운 프로세스를 수용하기 위해 프로세스를 이동할 필요가 없습니다. 이제 전체 프로세스를 한 번에 맞출 필요가 없으며 framesRAM에서 제거 하여 발생하는 특정 페이지 만 임시에 맞출 필요가 있기 때문 입니다. 모든 것이 단위로 발생 pages하므로 hole지금의 개념이 없으므로 움직이는 것은 의심 할 여지가 없습니다 ! pages이 새로운 요구 사항으로 인해 10 개가 옮겨 져야했으며 수천 pages개가 그대로 남아 있습니다. 반면, 이전에는 모든 프로세스 (모든 프로세스)를 이동해야했습니다!

문제 2에 대한 솔루션 : 새로운 프로세스를 수용하려면 다른 프로세스에서 덜 최근에 사용 된 부분의 데이터 만 필요에 따라 제거해야하며 이는라는 고정 크기 단위로 발생합니다 pages. 따라서의 가능성이없는 hole또는 External Fragmentation이 시스템은.

이제 프로세스가 I / O 작업을 수행해야 할 때 CPU를 쉽게 양도 할 수 있습니다! OS는 단순히 pagesRAM에서 모든 것을 제거하고 (아마도 일부 캐시에 저장) 새로운 프로세스가 그 동안 RAM을 차지합니다. I / O 작업이 완료되면 OS는 단순히 pagesRAM으로 복원 합니다 (물론 pages다른 프로세스에서 대체하여 원래 프로세스를 대체 한 프로세스에서 가져 오거나 I / O를 수행해야하는 일부에서 가져올 수 있음). 오, 이제 기억을 포기할 수 있습니다!)

문제 5에 대한 해결 방법 : 프로세스가 I / O 작업을 수행 할 때 다른 프로세스에서 사용할 수있는 RAM 사용을 쉽게 포기할 수 있습니다. 이것은 RAM의 적절한 활용으로 이어집니다.

물론 이제 어떤 프로세스도 RAM에 직접 액세스하지 않습니다. 각 프로세스는 물리적 RAM 주소에 매핑되고 page-table해당 프로세스 에서 유지 관리하는 가상 메모리 위치에 액세스합니다 . 매핑은 OS 기반이며, OS는 프로세스에 대한 새 페이지를 거기에 맞출 수 있도록 비어있는 프레임을 프로세스에 알려줍니다. 이 메모리 할당은 OS 자체에 의해 감독되기 때문에 RAM에서 빈 프레임 만 할당하거나 RAM의 다른 프로세스 내용을 잠식 할 때 프로세스가 다른 프로세스의 내용을 침해하지 않도록 쉽게 보장 할 수 있습니다. 그것을 업데이트합니다 page-table.

원래 문제에 대한 해결책 : 전체 할당이 OS 자체에서 관리되고 모든 프로세스가 자체 샌드 박스 가상 주소 공간에서 실행되기 때문에 프로세스가 다른 프로세스의 내용에 액세스 할 가능성이 없습니다.

따라서 paging(다른 기술 중에서) 가상 메모리와 함께 OS-es에서 실행되는 오늘날의 소프트웨어에 힘을 실어줍니다! 이를 통해 소프트웨어 개발자는 사용자 장치에서 사용할 수있는 메모리 양, 데이터를 저장할 위치, 다른 프로세스가 소프트웨어 데이터를 손상시키는 것을 방지하는 방법 등에 대해 걱정할 필요가 없습니다. 그러나 물론 완전한 증거는 아닙니다. 결함이 있습니다.

  1. Paging궁극적으로 디스크를 2 차 백업으로 사용하여 사용자에게 무한 메모리의 환상을 제공합니다. 메모리에 맞추기 위해 보조 저장소에서 데이터를 page swap검색하는 page fault것은 IO 작업이므로 비용이 많이 듭니다 ( 라고하며 RAM에서 원하는 페이지를 찾지 못하는 이벤트를라고 함 ). 이것은 프로세스를 느리게합니다. 이러한 여러 페이지 스왑이 연속적으로 발생하고 프로세스가 고통스럽게 느려집니다. 소프트웨어가 훌륭하고 멋지게 실행되는 것을 본 적이 있는데 갑자기 속도가 너무 느려져 거의 중단되거나 다시 시작할 옵션이없는 경우가 있습니까? 너무 많은 페이지 스왑이 발생하여 속도가 느려질 수 있습니다 (라고 함 thrashing).

그래서 OP로 돌아와

프로세스를 실행하기 위해 가상 메모리가 필요한 이유는 무엇입니까? -대답이 길게 설명 하듯이, 소프트웨어에 무한 메모리를 가진 장치 / OS의 환상을주기 위해 메모리 할당에 대해 걱정하지 않고 크고 작은 모든 소프트웨어를 실행할 수 있습니다. 병렬로 실행됩니다. 이는 다양한 기술을 통해 실제로 구현 된 개념이며, 여기에 설명 된대로 페이징 중 하나입니다 . 또한 Segmentation 일 수 있습니다 .

실행을 위해 외부 하드 드라이브의 프로세스 (프로그램)를 주 메모리 (물리적 메모리)로 가져올 때이 가상 메모리는 어디에 있습니까? -가상 메모리는 그 자체로 어디에도 서 있지 않고 추상화이며 항상 존재하며 소프트웨어 / 프로세스 / 프로그램이 부팅 될 때 새 페이지 테이블이 생성되고 그에 의해 스 패팅 된 주소의 매핑이 포함됩니다. RAM의 실제 물리적 주소로 처리합니다. 프로세스에서 뱉어 낸 주소는 실제 주소가 아니기 때문에 어떤 의미에서 실제로 말할 수있는 것 the virtual memory입니다.

누가 가상 메모리를 관리하며 가상 메모리의 크기는 얼마입니까? -OS와 소프트웨어가 함께 처리합니다. 로컬 변수를 포함하는 코드의 함수 (결국 프로세스를 생성 한 실행 파일로 컴파일되고 생성됨)를 상상해보십시오 int i. 코드가 실행 i되면 함수 스택 내에서 메모리 주소를 가져옵니다. 이 함수는 그 자체가 다른 곳에 객체로 저장됩니다. 이러한 주소는 컴파일러가 생성합니다 (코드를 실행 파일로 컴파일 한 컴파일러)-가상 주소. 실행될 때 i적어도 해당 함수의 기간 동안 실제 물리적 주소의 어딘가에 있어야합니다 (정적 변수가 아닌 경우!). 따라서 OS는 컴파일러에서 생성 한 가상 주소를 매핑합니다.i따라서 해당 함수 내에서 일부 코드에 값이 필요할 때마다 i해당 프로세스는 OS에서 해당 가상 주소를 쿼리 할 수 ​​있으며 OS는 저장된 값에 대한 물리적 주소를 쿼리하고 반환 할 수 있습니다.

RAM의 크기가 4GB (즉, 2 ^ 32-1 주소 공간) 인 경우 가상 메모리의 크기는 얼마입니까? -RAM의 크기는 가상 메모리의 크기와 관련이 없으며 OS에 따라 다릅니다. 예를 들어 32 비트 Windows에서는 16 TB이고 64 비트 Windows에서는 256 TB. 물론 메모리가 백업되는 디스크 크기에 의해서도 제한됩니다.


2
이것은 VM / 페이징에 대한 훌륭하고 심도있는 설명입니다 (어딘가에 블로그 게시물이어야 함). 나를 혼란스럽게하는 VM 매핑 / 페이징의 한 부분은 모든 페이지 오류 또는 스왑에 대해 많은 디스크 액세스가 여전히 필요하다는 것입니다. 각 페이지 스왑 (VM에서 디스크로 또는 그 반대로)이 디스크에 대한 읽기 / 쓰기를 호출합니까? 그것은 나에게 엄청난 오버 헤드 인 것 같습니다.
Aroic

@TMartin 예, 페이지는 pagefile.sys에 기록되며 페이지 파일에 하나, 페이지 파일 내부의 배열에 저장되는 PFN에 대해 하나씩 2 개의 쓰기가 있다고 생각합니다. LRU 알고리즘은 각 프로세스 작업 세트 (가장 오래된 연령)에서 가장 적게 액세스 된 PTE의 페이지가 대부분 대기 목록으로 전송되고 결국 페이지 아웃되도록하여 페이지가 디스크에 기록 된 지 오래되었습니다. 다시 액세스되므로 백그라운드에서 발생합니다. 또한 그것은 웅장한 계획에서 비교적 드문 사건입니다. 대부분의 페이지 폴트는 부드러울 것입니다.
Lewis Kelsey

대기 목록에는 자체 우선 순위 시스템도 있으며 0 및 사용 가능 목록이 비어 있으면 가장 낮은 우선 순위에서 대기 페이지를 페이징하기 시작합니다. 우선 순위가 무엇인지 잘 모르겠지만 이전 LRU 연령에 해당 할 수 있습니다
Lewis Kelsey 19

16

나는 맨 위의 맨 페이지에서 발췌를 뻔뻔스럽게 복사하고 있습니다.

VIRT-가상 이미지 (KB) 작업에 사용 된 총 가상 메모리 양입니다. 여기에는 모든 코드, 데이터 및 공유 라이브러리와 스왑 아웃 된 페이지 및 매핑되었지만 사용되지 않은 페이지가 포함됩니다.

SWAP-상주하지는 않지만 작업에있는 스왑 된 크기 (kb) 메모리입니다. 이것은 스왑 아웃되었지만 추가 비 상주 메모리를 포함 할 수있는 메모리입니다. 이 열은 가상 메모리에서 실제 메모리를 빼서 계산됩니다.


5

여기 참조 : 물리적 대 가상 메모리

가상 메모리는 하드 드라이브에 저장되며 RAM이 가득 차면 사용됩니다. 물리적 메모리는 컴퓨터에 설치된 RAM 칩의 크기로 제한됩니다. 가상 메모리는 하드 드라이브의 크기에 의해 제한되므로 가상 메모리에는 더 많은 저장 공간이 있습니다.


가상 메모리가 스왑 파일 / 파티션 내부의 하드 드라이브에 저장되어 있습니까?
BruceJohnJennerLawso

3
@BruceJohnJennerLawso : 아니, 가상 =은 + 실제 교환하지
RickyA

@RickyA, 가상> = 물리적 인 항상 동의합니다.
hastrb
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.