메모리 관리 — 유한한 RAM을 쥐어짜다

가상 메모리가 "메모리가 무한한 척"을 가능케 했지만 — 물리 RAM은 유한하다. 그래서 OS는 제한된 프레임을 어떻게 나눠 주고, 가득 차면 무엇을 내보내고, 부족이 심해지면 어떻게 버티는지를 끊임없이 결정한다. 이 유한한 자원의 관리가 — 무엇을 메모리에 두고 무엇을 버릴까라는 보편적 고민의 원형임을 본다.

빈틈의 두 종류 — 내부·외부 단편화

메모리를 나눠 주다 보면 *빈틈(단편화)*이 생긴다. 내부 단편화는 — 필요보다 큰 블록을 줘서 안에 못 쓰는 자투리가 남는 것이다(3KB만 필요한데 4KB 페이지를 통째로 주면 1KB 낭비). 외부 단편화는 — 전체 빈 공간은 충분한데, 흩어져 있어 연속으로 못 쓰는 것이다(여기 2KB, 저기 2KB 비었는데 4KB 연속이 필요하면 못 준다). 흥미롭게도 페이징이 외부 단편화를 거의 없앤다 — 메모리를 고정 크기 프레임으로 나누면 어느 빈 프레임이든 갖다 쓰면 되니까(연속일 필요가 없다). 대신 페이지 크기만큼의 내부 단편화는 남는다 — 단편화는 형태를 바꿀 뿐 공짜로 사라지진 않는다.

가득 차면 누굴 내보내나 — 페이지 교체

물리 메모리가 꽉 찼는데 새 페이지가 필요하면 — 기존 페이지 하나를 디스크로 내보내고(swap out) 그 자리를 내준다. 누구를 희생시킬지가 페이지 교체 알고리즘이다. FIFO(먼저 온 것 먼저)는 단순하나 어리석고, 이상적인 OPT(앞으로 가장 오래 안 쓸 것)는 미래를 모르니 불가능하다. 현실적 절충이 LRU(가장 오래 안 쓴 것) — 최근 안 쓴 페이지는 앞으로도 안 쓸 가능성이 높다는 *지역성(locality)*에 기댄다. (출처: Page replacement.) 캐시 시스템의 LRU/LFU 축출도 바로 이 페이지 교체와 같은 원리다 — 유한한 공간에서 무엇을 버릴지의 보편적 문제다.

너무 부족하면 — 스래싱

부족이 심해지면 재앙이 온다. 모든 프로세스의 *작업 집합(working set, 최근에 실제로 쓰는 페이지들)*을 합친 게 물리 메모리를 넘으면 — 페이지를 내보내자마자 다시 필요해져, 디스크와 메모리 사이로 페이지를 계속 주고받느라 일은 거의 못 하고 페이지 교체만 하게 된다. 이게 **스래싱(thrashing)**이다. CPU 사용률은 떨어지는데 디스크는 미친 듯이 돌고 시스템이 기어간다. 해법은 — 작업 집합이 메모리에 맞도록 동시 실행 프로세스를 줄이거나, 메모리를 늘리는 것이다. (출처: Thrashing & working set.)

영리한 절약 — copy-on-write, 그리고 최후의 수단

OS는 메모리를 영리하게 아낀다. 02편의 fork가 부모를 통째로 복사하지 않고 — **copy-on-write(COW)**로 부모·자식이 일단 같은 물리 페이지를 공유하다가 누군가 쓰려는 순간에만 그 페이지를 복사한다(대부분은 안 바뀌니 큰 절약이다). 그래도 메모리가 완전히 바닥나면 — 리눅스의 OOM Killer가 덜 중요한 프로세스를 골라 강제 종료해 RAM을 확보한다(프로그램이 만나는 "메모리 부족" 오류의 시스템 버전이다).

왜 보편적인가 — 유한한 메모리에서 무엇을 버릴까는 컴퓨팅 전반을 관통한다. 불필요한 데이터 회수, 캐시 축출(LRU/LFU), 큐에 상한 두기, 버퍼 크기 정하기 — 모두 *"공간은 유한하니 관리해야 한다"*는 같은 명제의 변주다. 그리고 스래싱은 과부하 보호와 같은 교훈을 준다 — 감당 못 할 양을 욱여넣으면 전부 느려지니, 동시에 처리하는 양을 제한해야 한다.

정리하면, OS는 유한한 물리 RAM을 — 단편화(내부/외부, 페이징이 외부를 해결)를 감수하며 나눠 주고, 가득 차면 페이지 교체(LRU, 지역성)로 희생자를 골라 swap하며, 부족이 심하면 스래싱(작업 집합 초과)으로 무너지는 걸 동시 실행 제한으로 막고, copy-on-write로 아끼되 정 안 되면 OOM Killer로 최후의 정리를 한다. 이 모든 *"유한한 공간을 어떻게 쓰나"*는 캐시·큐 같은 모든 자원 관리와 한 형제다. 메모리를 봤으니, 이제 디스크를 파일로 추상화하는 파일 시스템이 다음이다.