컴퓨터를 사용하다 보면 갑자기 프로그램이 느려지거나 종료되는 답답한 경험을 한 적 있으신가요?

이런 문제들은 대부분 '메모리 부족' 때문입니다.

혹시 컴퓨터가 메모리를 어떻게 관리하는지 궁금했던 적 있나요? 사실 우리 컴퓨터는 메모리를 매우 꼼꼼하고 영리하게 관리하고 있답니다. 특히 리눅스라는 운영체제는 "모든 메모리를 직접 관리한다!" 라는 철학을 가지고 있어요. 오늘은 이 복잡한 메모리 관리 과정을 친절하고 재미있게 풀어 드릴게요~

🚦 1장: 리눅스는 메모리를 어떻게 관리할까요?

🌟 메모리 전체를 리눅스가 관리한다고요?

네, 맞습니다! 리눅스는 시스템에 설치된 메모리를 혼자서 깔끔하게 관리합니다.

그 말은 커널(리눅스의 핵심!)이 프로세스와 자신이 사용할 메모리까지 모두 관리한다는 뜻이에요.

커널은 마치 엄마처럼 집안의 모든 방을 꼼꼼히 관리하는 역할을 하는데요. 프로세스들이 메모리를 요구할 때마다 이를 적절히 할당해주는 역할을 합니다.

이렇게 하면 프로세스들은 필요한 만큼 메모리를 얻을 수 있고, 불필요한 메모리는 빠르게 반환됩
니다. 깨끗한 방을 유지하려면 엄마가 직접 청소해야 하듯이, 리눅스도 커널이 나서서 메모리 정리를 하는 거죠~

예를 들어, 집에 여러 개의 방이 있다면 커널은 각각의 방에 누가 들어가 있고, 어디가 비어 있는지 항상 체크하는 똑똑한 집주인이에요.

$ free

이 명령어를 통해 현재 메모리 상태를 간편하게 확인할 수 있답니다.

이 명령어를 실행하면 전체 메모리 크기(total), 사용 중인 메모리(used), 남아 있는 메모리(free), 캐시로 사용하는 메모리(buff/cache), 실제로 사용 가능한 메모리(available)까지 보여줍니다. (친절하죠?)

📚 필드별로 쉽게 이해하기

사진으로 쉽게 이해하기

1. total

• 시스템 전체에 설치된 물리 메모리의 총량입니다.
• 그림의 전체 너비가 바로 total 영역이에요.

2. used = total - free - buff/cache

• 실제로 사용 중인 메모리입니다.
• 여기에는 프로세스가 직접 사용하는 메모리뿐만 아니라 커널이 사용하는 메모리도 포함됩니다.

3. free

• 아직 아무도 사용하지 않은, 명목상 '비어 있는 메모리'입니다.
• 하지만 실제로는 available 항목이 더 정확한 ‘사용 가능한 메모리’를 나타냅니다.
• free 항목은 프로세스가 바로 접근 가능한 영역만 포함합니다.

4. buff/cache

• 커널이 디스크 I/O 성능 향상을 위해 사용 중인 캐시 메모리입니다.
• buffer: 디스크 블록을 임시로 저장해두는 공간
• cache: 파일 내용을 저장해두는 공간
• 이 영역은 필요 시 해제 가능한 부분(노란색)과 해제 불가능한 부분(갈색)으로 나뉩니다.

5. available

• 실제로 애플리케이션이 사용할 수 있는 메모리 양입니다.
• free + buff/cache 중에서 커널이 해제 가능한 부분을 합친 값이에요.
• 그림에서는 ‘해제 가능’ 부분과 ‘free’를 합쳐서 available로 표시하고 있죠.

6. 프로세스가 사용 중

• 애플리케이션이나 사용자 프로그램이 현재 점유 중인 메모리입니다.
• 이 영역은 커널이 알아서 회수하지 않으며, 해당 프로세스가 종료되어야 해제됩니다.

✅ 요약

항목	의미 요약
total	시스템에 설치된 메모리 총량
free	바로 사용 가능한 메모리 (작음)
available	실제로 사용 가능한 메모리. free 필드값과 비어 있는 메모리가 줄어 들었을 때 해제 가능한 커널 내부 메모리 영역(예를 들어 페이지 캐시) 크기를 더한 값 (큰 값)
buff/cache	커널이 캐시로 점유한 메모리이자, 데이터를 빠르게 접근하기 위해 저장한 임시 공간
used	프로세스 + 커널이 사용 중인 메모리

이 그림을 이해하면 free 명령어 결과를 해석할 때 숫자에 너무 얽매이지 않고, 커널이 얼마나 유동적으로 메모리를 관리하는지 감을 잡을 수 있습니다!

🚧 2장: used와 buff/cache의 비밀을 풀어보자!

🗃 used 메모리의 진짜 모습

간단하게 이야기하면 used는 프로세스가 쓰고 있는 메모리, 그리고 커널 자신이 쓰고 있는 메모리를 모두 포함한 값이에요.

'used' 메모리는 실제로 프로세스가 점유하고 있는 공간과, 커널이 스스로 사용하는 공간을 모두 포함한 값이라는 거죠. 프로그램이 작동할 때마다 점점 올라가고, 프로그램이 종료되면 다시 내려갑니다. 마치 도서관에서 책을 빌렸다가 반납하면 빈자리가 다시 생기는 것과 같은 원리죠.

만약 어떤 프로세스가 종료되면, 커널이 알아서 그 메모리를 깨끗하게 비워주는 거죠.

실제로 메모리를 많이 쓰는 프로그램을 실행한 뒤 종료하면, used 값이 다시 원래대로 돌아가는 걸 눈으로 확인할 수 있어요. (신기하죠?)

memuse.py 실험

✅ memuse.py 전체 코드 (해설 주석 추가)

#!/usr/bin/python3
import subprocess

# 사용할 리스트 크기 설정 (데이터 수: 1천만 개)
# 너무 크면 메모리 부족으로 실행 실패할 수 있음
size = 10000000

# 현재 시스템 메모리 상태를 출력 (실험 전 상태)
print("메모리 사용 전의 전체 시스템 메모리 사용량을 표시합니다.")
subprocess.run(["free"])

# 리스트에 0을 1천만 개 생성 (메모리를 실제로 할당함)
array = [0] * size

# 메모리 사용 후의 시스템 상태 출력
print("메모리 사용 후의 전체 시스템 메모리 남은 용량을 표시합니다.")
subprocess.run(["free"])

📌 실행 순서별 요약:

1. 프로그램 실행 전 free 출력
2. 리스트를 생성하며 메모리 사용 (array = [0] * 10000000)
3. 프로그램 내부에서 다시 free 출력
4. 프로그램 종료 후, 사용자가 터미널에서 free 재실행

🔍 각 단계 분석

✅ 1. 프로그램 실행 전

Mem:  16257384  513144   15338352  3572  405888  15474572

• total: 16.2GiB (16257384 KiB)
• used: 513144 KiB
• free: 15.3GiB
• buff/cache: 405888 KiB
• available: 15474572 KiB

🔎 상태:
→ 전체 시스템 메모리 중 대부분이 아직 사용되지 않음 (정상적인 idle 상태)

✅ 2. 프로그램 실행 후 (array 생성 직후)

Mem:  16257384  593596  15257900  3572  405888  15394120

• used가 +80MiB 증가
  → 593596 - 513144 = 80452 KiB ≈ 78.5MiB

🔎 해석:
→ Python 리스트 생성으로 약 80MiB 메모리가 사용됨
→ available 값도 함께 감소함

✅ 3. 프로그램 종료 후 (터미널에서 free 재실행)

Mem:  16257384  523968  15546368  3576  187048  15474436

• used: 523968 (다시 거의 원래대로 돌아옴)
• buff/cache: 감소 (405888 → 187048)
• available: 다시 원래 수준인 15474436

🔎 해석:

• 프로그램이 종료되자 array에 할당됐던 메모리가 커널에 의해 해제됨
• used 수치가 다시 줄고, available도 회복
• 정확히 종료 전과 일치하진 않지만 거의 같은 수준 (이는 다른 백그라운드 활동 때문일 수 있음)

📊 핵심 정리

구분	used (KiB)	available (KiB)	설명
실행 전	513,144	15,474,572	대부분 여유 상태
array 생성 후	593,596	15,394,120	약 80MiB 사용 증가
종료 후	523,968	15,474,436	사용량 거의 복귀됨

✅ 결론

• memuse.py 실행 후 메모리를 사용한 흔적이 used 수치의 증가로 보였고,
• 프로세스가 종료되자 메모리가 자동으로 해제되어 다시 줄어든 것을 확인할 수 있습니다.
• 이것이 리눅스 메모리 관리 시스템의 특징이며, 우리가 프로그램 종료 시 직접 free()하지 않아도 되는 이유예요.

💡 참고 팁

• Python은 가비지 컬렉터가 있어도, 프로세스가 종료되기 전까지는 메모리가 유지됩니다.
• 이 실험은 메모리 사용 추세 분석이나 OOM 상황 디버깅 시 유용합니다.
• 같은 방식으로 free나 top, sar 명령어와 함께 메모리 변화 패턴을 파악해보는 것도 좋아요.

"프로그램이 종료되면 해당 메모리는 운영체제(리눅스 커널)에 의해 회수된다"
는 사실을 증명하는 근거입니다.

✨ buff/cache의 마법

buff/cache는 데이터를 미리 메모리에 올려놓아 다음 번 접근할 때 속도를 높이는 캐시 메모리입니다. 빈번히 읽는 데이터를 계속해서 하드디스크에서 읽으면 시간이 오래 걸리니까, 자주 쓰는 책을 책상 위에 올려놓는 것과 같아요.

✅ 실험하기

#!/bin/bash
# 1. 파일 작성 전 시스템 메모리 상태 출력
echo "파일 작성 전의 시스템 전체 메모리 사용량을 표시합니다."
free

# 2. 1GiB 크기의 파일을 생성하여 페이지 캐시 사용 유도
echo "1GB 파일을 새로 작성합니다. 커널은 메모리에 1GB 페이지 캐시 영역을 사용합니다."
dd if=/dev/zero of=testfile bs=1M count=1024

# 3. 파일 생성 후 메모리 상태 출력 → 페이지 캐시 증가 확인
echo "페이지 캐시 사용 후의 시스템 전체 메모리 사용량을 표시합니다."
free

# 4. 파일 삭제 → 페이지 캐시 제거
echo "파일 삭제 후, 즉 페이지 캐시 삭제 후의 시스템 전체 메모리 사용량을 표시합니다."
rm testfile

# 5. 파일 삭제 후 메모리 상태 출력 → buff/cache 감소 확인
free

📊 실험 결과 정리

단계	used (KiB)	buff/cache (KiB)	free (KiB)	available (KiB)
파일 작성 전	523004	192476	15541864	15472644
파일 작성 후	522072	1269160	14466152	15451568
파일 삭제 후	521748	194128	15541508	15473096

📌 핵심 변화 요약

1. 파일 작성 전 (baseline)

   • buff/cache: 약 192MiB
   • 시스템이 안정된 상태, 페이지 캐시도 적당한 수준

2. 파일 작성 후

   • buff/cache: 약 1.2GiB로 급증
     → 이는 dd 명령으로 1GiB 파일을 생성하면서, 커널이 해당 데이터를 페이지 캐시로 메모리에 저장했기 때문입니다.

3. 파일 삭제 후

   • buff/cache: 다시 약 194MiB로 감소
     → 커널이 사용하지 않는 페이지 캐시를 자동으로 해제했음을 보여줍니다.

📈 시각적 변화 흐름

    buff/cache (KiB)

1.4M |                        
     |                     
1.2M |                ● 파일 작성 후
     |                     
 200K | ● 파일 작성 전    ● 파일 삭제 후
     |
     +----------------------------→ 시간 흐름
        작성 전     생성 후      삭제 후

🧠 해석 및 결론

• dd 명령으로 생성한 1GiB 파일의 내용은 디스크에만 저장되지 않고, 동시에 메모리의 페이지 캐시에 올라갑니다.
• 이로 인해 buff/cache 값이 급격히 증가합니다.
• 하지만, 파일을 rm 명령어로 삭제하면 커널은 이 데이터가 더 이상 필요하지 않음을 인지하고 페이지 캐시를 해제합니다.
• 이 과정을 통해 메모리의 buff/cache 영역이 자동으로 줄어드는 것을 확인할 수 있습니다.

✅ 정리하자면

개념	설명
페이지 캐시	디스크 데이터를 빠르게 접근하기 위해 메모리에 임시로 저장하는 영역
buff/cache	페이지 캐시 + 버퍼 캐시 영역을 나타냄
자동 해제	시스템이 필요하면 해당 메모리를 자동으로 반환 (커널이 똑똑함!)

🔍 실무에서의 팁

free 명령어로 메모리를 볼 때 used나 free만 보고 “메모리가 부족하다”고 오해하지 마세요!
진짜 사용할 수 있는 메모리는 available이고, buff/cache는 필요 시 커널이 반납 가능한 메모리입니다.

free와 available 의미 차이

free와 available은 모두 "쓸 수 있는 메모리"처럼 보이지만, 실제로는 완전히 다른 의미를 담고 있습니다.

항목	의미	왜 헷갈릴까?	진짜로 쓸 수 있나?
free	지금 아무도 사용하고 있지 않은 메모리 공간	숫자가 작으면 “메모리 부족하잖아?!”라고 생각하기 쉬움	쓸 수 있지만, 시스템은 일부를 캐시로 활용 중
available	필요할 경우 커널이 즉시 회수해서 사용할 수 있는 전체 메모리	캐시 포함이라 free보다 훨씬 큼	진짜로 사용 가능한 메모리! 가장 신뢰해야 할 값

🔍 예시로 이해해보자

$ free
               total        used        free      shared  buff/cache   available
Mem:        16257384      523004     15541864        3576      192476     15472644

• free: 15,541,864 KiB → 진짜로 아무도 안 쓰는 공간
• available: 15,472,644 KiB → 캐시까지 포함한 실제로 쓸 수 있는 공간

그런데 왜 available이 free보다 더 작을 수도 있고, 더 클 수도 있냐면…

🔎 왜 available이 free보다 클 수도 있을까?

바로 buff/cache 영역이 포함되기 때문입니다.

리눅스는 성능을 높이기 위해 가능한 많은 메모리를 캐시(임시 저장)로 사용합니다.
하지만 이 캐시 메모리는 커널이 필요하면 언제든 회수해서 다른 데 쓸 수 있어요.

그래서 available에는 다음이 포함돼요:

• free: 아무도 안 쓰는 메모리
• • buff/cache: 캐시로 쓰이지만 곧 회수 가능
• • 기타 reclaimable 영역 등

👉 즉, available = free + reclaim 가능한 메모리

예시로 보면 더 명확해요

              total        used        free      shared  buff/cache   available
Mem:        16257384      523004     15541864      3572     192476     15472644

• free: 15,541,864 KiB (15GB) → 지금 안 쓰고 있는 공간
• available: 15,472,644 KiB → 지금 쓸 수 있는 전체 공간
  → 캐시 일부도 포함하니, 약간 작거나 클 수도 있어요.

🧐 그런데 왜 available이 free보다 작을 때도 있을까?

그 이유는 다음과 같아요:

• 시스템에 메모리를 많이 쓴 프로세스가 떠 있음
• buff/cache 영역도 많이 사용 중인데 당장 회수할 수 없는 상태
• 즉, 커널이 안전하게 회수할 수 있는 메모리 양이 적다고 판단하면
  → available은 free보다 작을 수도 있어요.

상황	available vs free	이유
일반적인 상황	available > free	캐시 메모리 포함
메모리 빡빡한 상황	available < free	회수 가능한 캐시가 거의 없음
파일 캐시, 버퍼 많을 때	available > free	필요 시 회수 가능하므로 더 큼

💬 한 줄 요약

free는 지금 완전히 놀고 있는 메모리,
available은 당장 회수해서 쓸 수 있는 "잠재적 여유 메모리"예요.

🎓 핵심 차이 요약

구분	free	available
의미	아무도 안 쓰는 메모리	지금 당장은 쓰이고 있지만, 시스템이 필요하면 회수 가능한 메모리 포함
포함 내용	진짜로 놀고 있는 메모리만	free + 일부 캐시 + 버퍼 캐시
시스템 신뢰도	낮음 (헷갈리기 쉬움)	높음 (현실 반영된 값)
보기 좋은 항목	❌	✅ 실제 사용 가능한 공간으로 판단해야 할 지표

🧠 비유로 쉽게 이해하기

• free: 책상에 아무것도 안 올려둔 공간
• available: 책상 위에 책이 있지만, 당장 쓰지 않으면 옆으로 밀어버릴 수 있는 공간까지 포함

즉, 당장 비어 있는가? vs. 필요하면 비울 수 있는가?의 차이예요.

📝 정리

• free는 현재 사용되지 않는 공간
• available은 사용 중이지만, 언제든 회수 가능한 공간까지 포함
• 메모리 부족 판단 시 무조건 available을 기준으로 판단해야 합니다!

sar 명령어를 사용해서 메모리 관련 정보를 수집하기

sar -r 명령어를 사용하면 두 번째 인수로 지정한 간격(예제는 1초)으로 메모리 관련 통계 정
보를 얻을 수 있습니다.

🚨 3장: 메모리가 부족할 때의 히어로, OOM Killer

📉 메모리가 부족하면 어떡해요? (OOM Killer 등장!)

메모리 관리가 잘되다가도 시스템이 너무 바쁘고 메모리를 심하게 쓰면 갑자기 부족해질 수 있어요. 이걸 'Out Of Memory'(OOM) 상태라고 부릅니다. 이런 상황에서는 리눅스가 과감하게 하나의 프로세스를 강제로 종료시켜요! 네, 조금 무섭지만... 생존을 위한 어쩔 수 없는 선택이죠. 이걸 OOM Killer라고 불러요.

만약 여러분이 돌리던 프로그램이 갑자기 사라졌다면, OOM Killer 때문일 수 있습니다.

💡 먼저 이해할 개념: available과 free

리눅스에서 메모리 상태를 나타낼 때는 free, used, available, buff/cache 등의 값이 나오죠.

• free: 말 그대로 지금 아무도 안 쓰고 있는 메모리
• available: 필요하면 바로 회수해서 쓸 수 있는 재활용 가능한 메모리
  • buff/cache 영역도 포함됨
  • 즉, free보다 항상 크거나 작을 수 있음!

❗ 그럼에도 메모리가 부족해진다면?

일반적으로는 buff/cache 영역을 줄이거나 다른 프로세스가 종료되면서 메모리를 회수할 수 있어요.

시스템 부하가 높아지면 free 메모리가 줄어듭니다.

이럴때, 커널의 메모리 관리 시스템은 재활용 가능한 메모리 영역을 해제해 free 값을 늘립니다.

예를 들어 재활용 가능한 메모리에는 디스크에서 데이터를 읽어서 아직 변경되지 않은 페이지
캐시가 있습니다. 이런 페이지 캐시는 동일한 데이터가 디스크에 존재하므로 메모리를 해제해
도 문제가 없습니다.

만약 회수할 수 있는 재활용 메모리(available)도 모두 써버리고
더는 줄일 수 없는데 새로운 메모리 요청이 온다면?

시스템은 이제 선택을 해야 해요. 이때 동작하는 무서운 친구가 등장합니다:
마치 초과 탑승한 비행기에서 승객 몇 명을 어쩔 수 없이 내려야 하는 상황과 같죠.

💀 OOM Killer: 메모리 부족 시 발동되는 "프로세스 제거자"

OOM은 Out Of Memory의 줄임말이고,
OOM Killer는 리눅스 커널이 강제로 프로세스를 종료시켜
메모리를 확보하려는 자동 방어 시스템이에요.

🧠 OOM Killer의 작동 방식

1. 시스템이 메모리 부족 상황에 빠짐
2. available 메모리조차 부족해서 더 이상 쓸 수 없음
3. 커널이 "이 중 누구를 죽이면 가장 이득일까?" 계산함
4. 메모리를 많이 쓰면서 중요도가 낮은 프로세스를 "제물"로 삼음
5. 그 프로세스를 강제로 종료하고 메모리를 회수함

📉 예시 상황 (그림 설명)

Out Of Memory 상태

상태	설명
total	전체 메모리
free	지금 당장 아무도 안 쓰는 메모리
buff/cache	페이지 캐시나 버퍼 캐시로 쓰이는 메모리
used	total - free - buff/cache
available	실제로 필요하면 회수 가능한 메모리 (buff/cache 포함)

→ 그런데 used 영역이 너무 커서 더 이상 available도 확보 못 하면 OOM 발생!

OOM Killer 동작 전후

• 동작 전: 커널도 메모리를 쓰고, 각종 프로세스도 메모리를 차지 중
• 동작 후: OOM Killer가 불필요한 프로세스를 강제 종료
  → 남은 메모리를 확보하고 시스템을 정상으로 복귀시킴

🧪 OOM 발생 확인 방법

$ dmesg | grep -i oom

• 위 명령어로 커널 로그에서 OOM Killer가 작동한 흔적을 확인할 수 있어요. 다음과 같이 출력돼요.

[XXX] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),...

🧹 메모리 누수나 OOM 예방 팁

1. ps 명령어로 프로세스 메모리 감시

$ ps aux

→ 이 중 RSS 필드를 보면 각 프로세스의 실제 메모리 사용량을 확인할 수 있어요.

2. 수상한 프로세스 모니터링

• 시간이 지날수록 RSS가 계속 증가한다면 메모리 누수일 가능성
• 원인을 못 찾으면 정기 재시작(cron 등)으로 임시 해결 가능

OOM Killer가 동작하는 시스템이라면
메모리가 충분하지 않은 경우가 많습니다. 동시 실행 중인 프로세스 개수를 줄여서 메모리 사용
량을 줄이거나 또는 추가로 메모리를 설치하는게 좋습니다.

✅ 요약 정리

개념	설명
available	커널이 재활용할 수 있는 메모리 (free보다 정확한 지표)
OOM 상태	전체 메모리 중 재활용 가능한 부분도 다 써버린 상황
OOM Killer	메모리 부족 시, 불필요한 프로세스를 종료해서 시스템을 살리는 기능
확인 명령어	dmesg, ps aux, top, free 등으로 상태 확인 가능
예방 방법	수상한 프로세스 감시, 필요시 재시작 자동화, 메모리 증설 등

“어느 날 갑자기 프로그램이 튕겼다?” → OOM Killer의 소행일 수 있어요.
dmesg 로그 확인은 필수입니다!

추가 정리 : 🎯 OOM Killer는 어떤 기준으로 프로세스를 죽일까?

리눅스 커널이 OOM(Out Of Memory) 상황에서 어떤 프로세스를 죽일지 결정하는 기준은 사실 꽤 똑똑하고 계산적인 방식으로 진행됩니다. 바로 "OOM Score (OOM 점수)"라는 기준이 있어요.

커널은 메모리가 부족할 때, 다음과 같은 기준을 종합적으로 고려해 "누굴 죽이는 게 가장 이득일까?"를 계산합니다:

1. 메모리 사용량이 많은 프로세스

• 기본적으로 RSS(Resident Set Size), 즉 실제 메모리를 많이 차지하는 프로세스는 좋은 후보가 됩니다.
• 왜냐하면, 이 프로세스를 죽이면 많은 메모리를 한꺼번에 회수할 수 있기 때문이죠.

2. oom_score 값이 높은 프로세스

• 리눅스는 각 프로세스마다 oom_score라는 점수를 관리해요.
• 점수가 높을수록 죽을 확률이 높음
  → 이 점수는 /proc/[PID]/oom_score 파일로 확인할 수 있어요.

$ cat /proc/1234/oom_score

3. 프로세스의 중요도 (oom_score_adj)

• 사용자는 프로세스에 중요도 가중치도 부여할 수 있어요.
• 이 값은 -1000에서 +1000까지 설정 가능:
  • -1000: 절대 죽이면 안 되는 프로세스 (예: 시스템 데몬, SSH 등)
  • 0: 기본값
  • +1000: 아주 죽이기 쉬운 프로세스

$ echo -1000 > /proc/1234/oom_score_adj

→ 이걸로 OOM Killer가 어떤 프로세스를 피하거나 우선적으로 종료하도록 정책을 조정할 수 있어요.

4. 프로세스의 유효 사용자 ID(uid)

• 시스템은 일반적으로 루트 프로세스보다는 일반 사용자 프로세스를 먼저 종료하려고 해요.

5. 백그라운드 vs 포그라운드

• 데스크탑 환경에서는 사용자가 직접 사용하는 앱보다 백그라운드에서 조용히 돌아가는 앱을 먼저 종료하려고 하기도 해요.

🔍 예시 시나리오

PID	프로세스	메모리 사용량	oom_score_adj	최종 종료 가능성
100	SSH 데몬	적음	-1000	매우 낮음 ❌
200	Python 서버	많음	0	높음 🔥
300	DB 백업 툴	중간	+500	꽤 높음 🔥
400	크롬 브라우저	많음	0	사용자 포커스면 낮음

🛠 정리하자면

기준 항목	설명
oom_score	현재 메모리 부족 상황에서 각 프로세스의 "죽을 확률" 점수
oom_score_adj	사용자가 직접 조정할 수 있는 가중치 (중요도 설정)
메모리 사용량	많이 쓰는 놈이 죽으면 효율적!
프로세스 UID	루트보다 일반 사용자 프로세스가 더 죽기 쉬움
중요 데몬 여부	SSH, 시스템 필수 프로세스는 보호됨

✅ 확인 방법 정리

# 특정 PID의 oom_score 확인
cat /proc/1234/oom_score

# oom_score_adj 조정
echo -1000 > /proc/1234/oom_score_adj

요약: "가장 많은 메모리를 차지하면서도, 덜 중요한 프로세스"가 OOM Killer의 1순위입니다.
서버 운영 중이라면, 중요한 프로세스는 oom_score_adj = -1000으로 꼭 보호해 주세요!

---

🌈 4장: 가상 메모리의 신비로운 세계

가상 메모리는 실제 메모리를 가상 공간으로 나누어 관리합니다. 이를 통해 여러 가지 문제를 해결할 수 있습니다. 예를 들어 가상 메모리는 마치 모든 프로세스에 독립된 방을 제공하는 호텔과 같습니다.

🌌 가상 메모리의 마법!

메모리 관리의 핵심 중 하나가 바로 가상 메모리예요. 가상 메모리는 실제 메모리(물리 메모리)를 가상적으로 관리해서 프로세스가 직접 메모리를 다루지 못하게 합니다. 이렇게 하면 여러 가지 문제가 해결됩니다.

🧩 메모리 단편화 해결: 흩어진 공간도 이어 붙인다!

• 메모리를 할당하고 해제하는 작업이 반복되면 조각조각 나서 단편화가 발생합니다.
• 하지만 가상 메모리를 사용하면, 물리 메모리가 조각나 있어도 프로세스 입장에서는 연속된 공간처럼 보이게 만들 수 있어요.
• 퍼즐처럼 흩어진 물리 메모리를 논리적으로 이어 붙여주는 역할이죠!

🧍‍♀️🧍‍♂️ 멀티 프로세스도 OK: 모든 프로세스에 독립된 방

• 여러 프로그램이 동시에 돌아가도 각각의 프로세스에게 서로 완전히 독립적인 가상 주소 공간을 제공해 줍니다.
• 같은 프로그램을 두 번 실행해도 문제없이 돌아가는 이유는, 실제 물리 메모리 주소가 달라도 가상 주소로는 각자 동일한 주소에서 시작하는 듯이 보이기 때문이에요.
• 각자 다른 방에서 같은 인테리어를 한 셈이죠!

🛡 다른 방은 열 수 없다! 보안 보장

• 가상 메모리를 통해 자기 방(프로세스 메모리)만 보이고, 다른 방은 보이지 않아요.
• 즉, 다른 프로세스나 커널 메모리에 마음대로 접근하는 일이 원천 차단됩니다.
• 보안과 안정성까지 챙겨주는 1석 3조 기능이에요.

🏗️ 가상 메모리가 없다면 어떤 문제가 생길까?

🚨 문제 1: 메모리 단편화

메모리를 계속 할당하고 반납하다 보면, 비어 있는 공간이 여러 조각으로 흩어지게 됩니다.
이런 상태에서 연속된 큰 공간이 필요하면, 전체 빈 공간은 충분해도 할당에 실패할 수 있어요.

"조각조각 빈 방은 많지만, 커다란 짐 하나를 둘 연속된 공간은 없는 셈이죠."

🚧 문제 2: 여러 프로세스가 동시에 실행되기 어려움

가상 메모리가 없다면, 실제 메모리 주소에 맞춰 프로그램이 실행되어야 합니다.
그러면 같은 프로그램을 두 번 실행하면 주소가 겹쳐서 오류가 납니다.

• 프로그램 A: 300~500 사용 중이면,
• 프로그램 B는 같은 주소에 배치 못해서 실행 불가!

"모든 손님에게 301호만 주는 호텔이면 동시에 둘은 못 들어가요."

🔓 문제 3: 다른 메모리에 마음대로 접근 가능

프로세스가 다른 프로세스나 커널 메모리 주소를 지정하면 실제로 접근이 가능해집니다.
즉, 데이터 손상이나 보안 문제가 발생할 수 있어요!

"옆방 문이 열려 있다면, 그 방 짐도 함부로 만질 수 있다는 거죠."

🧠 가상 메모리의 동작 방식

🎯 기본 개념

출처 ： https://velog.io/@hyun0310woo/11-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%AC

가상 메모리의 원리는 생각보다 간단합니다. 프로세스가 4Gb의 크기를 가지고 있다고는 하지만 CPU가 한번에 4Gb의 코드를 읽을 수는 없습니다. 한번에 읽을 수 있는 코드, 다시 말해 메모리 크기는 제한적이라는 말입니다.

이는 CPU가 프로세스를 실행하기 위해서는 모든 코드에 대한 주소가 필요하지 않고 현재 실행 중인 코드에 대한 물리 메모리 정보만 알고 있으면 된다는 말입니다.

그리고 다음 코드로 넘어간다면 이미 읽었던 코드에 대한 정보는 물리 메모리에서 지워버리고 다시 읽어야 하는 코드 주소에 대한 정보만 실제 메모리에 올려서 실행하면 되는겁니다.

위와 같은 원리로 동작을 하기 위해서는 두 개의 주소가 필요합니다. 0 ~ 4Gb의 주소를 가지고 있는 프로세스가 참조하는 가상 주소(Vitual address)와 이러한 가상 주소 중에서 실제로 메모리에 올라가야 하는 주소인 물리 주소(Physical address)가 필요합니다.

• 가상 주소 (virtual address): 프로세스가 참조하는 주소 | 0 ~ 4Gb
• 물리 주소 (physical address): 실제 메모리 주소

CPU는 프로세스를 실행하기 위해서 먼저 가상 주소에 대한 정보를 찾습니다. 그리고 해당 가상 주소를 가지고 프로세스를 실행하기 위해서는 가상 주소가 실제로 어떤 물리 주소에 위치해 있는지 알아야합니다. : mmu로

가상 메모리는 "가상 주소(Virtual Address)"를 사용해서, 물리 주소(Physical Address)로 간접 접근하게 만드는 기술입니다.

가상 주소에 대비되는 시스템에 설치된 메모리의 실제 주소를 물리 주소라고 하며, 이런 주소를 사용해서 접근 가능한 범위를 주소 공간이라고 합니다。

• 프로세스는 오직 가상 주소만 사용합니다.
• 가상 주소는 실제 메모리 주소가 아니라, 중간에서 커널이 번역해주는 주소예요.
• 번역 작업은 페이지 테이블(Page Table)을 통해 이루어집니다.

✅ 프로세스가 실행되는 구조

프로세스 하나는 최대 4GiB의 가상 주소 공간을 할당받아요.

실제 메모리(RAM)는 제한되어 있지만, 모든 코드를 한 번에 실행하는 건 아니기 때문에 필요한 부분만 올려서 실행해요.

이를 가능하게 하는 하드웨어가 MMU(Memory Management Unit)입니다.

🧱 MMU의 역할

MMU는 CPU에서 코드를 실행할시에 가상 주소를 실제 물리 주소로 변환해주는 하드웨어 칩입니다.

CPU가 가상 주소로 요청하면 MMU가 페이지 테이블을 참조해 물리 주소로 변환합니다.
CR3 레지스터: 현재 프로세스의 페이지 테이블 시작 주소를 저장하는 CPU 레지스터입니다.

정리하자면 CPU는 프로세스를 실행하기 위해 가상 메모리 주소에 대한 정보를 찾고 실제로 해당 주소로 접근할 시에 MMU라는 하드웨어가 실제 물리 주소로 변환해서 CPU에게 전달해 줍니다.

이렇게 실제 메모리 용량보다 더 많은 프로세스를 실행하기 위해서 프로세스를 일정 부분만 메모리에 올려서 실행하는것과 그것을 도와주는 하드웨어에 대해서 알게되었습니다.

어떤 규칙으로 프로세스를 나누냐는 것?이냐가 아래입니다.

📖 페이지 테이블과 페이지

메모리는 페이지(Page) 단위(보통 4KiB)로 나뉘어 관리돼요.

• 커널은 각 프로세스마다 페이지 테이블을 만들어서, 가상 주소 → 물리 주소로 연결해줍니다.
• CPU는 메모리에 접근할 때 페이지 단위로 매핑된 주소를 참조합니다.

페이지 테이블 = 가상의 룸 넘버 → 실제 방 위치 안내도

⚡ TLB (Translation Lookaside Buffer)

MMU가 매번 페이지 테이블에 접근하면 느리기 때문에 자주 쓰는 주소는 TLB라는 고속 캐시에 저장해 속도를 높입니다..

🧠 가상 메모리가 어떻게 작동하는가?

✅ 프로세스가 실행되는 구조

• 프로세스 하나는 최대 4GiB의 가상 주소 공간을 할당받아요.
• 실제 메모리(RAM)는 제한되어 있지만, 모든 코드를 한 번에 실행하는 건 아니기 때문에 필요한 부분만 올려서 실행해요.
• 이를 가능하게 하는 하드웨어가 MMU(Memory Management Unit)입니다.

🧱 MMU의 역할

• 가상 주소 → 물리 주소 변환을 담당하는 하드웨어 장치
• CPU가 가상 주소로 요청하면 MMU가 페이지 테이블을 참조해 물리 주소로 변환합니다.
• CR3 레지스터: 현재 프로세스의 페이지 테이블 시작 주소를 저장하는 CPU 레지스터입니다.

🗺️ 페이지 테이블과 TLB

📖 페이지 테이블과 페이지

페이지 테이블이란?

"가상 주소를 물리 주소로 바꿔주는 비서!"

🎒 비유: 주소 변환이 필요한 배달원
우리가 프로그램을 실행하면, 운영체제는 각 프로그램(프로세스)마다 가상 주소 공간을 줘요.
하지만 컴퓨터는 진짜 물리 메모리(RAM) 주소를 알아야 데이터를 읽고 쓸 수 있겠죠?

그래서 필요한 게 바로…

📬 "주소 변환표" 역할을 하는 페이지 테이블 (Page Table)입니다!

🧭 페이지 테이블의 역할은?

기능	설명
주소 변환	CPU가 사용하는 가상 주소를 물리 주소로 변환해줘요.
접근 보호	이 주소가 유효한지? 읽기만 가능한지? 실행 가능한지? 등 접근 권한 확인도 해줘요.
메모리 할당 여부	물리 메모리가 아직 안 할당됐으면 페이지 폴트를 발생시켜요.

🧩 어떻게 구성돼 있을까?

운영체제는 가상 주소를 "페이지 단위(보통 4KiB)"로 나눠서 관리하고 있어요.
예: 4KB 단위로 쪼개서 가상 주소 0번 페이지, 1번 페이지, 2번 페이지… 식으로요.

📌 페이지 테이블은 이 각각의 가상 페이지 번호가 어디 물리 주소에 있는지를 저장해두는 표예요.

가상 페이지 번호 → 물리 페이지 번호
        0       →       3
        1       →       7
        2       →     없음 (페이지 폴트!)

📦 페이지 테이블은 어디에 있을까?

• 각 프로세스마다 고유한 페이지 테이블을 갖고 있어요!
• 페이지 테이블 자체도 물리 메모리에 저장되고,
• CPU는 CR3 레지스터를 통해 현재 사용 중인 페이지 테이블을 참조해요.

🌉 계층형 페이지 테이블이 필요한 이유

x86_64 시스템에선 가상 주소 공간이 128TB나 되니까,
모든 주소를 다 평면(1차원 배열)으로 저장하면 너무 커요! (256GB 넘게 먹음 😱)

그래서 메모리 낭비를 줄이기 위해 트리 구조처럼 계층적으로 관리합니다.

📚 책을 목차 → 챕터 → 페이지 순으로 찾듯,
페이지 테이블도 4단계 계층 구조로 쭉쭉 따라 내려가요.

💡 요약 정리

항목	설명
📌 정의	가상 주소를 물리 주소로 바꿔주는 주소 변환표
🧠 존재 이유	주소 보호, 접근 권한, 메모리 할당 관리
🧱 구조	페이지 단위 매핑 (4KB 기준), 계층형 테이블 구조
💥 폴트	매핑이 없으면 페이지 폴트 발생 → OS介입
🏢 각자 보유	모든 프로세스는 각자 자기만의 페이지 테이블을 가짐

“페이지 테이블은 모든 가상 메모리 접근을 책임지는 든든한 안내도다!”

페이지 테이블 = 가상의 룸 넘버 → 실제 방 위치 안내도

사실은 가상 주소 공간 크기는 고정된 값이고, 페이지 테이블 엔트리에 페이지와 대응하는 물리
메모리의 존재 여부를 관리하는 데이터가 있습니다.

참고로 "가상 주소를 물리 주소로 바꿔주는 실질적인 하드웨어"는 MMU (Memory Management Unit)입니다.

🧠 정리해보면 이렇게 나눌 수 있어요:

역할	주체	설명
📋 변환 정보 저장	페이지 테이블 (Page Table)	가상 페이지가 물리 메모리 어디에 있는지 저장된 표
⚙️ 주소 변환 실행	MMU (메모리 관리 유닛)	CPU 안에 있는 하드웨어. 페이지 테이블을 참고해 주소를 변환함
💡 의사 결정 주체	운영체제 (커널)	페이지 테이블 생성/관리, 페이지 폴트 처리, 권한 부여 등

즉, MMU는 변환을 ‘실행’하는 사람,
페이지 테이블은 그 ‘지도’,
운영체제는 그걸 ‘작성하고 감독’하는 관리자입니다.

⚡ TLB (Translation Lookaside Buffer)

• MMU가 매번 페이지 테이블에 접근하면 느리기 때문에 자주 쓰는 주소는 TLB라는 고속 캐시에 저장해 속도를 높입니다.

🔍 페이지 폴트 완전 정복: 컴퓨터가 ‘방을 찾지 못했을 때’ 생기는 일

🚪 페이지 폴트란? "그 방은 아직 준비되지 않았어요"

가상 메모리는 마치 호텔처럼 생겼습니다.

• 예약은 되어 있지만, 아직 실제 방이 만들어지지 않은 경우도 있죠!
• 이때 손님(프로세스)이 방(메모리)에 들어가려 하면, 프런트(커널)가 가서 급히 방을 만드는 과정이 발생합니다.

이게 바로 페이지 폴트(Page Fault)입니다.

이런 페이지 폴트 예외가 발생하면 CPU에서 실행 중인 명령이 중단되고, 커널 메모리에 배치된 페이지폴트 핸들러 page fault handler 처리가 실행됩니다.

🧠 기본 정의

• 프로세스가 가상 주소를 참조했는데, TLB도 모르고, 페이지 테이블에도 물리 주소가 없을 때 발생합니다.
• CPU는 실행을 멈추고 커널에게 페이지 폴트 예외(Page Fault Exception)를 발생시킵니다.
• 커널은 이 예외를 처리하고, 해당 페이지를 디스크에서 RAM으로 불러옵니다.

🧩 페이지 폴트의 종류: 다 같은 폴트가 아니다!

1) 📦 Minor Page Fault (마이너 폴트)

📌 "주소에 대응되는 물리 페이지는 이미 메모리에 있어요. 근데 페이지 테이블에만 아직 없었네요!"

• 예: 같은 프로그램이 이미 메모리를 공유하고 있는 경우 등
• 또는 fork() 이후에 부모와 자식이 같은 페이지를 공유하는 상태일 수도 있어요

이럴 때는 디스크 접근 없이, 페이지 테이블만 업데이트하면 끝!

✅ 빠르고 부담 없음

🧠 비유하자면?
이미 책은 책장에 꽂혀 있는데, 도서 목록(페이지 테이블)에만 누락된 상태예요.

"아! 목록에만 추가하면 되는구나~" 👓

🧠 메모리는 있는데, 주소표(페이지 테이블)가 빠져 있어서 생긴 일

2) 🛠️ Major Page Fault (메이저 폴트)

📌 "이건 큰일이에요! 그 주소의 데이터가 메모리에 없고 디스크에 있어요!"

• 디스크에 있던 데이터를 RAM으로 로딩해야만 할 경우

• 보통은 swap 영역이나 mmap된 파일에서 데이터를 디스크에서 읽어와야 해요

• 디스크 I/O는 엄청 느려서 ➡ CPU가 한참 기다려야 함

  즉, 디스크 I/O가 발생함

• 메이저 폴트가 자주 일어나면 성능이 뚝 떨어집니다

• 속도도 훨씬 느림 (하드디스크 → 메모리 복사)

🧠 비유하자면?
책장에도 책이 없고, 창고(디스크)까지 가서 찾아와야 해요.

"아이고 이걸 지금 가지러 가야 해?" 🧳

🧠 방이 아예 없어서, 새로 시트를 깔고 TV를 놓고 방을 꾸미는 작업이 필요한 상황

🧪 실전에서 이걸 어떻게 확인해?

ps -o min_flt,maj_flt -p <PID>

• min_flt: 마이너 폴트 횟수
• maj_flt: 메이저 폴트 횟수

demand-paging.py에서도 페이지에 접근하면 둘 중 하나가 올라가요!

✨ 그리고 이걸 완성시키는 기술, COW (Copy-On-Write)

🤔 언제 쓰냐면?

fork()로 부모 프로세스를 복사할 때요.
자식 프로세스를 만들기 위해 메모리를 전부 복사해야 한다면? 💥 비효율적이죠.

💡 해결책: "복사 안 하고 일단 같이 써!"

• 부모와 자식은 같은 메모리 페이지를 읽기 전용으로 공유

둘 중 누가 쓰기 시도를 하면?

-페이지 폴트 발생!

• 그때 비로소 해당 페이지를 진짜 복사해서 분리

🧠 마치 문서를 복사해달라고 해서 같이 보고 있다가, 한 명이 낙서를 하려고 하면 그때서야 복사해주는 느낌이에요

📌 그래서 얻는 이점은?
메모리 절약

• fork() 성능 향상 (특히 exec()로 금방 덮어쓸 경우)

“페이지 폴트가 다 같은 게 아니다.
문제는 메이저 폴트!
똑똑하게 아끼는 기술은 COW!”

🏃 페이지 폴트가 발생하면 어떤 일이 벌어질까?

아래는 페이지 폴트가 발생하고 처리되는 전체 흐름입니다:

✅ 전체 흐름 요약

1. 프로세스가 가상 주소에 접근함
2. TLB에서 확인 – 실패!
3. 페이지 테이블에서 확인 – 실패!
4. 페이지 폴트 예외 발생 (인터럽트)
5. 운영체제가 디스크에서 해당 페이지를 물리 메모리에 로드
6. 페이지 테이블 업데이트
7. 프로세스 재실행

🎨 그림으로 보면 더 쉬워요!

💥 페이지 폴트 실전 예시: 고의로 터트려보자

• 가상 주소에는 있지만 물리 메모리에 없는 경우, CPU는 페이지 폴트 예외를 발생시켜요.
• 커널은 이걸 감지하고 필요한 페이지를 디스크에서 RAM으로 불러오고 다시 실행시킵니다.

// segv.go
package main

import "fmt"

func main() {
    var p *int = nil
    fmt.Println("비정상 메모리 접근 전")
    *p = 8 // 💣 터진다!
    fmt.Println("비정상 메모리 접근 후")
}

• 이 코드를 실행하면 다음과 같은 메시지가 뜹니다:

panic: runtime error: invalid memory address or nil pointer dereference
SIGSEGV: segmentation violation

💡 실제 물리 메모리에도 존재하지 않는 주소에 접근했기 때문이에요!

이 프로그램을 실행하면 다음과 같이 panic: invalid memory address 메시지와 함께 프로세스가 종료됩니다.
이것이 바로 가상 메모리 보호기능이 제대로 작동했다는 증거입니다.

실행하면 SIGSEGV(세그멘테이션 폴트)가 발생하며 프로그램이 종료됩니다.

📊 페이지 폴트 실습에서 본 변화

앞서 사용한 demand-paging.py 예시처럼…

• mmap()으로 메모리 확보한 뒤에도
• 실제 접근하기 전까지는 물리 메모리 사용량이 변하지 않습니다
• 접근 시점마다 페이지 폴트가 발생하고, 그때서야 메모리에 로딩됩니다

💡 이게 바로 Demand Paging이에요! 실제 필요할 때만 물리 메모리 할당

• 모든 페이지를 미리 메모리에 올려놓는 선행 페이징과 달리, 필요한 순간에 메모리에 올리는 방식입니다.
• 프로세스가 접근하려는 페이지가 없으면 페이지 폴트 → 메모리에 로드 → 테이블 갱신 → 재시작 흐름이 발생합니다.

🧠 리눅스에서의 페이지 폴트 관리

리눅스는 다음과 같은 방식으로 페이지 폴트를 처리합니다:

단계	설명
1	페이지 폴트 예외 발생
2	커널의 page_fault_handler() 동작
3	해당 주소가 유효한 범위인지 검사
4	메모리 할당이 가능하면 페이지 테이블을 업데이트
5	가능하지 않으면 SIGSEGV 시그널 전송

🔍 분석 도구로 확인하기

ps -o min_flt,maj_flt -p <PID>

• 프로세스의 마이너/메이저 페이지 폴트 횟수 확인

vmstat

• 시스템 전체의 페이지 폴트 흐름 파악 가능

⚠️ 페이지 폴트는 많으면 안 좋은가?

그렇습니다!

• 초반에는 필요하지만, 지속적으로 발생한다면?
• → 메모리 부족, 메모리 설계 미숙, 캐시 미스 등의 문제가 있을 수 있어요

📌 예를 들어, Major Page Fault가 계속 발생하면 디스크 I/O가 빈번해지고 성능이 크게 저하될 수 있습니다.

페이지 폴트가 자주 일어난다면 어떻게 될까여
→ 처리 시간이 오래 걸린다. 

페이지 폴트를 방지하려면 어떻게 해야할까?
→ 앞으로 실행될 코드나 요청될 데이터를 포함한 페이지를 미리미리 메모리에 올립니다.
→ 완벽한 미래예측 = 신의 영역 

• 이러한 문제를 해결하기 위해서 다양한 페이지 교체 알고리즘이 있다. 

  출처: https://devraphy.tistory.com/246 [개발자를 향하여:티스토리]

✨ 정리: 페이지 폴트, 꼭 나쁜 것만은 아니지만…

항목	설명
Minor Page Fault	메모리는 있음, 주소 정보만 없음
Major Page Fault	디스크에서 읽어야 함
발생 시 처리	커널의 page fault handler가 물리 메모리에 올리고 페이지 테이블 갱신
SIGSEGV	메모리 공간이 아예 없으면 발생하는 시그널

페이지 폴트 핸들러의 페이지 테이블 엔트리 존재 여부에 따른 분기 처리 (스터디 후 보강)

페이지 폴트가 발생한 후 처리

운영체제는 이러한 페이지 폴트가 발생하면 해당 페이지를 물리 메모리에 올려주고 재실행을 하게합니다.

이러한 과정을 그림으로 살펴보면 아래와 같습니다.

출처 : https://velog.io/@hyun0310woo/11-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C-%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%AC

1. TLB에 물리 주소가 있을 경우

TLB에 물리 주소가 있다면 메모리에 있는 페이지 테이블에 가지 않고 바로 물리 주소에 해당하는 데이터를 확인 후에 전달하면 됩니다.

2. TLB에 물리 주소가 없을 경우

없을 경우에는 CR3 레지스터 값을 통해서 페이지 테이블에 접근하며 이때 페이지 테이블의 정보(valid - invalid bit값)을 확인해서 물리 주소에 대한 데이터가 있을 경우 전달해주면 됩니다.

3. 페이지 테이블에 물리 메모리 데이터가 없을 경우

페이지 테이블에도 물리 메모리 데이터가 없다면 페이지 폴트 인터럽트를 통해서 운영체제에게 알려줍니다. 그러면 운영체제는 해당 인터럽트를 처리하기 위해서 프로세스의 공간에서 페이지를 가져와 물리 메모리에 올려주게 되고 페이지 테이블을 업데이트하게 됩니다. 그리고 다시 CPU에게 가상 주소 요청을 하도록 합니다.

물론 이러한 페이지 폴드가 빈번하게 발생하면 실행 시간이 오래 걸립니다.

🔁 페이지 교체 정책 (Page Replacement)

✅ 물리 메모리가 꽉 찼다면?

• 새 페이지를 올려야 하는데 공간이 없다면 기존 페이지를 하나 제거해야 해요.
• 어떤 페이지를 제거할지는 교체 알고리즘에 따라 결정됩니다:

알고리즘	설명
FIFO	가장 먼저 들어온 페이지 제거
OPT	앞으로 가장 오래 안 쓸 페이지 제거 (이론상 최적이지만 구현 어려움)
LRU	가장 오래전에 사용한 페이지 제거
LFU	가장 적게 사용된 페이지 제거
NUR	최근 사용되지 않은 페이지 우선 제거 (R/M 비트 사용)

⚡ Thrashing (스레싱)

• 너무 많은 페이지 폴트와 교체 작업이 반복되면 CPU는 일만 하고 실제 일은 못 하게 됩니다.
• 시스템 성능이 급격히 떨어지는 현상으로, 스레싱 방지를 위해 페이지 수 조절이 필요해요.

📚 Segmentation (세그멘테이션)

• 페이징과 달리, 논리적인 의미 단위로 메모리를 나누는 기법이에요.
• 코드, 데이터, 스택 등으로 나눔 (크기 불균형 허용)

보통 페이징과 혼합해서 사용되기도 합니다.

🧾 마무리 한 줄 요약

가상 메모리는 리눅스 메모리 시스템의 마법 같은 기능입니다.
각 프로세스가 독립된 세계에 살게 하여, 충돌과 침범을 막고 효율적으로 메모리를 사용할 수 있게 해줘요!

🔄 리눅스에서의 메모리 접근 흐름 요약

1. CPU는 TLB(Translation Lookaside Buffer)를 먼저 확인합니다.
   → TLB에 매핑이 있으면 즉시 물리 주소로 접근 가능! ✅

2. TLB에 없다면? → 페이지 테이블을 조회합니다. 이때 CR3 레지스터(x86에서는 페이지 테이블의 루트 주소를 담고 있음)를 통해 시작합니다.

3. 페이지 테이블에서 해당 엔트리를 찾습니다.
   → Valid bit(유효 여부)를 확인하여, 물리 주소가 유효한지 판단합니다.

4. 만약 해당 가상 주소에 유효한 물리 주소가 없다면?
   → 페이지 폴트 예외(Page Fault Exception)가 발생합니다. 🚨

5. 커널의 페이지 폴트 핸들러가 동작하여 디스크(스왑 or 파일)에서 데이터를 물리 메모리에 로드하고, 페이지 테이블을 업데이트합니다.

🛠 5장: 메모리 할당의 놀라운 방법, mmap과 Demand Paging

📚 이야기로 풀어보는 메모리 할당

우리가 흔히 생각하는 메모리 할당 방식은 이래요:

1. 프로그램이 “XX 바이트 주세요!”라고 요청
2. 커널이 실제 물리 메모리에서 그만큼을 꺼내서 줌
3. 확보한 메모리 영역을 프로세스의 가상 주소 공간에 매핑
4. 가상 주소 공간의 시작 위치 주소를 프로세스에 돌려줌

하지만 리눅스는 이렇게 단순하게 동작하지 않습니다.

메모리는 확보한 순간 당장 사용하기보다는 조금 시간이 지난 후에 사용하는 일이 많아서 리눅스는 메모리를 확보하는 절차를 두 단계로 나눕니다.

1. 메모리 영역 할당: 가상 주소 공간에 새롭게 접근 가능한 메모리 영역을 매핑합니다.
2. 메모리 할당: 확보한 메모리 영역에 물리 메모리를 할당합니다.

리눅스는 대신, “일단 책장은 만들어 줄게. 진짜 책은 나중에 넣자!”라는 철학을 가집니다.
이걸 가능하게 해주는 것이 바로…

💾 mmap(): 책장을 만드는 시스템 콜(파일처리 성능 개선 기법이기도 한)

출처 : https://bannavi.tistory.com/80

mmap()은 프로세스가 새로운 메모리 공간이 필요할 때 사용하는 시스템 콜입니다.

추가로 설명하자면 mmap() 시스템 콜과 Go 언어의 map() 함수 인수는 조금 다릅니다. 예를 들어 시스템 콜은 요청하는 메모리 크기를 두 번째 인수로 지정하지만, Go 언어 함수는 세번째 인수로 지정합니다.

이 함수는 실제 물리 메모리를 바로 할당해주지 않고, 가상 주소 공간에 “비어 있는 영역”을 매핑해주는 역할을 해요.

📌 즉, 물리 메모리는 아직 없지만, “여기부터 여기까지는 네 거야!” 하고 표식만 해두는 겁니다.

이렇게 확보된 가상 메모리 공간은 /proc/<pid>/maps 파일을 통해 확인할 수 있습니다.
아직 물리 메모리는 0바이트도 할당되지 않았지만, mmap() 호출 이후 가상 메모리 공간은 증가한 것을 확인할 수 있어요.

양쪽 모두 수많은 인수가 있지만 여기서는 메모리 영역 크기를 지정하는 인수에만 주의하면 됩니다.

mmap의 3가지 핵심 속성 정리

출처 : https://keepat-it.tistory.com/39

1️⃣ 권한: "읽기/쓰기/실행"은 protection으로 설정한다!

mmap()은 메모리와 파일을 맵핑하는 함수입니다.
하지만 단순한 파일 입출력이 아니라 메모리 페이지 단위로 작동하므로, "접근 권한"도 메모리 방식으로 설정합니다.

🧷 mmap의 접근 권한 = Protection

권한 약어	의미	설명
PROT_READ	읽기	해당 메모리 영역을 읽을 수 있음
PROT_WRITE	쓰기	해당 메모리 영역에 쓸 수 있음
PROT_EXEC	실행	코드처럼 실행 가능 (코드 영역 매핑에 사용)
PROT_NONE	접근 금지	보호 목적, 아무 작업도 못함

파일의 rwx처럼 보이지만, mmap에서는 PROT_*으로 설정한다는 점이 다릅니다!

2️⃣ 가상 메모리: "스왑과 페이지 인/아웃의 관계"

리눅스는 가상 메모리를 기반으로 작동하기 때문에, mmap으로 확보된 메모리도 물리 메모리가 아닌 디스크(스왑 공간)으로 이동될 수 있어요.

🌀 스왑 동작 요약

용어	설명
Page Out / Swap Out	메모리 부족 시, 사용 중인 페이지를 디스크로 내보내기
Page In / Swap In	다시 필요해진 페이지를 디스크에서 메모리로 불러오기

이게 중요한 이유는:

• mmap된 메모리가 실제로 물리 메모리에서 사라질 수도 있다
• 다시 접근 시 페이지 폴트 발생 → 페이지 인 필요

즉, mmap도 스왑의 대상이 될 수 있다는 것, 단, 공유 mmap은 예외일 수 있음!

3️⃣ 공유 방식: Shared vs Private

mmap()은 메모리 매핑 방식을 공유(shared) 또는 사설(private) 중에서 선택할 수 있습니다.

📤 Shared (공유) mmap

• MAP_SHARED 옵션
• mmap과 원본 파일이 양방향 동기화됨
• 여러 프로세스가 동일한 mmap 영역을 공유 가능
• 스왑 아웃 대상이 아님 (원본 파일이 항상 디스크에 존재하므로)

예시:

mmap(..., MAP_SHARED)

프로세스 A에서 수정한 내용이 프로세스 B에도 그대로 반영됨
(단, 파일과의 싱크에는 약간의 시간차가 있을 수 있음)

🧍 Private (사설) mmap

• MAP_PRIVATE 옵션
• 처음에는 원본 파일 내용 복사, 이후는 독자적 메모리 사용
• 파일과 동기화 ❌ → 수정해도 파일에 반영되지 않음
• 변경된 페이지는 프로세스 고유 메모리로 전환되며, 스왑 아웃 대상이 됨

예시:

mmap(..., MAP_PRIVATE)

읽기 전용 참고용으로는 좋지만, 쓰기 성능이나 스왑 관리에는 주의 필요

💡 Tip: 사설 mmap을 스왑에서 제외하고 싶다면?

mlock(addr, length)

특정 메모리 영역을 고정시켜 페이징 아웃(스왑 아웃)을 방지할 수 있음

✅ 정리 표

항목	Shared mmap	Private mmap
동기화 여부	O (파일과 공유)	X (한 번만 복사)
다른 프로세스와 공유	O	X
파일 수정 반영	O	X
스왑 아웃 대상	❌ (디스크에 있음)	✅ (RAM에 있어야 함)
쓰기 시 동작	바로 반영	COW (복사 후 수정)

📌 요약 정리

구분	설명
Protection	PROT_READ, PROT_WRITE, PROT_EXEC 등으로 접근 권한 설정
가상 메모리 관계	필요 시 스왑 아웃/인 발생, 특히 Private mmap은 스왑 대상이 됨
공유 방식	MAP_SHARED는 파일과 공유, MAP_PRIVATE는 복사 후 독립 사용

💤 Demand Paging: 실제로 접근해야만 주는 메모리

mmap() 시스템 콜을 호출한 직후라면 새로운 메모리 영역에 대응하는 물리 메모리는 아직 존재하지 않습니다.

리눅스는 메모리 낭비를 막기 위해 진짜 메모리 할당을 “필요할 때만” 합니다.
이런 방식이 바로 Demand Paging입니다.

🎯 Demand Paging이란?

페이지 접근 후 메모리 확보 절차

1. 프로세스가 mmap()으로 메모리 공간을 요청하면
   → 가상 주소만 확보됨 (물리 메모리는 없음)

2. 이 주소에 실제로 접근하려고 하면
   → 페이지 폴트 예외(Page Fault Exception) 발생
   

3. 커널이 물리 메모리를 할당하고
   → 페이지 테이블을 갱신

• 이후 메모리 접근 정상 처리!

📖 비유하자면?
“빈 책장을 만들어두고, 독자가 실제로 책을 꺼내려 할 때 그 책을 꽂는 것”

Demand Paging 좀 더 자세히 알아보기

페이지 폴트 핸들러는 페이지 테이블 엔트리가 존재하지 않을 시, 프로세스에 SIGSEGV 시그널을 보내지만, 페이지 테이블 엔트리는 존재하되 물리 메모리가 할당되지 않은 경우에는 새로운 메모리를 할당하는 처리로 분기합니다.

리눅스에서 페이지 폴트가 발생했을 때, 커널의 페이지 폴트 핸들러(page_fault_handler)는 다음과 같은 분기 처리를 합니다:

1) 페이지 테이블에 엔트리가 없으면?

• 이 가상 주소가 정상적인 주소 범위가 아니거나,
  해당 주소에 대해 메모리를 할당할 이유가 없다면
  👉 운영체제는 SIGSEGV (Segmentation Fault) 시그널을 해당 프로세스에 보냅니다.
• 이는 프로그램이 허용되지 않은 주소를 접근한 것이므로,
  대부분의 경우 프로그램은 강제 종료됩니다.

예: nil 포인터 역참조, 해제된 메모리 접근, 스택/힙 영역을 넘은 접근 등

2) 페이지 테이블 엔트리는 있으나, 물리 메모리가 할당되지 않은 경우?

• 이는 mmap() 등으로 가상 메모리 공간을 확보해두었지만, 아직 실제 메모리에 대응된 페이지가 없는 상태입니다.
• 이 경우 커널은 “아, 접근했으니 이제 물리 메모리 할당해줘야겠다!” 하고
  👉 Demand Paging 처리를 합니다.
• 물리 메모리에서 페이지를 할당하고, 해당 가상 주소와 연결해주는 페이지 테이블을 업데이트합니다.
• 이후, 인터럽트가 발생했던 명령어를 다시 실행시킵니다.

✅ 이건 오류가 아니라 정상적인 메모리 요청 흐름의 일부입니다!

✅ 요약 정리

상황	처리 방식	결과
페이지 테이블 엔트리 없음	SIGSEGV 시그널 전송	프로세스 강제 종료
페이지 테이블은 있지만 물리 메모리 없음	Demand Paging 수행	물리 메모리 할당 후 재실행

📌 관련 키워드 정리

용어	설명
SIGSEGV	잘못된 메모리 접근 시 운영체제가 프로세스에 보내는 시그널
Demand Paging	메모리 접근 시점에 실제 물리 메모리를 동적으로 할당하는 기법
페이지 테이블	가상 주소와 물리 주소의 매핑 정보를 담는 구조
페이지 폴트 핸들러	페이지 폴트가 발생했을 때 커널에서 실행되는 처리 루틴

• "접근 시 → TLB 미스 → 페이지 테이블 체크 → 존재 여부 판단 → Demand Paging or SIGSEGV"

🧪 실험으로 보는 mmap과 Demand Paging

✔️ Go로 보는 예시 (mmap.go)

코드 프로세스
1. 프로세스의 메모리 매핑 정보(/proc/<pid>/maps 출력)를 표시합니다.
2. mmap() 시스템 콜로 1GiB 메모리를 요청합니다.
3. 다시 메모리 매핑 정보를 표시합니다.

결과
1. mmap() 호출 → 0x7fd00aa94000 - 0x7fcfcaa94000 = 1GiB 메모리 공간 확보
2. /proc/<pid>/maps로 확인하면, 가상 메모리 공간은 늘었지만
물리 메모리는 아직 할당되지 않음!

주소를 뺀 값이 1GiB라는 점이 중요합니다.

✔️ Python으로 보는 예시 (demand-paging.py)

1. mmap()으로 100MiB 확보
2. 한 페이지씩 메모리에 접근 → 페이지 폴트 발생
3. 그때마다 물리 메모리 하나씩 할당
4. ps, sar -r, sar -B 등으로
   메모리 사용량, 페이지 폴트 횟수 확인 가능!

📊 실험 결과 한눈에 보기

시점	가상 메모리	물리 메모리	페이지 폴트
mmap() 직후	증가함	그대로	없음
메모리 접근 중	그대로	점점 증가	초당 수천 회
접근 완료 후	그대로	100MiB 증가	고정됨
프로세스 종료	사라짐	회수됨	0

✅ 즉, 실제로 메모리를 사용할 때만 할당되고,
페이지 폴트를 통해 커널이 즉석에서 처리해주는 방식입니다.

📦 프로그래밍 언어는 어떻게 사용할까?

파이썬, Go, C 같은 언어들도 내부적으로 비슷한 전략을 사용합니다.

• 매번 mmap()을 호출하지 않고,
• 처음 실행 시 큰 메모리 공간을 확보한 뒤
• 그 공간에서 필요한 만큼 잘라 씁니다

📌 이건 malloc(), new, 리스트 생성 등에서도 확인할 수 있어요.

✨ 요약 정리

개념	설명
mmap()	가상 주소 공간만 확보하는 시스템 콜
Demand Paging	메모리에 실제 접근할 때 물리 메모리 할당
페이지 폴트	접근 시 물리 메모리가 없으면 발생하는 예외
물리 메모리 할당 시점	페이지 폴트 발생 후
이점	메모리 낭비 방지, 성능 최적화

🧠 “페이지 폴트가 언제, 어떻게 일어나는지 직접 확인해보자!”

우리가 지금 알아보고 싶은 건 한 가지예요.

“가상 메모리는 처음에 그냥 주소만 할당해주고, 실제 물리 메모리는 언제 주는 걸까?”

답은 바로 접근할 때! 입니다. 이걸 "Demand Paging"이라고 하죠.
이번 실험은 바로 그 Demand Paging이 실제로 어떻게 동작하는지를 몸소 확인하는 실험이에요.

🧪 Step 1. 새로운 메모리 영역 확보 (하지만 아직은 비어 있음)

실험은 Python 코드(demand-paging.py)로 진행됩니다.

memregion = mmap.mmap(-1, ALLOC_SIZE, flags=mmap.MAP_PRIVATE)

• mmap() 시스템 콜로 100MiB의 가상 메모리 영역을 확보합니다.
• 이때! 실제 물리 메모리는 아직 아무것도 할당되지 않았어요.
• 그저 “이 주소부터 이만큼 쓸 수 있게만 해줘~” 한 것뿐입니다.

📦 아직 책장을 조립해놓기만 했고, 책은 한 권도 안 꽂혀 있는 상태죠.

🧪 Step 2. 접근을 시작하자! → 페이지 폴트 발생

for i in range(0, ALLOC_SIZE, PAGE_SIZE):
    memregion[i] = 8  # 각 페이지에 첫 바이트 접근

이제 메모리 영역의 각 페이지에 1바이트씩 접근합니다.
이 순간! Demand Paging이 시작돼요.

• 페이지에 처음 접근하면 운영체제가 “이 주소엔 아직 물리 메모리가 없어!”를 감지하고,
• ➡ 페이지 폴트가 발생!
• ➡ 운영체제가 실제 물리 메모리 페이지를 할당해줍니다.
• ➡ 페이지 테이블을 업데이트하고, 방금 중단됐던 명령어를 다시 실행합니다.

✨ “필요할 때만 책을 꺼내 꽂는 방식” — 이게 바로 Demand Paging입니다!

🧪 Step 3. sar 명령어로 시스템 상태를 관찰해보자

실행 중 sar -r 1, sar -B 1 명령어를 병렬로 실행하면 다음을 확인할 수 있어요:

🖥️ 메모리 사용량 (sar -r 1)

• 메모리 영역만 확보한 직후엔 메모리 사용량 거의 변화 없음
• 실제로 접근을 시작한 이후부터 초당 약 10MiB씩 물리 메모리 사용량이 증가
• 프로그램이 종료되면 메모리 사용량도 원래대로 돌아감

🔍 페이지 폴트 발생 (sar -B 1)

• 접근이 시작된 순간부터 fault/s(초당 페이지 폴트 수) 수천 단위로 급증
• 페이지 폴트는 접근한 만큼만 발생 (100MiB → 약 25,000개 페이지 접근 = 그만큼 폴트 발생)

이건 바로 물리 메모리가 필요한 순간에만 할당되기 때문이에요!

📊 capture.sh로 프로세스 상태 실시간 모니터링

이제 특정 프로세스(demand-paging.py)의 상태를 1초 간격으로 살펴보는 스크립트를 실행해볼 수 있어요:

./capture.sh

출력되는 주요 지표는 다음과 같아요:

항목	의미
VSZ	가상 메모리 크기
RSS	실제로 할당된 물리 메모리 크기
maj_flt	메이저 페이지 폴트 횟수
min_flt	마이너 페이지 폴트 횟수

📈 실행 중 확인된 변화

• 가상 메모리(VSZ)는 미리 할당되었기 때문에 처음부터 100MiB 수준
• 하지만 실제 물리 메모리(RSS)는 페이지에 접근할 때마다 점점 증가
• 페이지 폴트(min_flt)는 각 페이지마다 발생하며 점점 누적됨

마치, 책장에 매번 책 한 권씩 꽂을 때마다 알람이 울리는 거예요. "책 왔다!" 📦

🧠 정리 요약

단계	설명	메모리 변화
mmap() 호출	가상 주소 공간만 확보 (물리 메모리 없음)	VSZ 증가, RSS 변화 없음
각 페이지 접근 시작	페이지 폴트 발생 → 물리 메모리 동적 할당	RSS 증가, fault/s 증가
접근 완료	모든 페이지에 물리 메모리 할당 완료	RSS = VSZ
프로그램 종료	모든 메모리 해제	VSZ, RSS 모두 감소

💡 마무리 한 줄 요약

“Demand Paging은 미리 메모리를 주지 않지만, 필요한 순간엔 정확히 필요한 만큼만, 스마트하게 준다!”

📌 운영체제의 메모리 효율 전략이란 이런 것이다!

📗 "페이지 테이블은 얼마나 메모리를 쓸까?"와 계층형 테이블 구조

🧠 "페이지 테이블은 얼마나 메모리를 쓸까?"

가상 주소 공간이 어마어마하게 넓은데, 그걸 전부 관리하려면 페이지 테이블도 엄청 커야 하지 않을까?

📘 페이지 테이블은 뭐냐면요...

"컴퓨터의 주소록"이에요!
우리 집 주소는 “서울시 00구 123-45번지” 같은 가상 주소잖아요? 그런데 실제로 물건은 창고 안 칸칸마다 들어 있어요.
이때 "가상 주소 → 실제 주소(창고칸)"을 알려주는 게 바로 페이지 테이블이에요!

✅ 즉, 페이지 테이블 = 주소 변환 표

1️⃣ 단순 계산: 진짜 그렇게 큰가?

📊 그런데 페이지 테이블이 왜 이렇게 크다고 하는 걸까요?

🔍 가정: x86_64 아키텍처

• 가상 주소 공간: 128TB
• 페이지 크기: 4KB (4,096바이트)
• 한 페이지를 찾기 위해 필요한 정보(엔트리): 8바이트

그럼 얼마나 많은 페이지가 필요하냐면...

128TB ÷ 4KB = 약 34,359,738,368개! (약 340억 개 페이지)
거기다 각 페이지마다 8바이트 정보가 필요하니...

340억 개 × 8바이트 = 256GB

😱 페이지 테이블만 256GB나 필요하다는 말이 되는 거예요!
근데... 내 컴퓨터 RAM은 16GB밖에 안 되는데?!?

🤔 “헉, 그럼 우리 컴퓨터는 멀쩡히 돌아가는 거 맞아?”
맞아요. 왜냐하면...

2️⃣ 진짜 핵심! “계층형 구조라서 괜찮아요”

여기서 비밀 무기 등장! 바로 계층형 페이지 테이블 구조예요.
이건 “필요한 것만 꺼내 쓰는” 방식이에요.

🌲 계층형 페이지 테이블은 이렇게 동작해요:

1. 📚 1단계: "책장 큰 분류" (예: 영어책, 과학책, 만화책...)
2. 📘 2단계: "해당 분류의 실제 책 목록"
3. 📄 3단계: "책의 실제 내용 페이지"

만약 만화책만 본다면, 과학책 목록이나 내용은 아예 만들지도 않아요!

즉,

• 우리가 실제 사용하는 가상 주소 범위만큼만!
• 필요한 테이블 일부만 메모리에 생성해요!

그래서 실제로는 전체 256GB가 필요하지 않아요.

페이지 테이블은 실제로 나무처럼 계층 구조(Tree-like structure)로 되어 있어요.

✅ 단일 구조 vs 계층 구조 비교

• 평탄한 테이블(flat): 전체 공간을 한눈에 다 관리
  • 공간 낭비 심해요.
• 계층 구조(hierarchical): 필요한 부분만 만들고 관리
  • 공간 아껴서 현실적으로 운영 가능해요.

🧩 예시 (페이지 크기 100바이트, 가상 주소 공간 1600바이트):

• 평탄한 구조: 전체 페이지 엔트리 16개 필요
• 2단 계층형: 실제 사용하는 페이지만 테이블에 포함 → 엔트리 수 8개로 감소!

구조	설명	메모리 낭비 여부
평탄형 (1차원)	모든 페이지에 대해 무조건 엔트리 생성	있음 😭
계층형 (트리 구조)	필요한 페이지만 점차 구조 생성	없음 😊

3️⃣ 현실: x86_64는 4단계 계층형 페이지 테이블 🪜

• 시스템에 따라 다르지만, 리눅스 x86_64는 일반적으로 4단계 구조를 사용해요:
  • PML4 → PDPT → PD → PT → 실제 페이지

👉 그래서 프로세스 하나가 256GB를 차지하지 않고도, 메모리를 효율적으로 관리할 수 있는 거예요!

sar - ALL 명령

시스템이 사용하는 물리 메모리 중에서 페이지 테이블이 사용하는 메모리는 sar - ALL 명령어로 kbpgtbl 필드에서 확인할 수 있습니다

🏁 정리 한줄 요약!

“페이지 테이블은 처음 보면 너무 커 보여도, 실제로는 ‘필요한 만큼만’ 만들어서 똑똑하게 메모리를 아껴요!”

🧱 Huge Page와 Transparent Huge Page (THP)

메모리 관리 효율을 한 단계 더 끌어올리기 위한 기술이에요.

이걸 1페이지당 크기가 400바이트인 Huge Page로 바꾸면 페이지 테이블 계층을 1단은 건너뛰고 [그림 04-24]처럼 됩니다.

4️⃣ Huge Page: "페이지를 크게 써서 엔트리 줄이자!"

기본 페이지는 4KiB지만, Huge Page는 보통 2MiB~1GiB

✅ 장점

• 페이지 테이블의 엔트리 수가 확 줄어듦
• 페이지 테이블 복사 비용도 줄어서 fork() 속도 향상!

💻 사용 방법

mmap(..., MAP_HUGETLB);  // 명시적으로 Huge Page 요청

대용량 데이터 처리하는 DB, 가상머신 등에 좋음

5️⃣ Transparent Huge Page (THP): “자동으로 알아서 써줄게!”

프로그래머가 명시하지 않아도, OS가 알아서 4KiB 페이지들을 묶어서 Huge Page로 만들어줍니다.

✅ 장점

• 성능 향상 기대
• 프로그래머가 직접 Huge Page 설정 안 해도 됨

⚠️ 주의점

• 조건이 맞아야 합쳐짐
• 다시 4KiB로 쪼개는 비용도 있어서 성능이 오히려 낮아질 수도 있음

🛠 설정 확인 및 변경

cat /sys/kernel/mm/transparent_hugepage/enabled
# 출력 예시: always [madvise] never

• always : 항상 THP 사용
• madvise : madvise() 시스템콜로 요청한 경우만 사용 (Ubuntu 20.04 기본값)
• never : THP 비활성화

🧠 정리 요약

개념	설명	장점	주의점
평탄한 페이지 테이블	전 범위를 일괄 관리	구조 간단	메모리 낭비 큼
계층형 페이지 테이블	필요한 범위만 계층적으로 구성	메모리 효율적	구조 복잡
Huge Page	페이지 단위 자체를 키움 (ex. 2MiB)	페이지 테이블 작아짐	명시적 설정 필요
Transparent Huge Page	연속된 페이지를 OS가 자동으로 묶음	자동 최적화	오히려 느려질 수도 있음

보충 정리 : 새로운 메모리 계층과 운영체제의 역할

출처 : https://medium.com/rate-labs/%EC%83%88%EB%A1%9C%EC%9A%B4-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B3%84%EC%B8%B5%EA%B3%BC-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EC%9D%98-%EC%97%AD%ED%95%A0-92109ebea01a

📚 "DRAM이 부족한 세상, 계층형 메모리가 나타났다!"

1️⃣ DRAM의 성장 둔화와 새로운 시대의 도래

옛날에는 DRAM이 무서운 속도로 성장했어요.

• 초창기엔 3년에 4배씩! 🚀
• 그다음엔 2년에 2배씩!
• 그런데 최근엔... 4년에 겨우 2배.

한마디로 "DRAM 성장이 예전 같지 않다..."는 거죠.
하지만 세상은 점점 더 많은 데이터를 원해요.

• 글에서 → 사진에서 → 영상으로
• 그리고 요즘은 AI가 데이터를 폭식 중이에요.

“DRAM만으로는 도저히 감당할 수 없다!”

그래서 연구자들은 대안을 찾아 나섰습니다.

2️⃣ 대안: 새로운 메모리 기술의 등장!

DRAM을 보완하거나 대체할 방법들, 바로 이것들이에요:

• 🔁 Persistent Memory (PM)
• 🔌 Non-volatile Memory (NVM)
• 🌪️ Storage Class Memory (SCM)

그리고 그 안에는 또 멋진 기술들이 숨어 있어요:

• PCM, FeRAM, STT-RAM 같은 신소재 기반 메모리들
• 그리고 인텔의 Optane 같은 실제 상용 제품도 나왔죠.

또 하나, Disaggregated Memory란 개념도 나왔어요.
→ 여러 서버의 DRAM을 합쳐 하나의 거대한 메모리처럼 쓰는 거예요!

🚍 최근엔 CXL(Compute Express Link)이라는 고속 통신 기술 덕분에,
CPU가 원격 메모리에 마치 내 것처럼 빠르게 접근할 수 있게 됐습니다.

3️⃣ 현실적인 전략: 계층형 메모리 시스템 등장!

그렇다고 "DRAM이 없어도 된다"는 건 아니에요.
오히려 DRAM을 캐시처럼 사용해서
속도와 용량 사이에서 절묘한 균형을 찾자! 이게 핵심입니다.

그래서 만들어진 구조가 바로 이거예요:

CPU 가까이: 빠르지만 비싼 메모리 (L1/L2 캐시, DRAM)
CPU 멀리: 느리지만 큰 메모리 (SCM, SSD 등)

🎯 목표는 단 하나!
"핫한 데이터는 위쪽에서, 콜드한 데이터는 아래쪽에서 처리하자!"

4️⃣ 문제 1: “어떤 데이터를 남기고, 어떤 걸 버릴까?” (페이지 교체 알고리즘)

계층 구조에서 가장 중요한 건
➡ 무슨 데이터를 DRAM에 두고, SCM으로 내릴지 결정하는 것이에요.

🔍 판단 기준은 두 가지:
1. 얼마나 자주 접근했는가 (빈도) → LFU
2. 마지막 접근이 얼마나 최근인가 (최신성) → LRU

현실에선 이 둘을 적절히 섞어서 판단해요.

그런데! 운영체제는 모든 데이터 접근을 완벽히 알 수가 없어요.

🛑 기존 방식의 한계:

• PTE 접근 비트는 정확하지 않음 (TLB 덕분에 생략되기도 함)
• 의도적 페이지 폴트는 성능에 악영향 😭

✅ 최근 해결책: Intel의 PEBS 활용!

• CPU 내부 이벤트를 샘플링해서
• 어떤 주소가 실제로 접근됐는지 확인 가능!
• 성능 부담도 적고, TLB 접근도 빠짐없이 기록됨!

5️⃣ 문제 2: “공간을 너무 낭비하고 있진 않을까?” (공간 효율성 문제)

Huge page 로 인한 비효율적인 공간 활용

🧱 Huge Page가 왜 쓰일까?

• 4KB 페이지 512개 → 2MB Huge Page
• TLB 커버리지가 커지고, 페이지 테이블도 줄어요!

😨 그런데 문제가...

• 2MB 중에 딱 4KB만 쓰면?
• 나머지 1.996MB는 낭비! → 메모리 부풀림(bloat) 발생!

🔄 해결책: 필요하면 다시 쪼개기!

• Huge Page를 4KB base page로 분해해서,
  진짜 ‘핫한’ 페이지만 DRAM에 넣자!

하지만 이것도 쉽지 않아요:

• 다시 huge로 합쳐야 할 수도 있음
• 쪼개고 합치는 데 시간과 비용 발생

그래서 연구자들은 적당한 타이밍과 기준을 찾아내려는 알고리즘도 연구 중이에요.
예: Memtis(2023)은 내부 단편화 수준을 보고 쪼개는 기준을 제안했어요!

🔚 결론: 계층 메모리 시스템, 아직 갈 길이 멀지만 가능성은 크다!

• DRAM은 더 이상 무한히 커지지 않아요.
• 그래서 새로운 메모리 계층, 페이지 교체, 공간 관리 등이 필요해졌고
• 이를 해결하기 위한 기술과 아이디어들이 쏟아지고 있어요.

“10년 후에는, 우리가 쓰는 메모리 구조가 지금과 완전히 달라질지도 몰라요!”

🎉 자, 이제 정리해볼까요?

이렇게 리눅스가 메모리를 어떻게 똑똑하게 관리하고, 메모리가 부족할 때 어떤 행동을 하는지 알아봤어요. 실제로 컴퓨터를 쓰면서 가끔 free 명령어나 sar 명령어로 메모리를 관찰해보세요. 리눅스의 똑똑한 메모리 관리 시스템을 직접 느낄 수 있을 거예요~

논의 나눈 부분

• THP 내용

• 블루스크린도 page fault의 일종 > os단에서 페이지폴트나면 블루스크린

• OOM 점수 보기 : cat /proc/[PID]/oom_score_adj

• DB가 프로세스니 리눅스를 따라간다.
  🧠 “DB가 프로세스니 리눅스를 따라간다”는 뜻은?

  1) 데이터베이스(DB)는 결국 프로세스이다

• 우리가 사용하는 MySQL, PostgreSQL, Oracle 같은 데이터베이스는 독립 실행되는 프로그램, 즉 프로세스예요.

• 이 DB 프로그램도 운영체제에서 관리하는 하나의 사용자 프로세스로 실행됩니다.

예: ps -ef | grep postgres
postgres  10123     1  0 10:00 ?        00:00:00 /usr/lib/postgresql/...

🔧 2) 리눅스가 관리하는 것들을 DB도 똑같이 겪는다

운영체제는 모든 프로세스를 관리하죠. 그러니까 DB도 다음과 같은 리눅스의 제약과 규칙을 그대로 따릅니다.

1) 페이지 폴트가 나면 커널이介入해서 메모리 올려주기
2) 가상 주소 공간 사용 (DB도 mmap을 써서 파일 매핑함)
3) 스케줄링 대상 (CPU 시간 분배받아야 함)
4) I/O 요청 시 커널을 통해 디스크에 접근
5) SIGKILL, SIGTERM 등 시그널도 DB에 적용됨

→ 요약하면, DB도 일반적인 리눅스 프로세스처럼 가상 메모리, 페이지 폴트, TLB 미스 등 다 겪는다는 말입니다.

🟢 PostgreSQL에서의 메모리 접근 예시

1) 사용자가 SELECT * FROM users WHERE id=1 같은 쿼리를 날림
2) PostgreSQL이 users 테이블 파일을 열고 mmap으로 매핑
3) 만약 아직 그 파일이 물리 메모리에 없으면?
→ 페이지 폴트 발생!
4) 리눅스 커널이 해당 페이지를 디스크에서 읽어와서 메모리에 적재
5) 이후 사용자 요청에 따라 결과를 반환

즉, PostgreSQL이 직접 디스크에서 읽는 게 아니라, 커널의 페이지 폴트 핸들링에 의존하는 구조입니다.

데이터베이스도 결국 리눅스 프로세스이므로, 가상 메모리와 페이지 폴트, TLB, 시그널 등 리눅스 커널의 모든 메커니즘을 그대로 따릅니다.

📚 덧붙여서 읽으면 좋은 내용

• mmap을 이용한 파일 매핑 (PostgreSQL에서 많이 씁니다)
• Demand Paging + Page Fault 핸들링
• DB가 직접 버퍼를 관리하는 이유 (OS 캐시만 믿을 수 없기 때문에)

읽어보면 좋을 자료(스터디 후 보강)

• 쿠버네티스가 쉬워지는 컨테이너 이야기 — memory편
• LINUX 메모리 부족과 oom_killer 문제에 대한 이해와 대응
• 스터디원 자료
• DBA와 개발자가 모두 행복해지는 Hibernate의 in_clause_parameter_padding 옵션
• HikariCP 깃허브 REPO
• Spring WebClient에서 새어나가는 메모리 잡기