TIL

Q1. Redis 같은 인메모리 DB가 SAVE 명령어로 스냅샷을 저장할 때, 메모리 사용량이 2배로 늘어나지 않는 이유는 무엇일까요? 정답: Copy-on-Write (CoW) 기법 때문입니다.

설명: 데비존스 님이 정리하신 ‘14-추가 페이징의 장점: Copy on write’ 내용이 핵심입니다.

Redis 부모 프로세스는 fork()를 호출하여 자식 프로세스를 만듭니다.

이때 자식 프로세스는 부모의 메모리를 물리적으로 복사하지 않고, 페이지 테이블만 복사하여 같은 물리 메모리 프레임을 가리킵니다. (읽기 전용으로 마킹)

부모 프로세스에 새로운 쓰기(Write) 요청이 들어오면, OS는 그제야 해당 페이지를 새로운 물리 공간에 복제하고 부모가 그곳을 쓰게 합니다.

변경되지 않은 데이터는 여전히 부모와 자식이 공유하므로, 실제 메모리 사용량은 2배가 되지 않고 ‘변경분이 발생한 페이지만큼’만 늘어납니다.

Q2. 4KB 페이징 시스템에서, 만약 페이지 크기를 4MB로 확 늘려버리면 어떤 일이 벌어질까요? 정답: TLB 적중률은 올라가지만, 내부 단편화가 심각해집니다.

장점 (TLB Reach 증가):

페이지 크기가 커지면 전체 메모리를 커버하기 위해 필요한 페이지 개수(PTE 개수)가 줄어듭니다.

정리하신 ‘TLB(페이지 테이블 캐시)’는 크기가 작습니다. 페이지가 4MB로 커지면, TLB 한 줄이 커버할 수 있는 메모리 범위(TLB Reach)가 1000배(4KB -> 4MB) 넓어집니다. 따라서 메모리 접근 횟수가 줄어 성능이 향상됩니다.

단점 (내부 단편화 증가):

정리하신 ‘페이징의 단점: 내부 단편화’ 섹션을 보면, 페이지 안에서 남는 공간이 낭비된다고 하셨죠?

4MB 페이지를 쓰는데 프로세스가 4MB + 1byte만 필요하다면? 1byte 때문에 4MB짜리 페이지 하나를 더 써야 합니다. 즉, 거의 4MB 가까운 공간이 낭비될 수 있습니다.

Q3. 유닉스 파일 시스템에서 1KB짜리 텍스트 파일을 읽는 것과, 10GB짜리 영화 파일의 ‘정중앙’을 읽는 것 중, 디스크 I/O 횟수는 어디가 더 많을까요? 정답: 10GB 파일의 정중앙을 읽을 때 디스크 I/O가 훨씬 많이 발생합니다.

설명: 데비존스 님의 ‘유닉스 파일 시스템’ 노트에 있는 간접 블록(Indirect Block) 구조 때문입니다.

1KB 파일: i-node에 있는 ‘직접 블록’ 주소 12개 중 하나만 보면 바로 데이터 위치를 알 수 있습니다. (I/O 적음)

10GB 파일: 직접 블록 범위를 아득히 넘어섭니다. 파일의 중간이나 끝부분 데이터를 찾으려면 i-node -> 삼중 간접 블록 -> 이중 간접 블록 -> 단일 간접 블록 -> 실제 데이터 블록 순으로 타고 들어가야 합니다.

데이터 위치를 알아내기 위해서만 인덱스 블록을 3번 이상 더 읽어야 하므로 오버헤드가 더 큽니다.

Q4. 컨텍스트 스위칭(Context Switching)이 일어날 때, CPU 옆에 붙어 있던 TLB의 데이터는 어떻게 처리해야 할까요? 정답: TLB를 전부 비워야(Flush) 합니다. (성능 저하의 원인)

설명:

프로세스 A의 가상 주소 0x1000과 프로세스 B의 가상 주소 0x1000은 서로 다른 물리 주소를 가리킵니다.

하지만 TLB는 단순히 가상 주소 -> 물리 주소 매핑만 저장합니다.

따라서 프로세스가 바뀌면(컨텍스트 스위칭), 기존 TLB 정보는 쓰레기 값이 되므로 TLB Flush(비우기)를 수행해야 합니다.

결과: 프로세스 B가 막 실행을 시작했을 때는 TLB가 텅 비어있으므로, 초기에는 TLB Miss가 계속 발생하여 메모리 접근 속도가 느려집니다. 이게 컨텍스트 스위칭 비용의 큰 부분을 차지합니다.