304. 스래싱 (Thrashing)

핵심 인사이트 (3줄 요약)

본질: 스래싱 (Thrashing)은 물리 메모리가 부족하여 프로세스들이 실제 연산을 수행하는 시간보다 페이지를 디스크와 램 사이로 퍼 나르는(Page-in/Out) 시간이 더 많아져 시스템 전체 성능이 급격히 붕괴되는 현상이다.

가치: CPU 이용률이 바닥을 치는 역설적인 상황을 통해, 멀티프로그래밍의 정도(DoM)를 무작정 높이는 것이 정답이 아니며 각 프로세스에 최소한의 **워킹 셋(Working Set)**을 보장해야 함을 증명하는 강력한 경고 지표다.

융합: OS는 이를 방지하기 위해 CPU 이용률 하락을 감지하여 일부 프로세스를 강제로 중단(Suspend)시키거나, 페이지 부재 빈도(PFF)를 기반으로 프레임 할당량을 동적으로 조절하는 제어 메커니즘을 가동한다.

Ⅰ. 개요 및 필요성

개념: 가상 메모리 시스템에서 너무 많은 프로세스가 동시에 실행될 때, 각 프로세스가 원활히 작동하기 위해 필요한 최소한의 물리 메모리(프레임)를 확보하지 못해 페이지 폴트가 무한 반복되는 상태다.
필요성: 현대 컴퓨터는 수백 개의 앱을 동시에 돌리려 한다. 하지만 무제한적인 동시 실행은 어느 임계점을 넘는 순간 시스템을 먹통으로 만든다. 스래싱은 이 **"과유불급"**의 지점을 정확히 인지하게 하여, 하드웨어 증설(RAM)의 필요성과 OS 스케줄링 정책(Swap-out)의 정당성을 부여한다.
💡 비유: 좁은 주방(RAM)에 요리사(프로세스)를 100명 집어넣었습니다. 요리사들은 요리(연산)를 하는 게 아니라, 재료(페이지)를 찾으러 냉장고(디스크)에 가려고 서로 길을 막고 부딪히느라 주방 전체가 아수라장이 되어 요리가 한 접시도 안 나오는 상황과 같습니다.
등장 배경: 1960년대 시분할 시스템이 대중화되면서, "컴퓨터가 왜 이렇게 버벅대지?"라는 질문에 대한 답으로 연구되었다. CPU 점유율은 낮은데 하드디스크 불빛만 계속 깜빡이는 기이한 현상의 실체가 바로 스래싱임이 밝혀졌다.

┌──────────────────────────────────────────────────────────────┐
│             스래싱(Thrashing)의 발생 메커니즘 및 그래프               │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  CPU 이용률                                                   │
│   ▲          최적 DoM 지점                                     │
│   │           /                                              │
│   │         / \      <--- 이 지점부터 스래싱 발생!                │
│   │        /   \                                             │
│   │      /      \                                            │
│   │    /         \____________________                       │
│   └───────────────────────────────────▶ DoM (멀티프로그래밍 정도) │
│                                                              │
│  * 원인: 프로세스 증가 -> 프레임 부족 -> 폴트 급증 -> I/O 대기 증가  │
│  * 결과: CPU는 놀고 디스크만 혹사당함.                            │
└──────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 넷플릭스를 100개 동시에 틀어놓은 꼴입니다. 드라마 내용은 하나도 안 나오고 하루 종일 '로딩 중' 동그라미만 뱅글뱅글 돌아가며 인터넷 회선(디스크 I/O)만 불타오르는 상태입니다.

Ⅱ. 아키텍처 및 핵심 원리

죽음의 소용돌이 (Death Spiral) 과정

DoM 증가: 더 많은 프로세스를 띄운다.
프레임 고갈: 각 프로세스에게 돌아가는 램 조각(프레임)이 줄어든다.
페이지 폴트 폭발: 조금만 연산해도 필요한 데이터가 램에 없으니 폴트가 터진다.
I/O 병목: 모든 프로세스가 디스크를 기다리느라 대기(Blocked) 상태로 들어간다.
CPU 유휴: 실행할 프로세스가 없으니 CPU 이용률이 뚝 떨어진다.
OS의 착각: "어? CPU가 노네? 일이 없나 보네? 프로세스 더 띄우자!"라고 판단하여 새로운 프로세스를 투입한다. (대참사)

방어 기법: 워킹 셋 (Working Set) 모델

스래싱을 막는 가장 근본적인 해법이다.

각 프로세스가 특정 시간 동안 빈번하게 참조하는 페이지들의 집합인 **'워킹 셋'**을 정의한다.
OS는 이 워킹 셋 전체를 램에 올릴 수 있을 때만 프로세스를 실행시킨다.
만약 램이 모자라 워킹 셋 하나도 못 올릴 지경이면, 차라리 프로세스 하나를 통째로 포기(Swap-out)하여 남은 프로세스들에게 숨 쉴 구멍을 만들어준다.
📢 섹션 요약 비유: 전교생 1,000명을 억지로 급식실에 밀어 넣는 게 아니라, 식탁 의자 수(RAM)에 맞춰서 100명씩 끊어서 입장(Working Set 보장)시키는 질서 정연한 배급 시스템입니다.

Ⅲ. 비교 및 연결

스래싱 vs 데드락 (Deadlock)

비교 항목	스래싱 (Thrashing)	데드락 (Deadlock)
본질	자원(RAM)의 양적 부족 및 관리 실패	자원(Lock)의 순환 대기로 인한 꼬임
CPU 상태	놀고 있음 (I/O 대기로 인한 유휴)	멈춰 있음 (점유 대기로 인한 정지)
시스템 반응	극도로 느려짐 (버벅임)	완전히 정지됨 (프리징)
해결책	램 증설, DoM 감소	락 해제, 자원 선점, 회피

스래싱과 지역성 (Locality)

프로그램이 강한 지역성을 띠고 있다면, 작은 프레임으로도 스래싱 없이 잘 돌아간다. 하지만 프로그램이 램 전체를 무작위로 찌르는(Random Access) 성격이라면, 램이 아무리 많아도 DoM이 조금만 올라가면 즉시 스래싱의 지옥에 빠지게 된다.

📢 섹션 요약 비유: 스래싱은 '체증'입니다. 차는 많은데 도로가 좁아 못 가는 것이죠. 데드락은 '사고'입니다. 사거리에서 서로 꼬여서 아무도 못 움직이는 것입니다.

Ⅳ. 실무 적용 및 기술사 판단

실무 시나리오

클라우드 서버의 급격한 성능 저하 원인 분석
- 상황: 평소 잘 돌아가던 웹 서버가 트래픽이 몰리자 갑자기 응답 속도가 10초 이상으로 늘어남.
- 진단: 서버 로그를 보니 CPU 사용량은 10%인데, 메모리 사용량은 95%이고 Swap-in/Out 트래픽이 평소의 100배임.
- 결정: 전형적인 스래싱이다. 웹 워커(Process) 개수를 너무 많이 늘려놓아 각 워커의 워킹 셋이 깨진 것이다.
- 조치: 즉시 동시 접속자 수 제한(Throttle)을 걸어 DoM을 낮추고, 램 용량을 스케일-업(Scale-up) 해야 한다.
Android App의 백그라운드 킬 (OOM Killer) 안드로이드 폰에서 여러 게임을 번갈아 실행할 때, 예전에 하던 게임이 꺼지는 이유가 바로 스래싱 방지다. 안드로이드 OS는 스래싱 조짐이 보이면(LVM 임계치 도달), 가장 덜 중요한 백그라운드 앱을 강제로 죽여버림으로써 현재 사용하는 앱의 워킹 셋을 사수한다.

도입 체크리스트

성능 모니터링: iostat, vmstat을 통해 iowait과 swap 수치를 실시간 감시하고 있는가?
PFF 제어: 페이지 부재 빈도(Page Fault Frequency)가 상한선을 넘으면 프레임을 더 주고, 하한선 아래면 프레임을 회수하는 동적 할당 정책이 적용되어 있는가?
📢 섹션 요약 비유: 주식 단타 매매(스래싱)를 너무 많이 하면 수수료(I/O 비용) 때문에 원금이 다 녹아버립니다. 차라리 몇 종목에 집중 투자(Working Set)하고 가만히 있는 것이 수익률(성능)에 훨씬 좋습니다.

Ⅴ. 기대효과 및 결론

정량적 기대효과

적정 DoM 유지: 스래싱 분석을 통해 우리 서버가 견딜 수 있는 최대 프로세스 수의 한계(Sweet Spot)를 찾아내어 서비스 가용성을 극대화할 수 있다.
인프라 투자 가이드: 무의미한 CPU 업그레이드 대신, 진짜 병목인 RAM 증설에 비용을 투입하게 유도하여 IT 비용 효율을 높인다.

결론

스래싱은 컴퓨터가 우리에게 보내는 **"나 너무 힘들어, 짐 좀 덜어줘"**라는 눈물겨운 SOS 신호다. CPU 이용률이 낮다는 이유로 프로세스를 더 투입하는 것은 굶주린 사람에게 일을 더 시키는 것과 같다. 현대 아키텍트는 스래싱의 원리인 '워킹 셋'의 보존을 최우선 가치로 삼아, 시스템이 '로딩'만 하다가 끝나는 무의미한 소용돌이에 빠지지 않도록 철저히 관리해야 한다.

📢 섹션 요약 비유: 훌륭한 리더는 팀원들이 바빠 보인다고 무조건 신입을 뽑지 않습니다. 사무실이 좁으면(RAM 부족) 신입이 들어와도 오히려 서로 방해만 될 뿐입니다. 먼저 사무실을 넓히거나(램 증설), 하던 일부터 끝내게(DoM 감소) 하는 것이 정답입니다.

📌 관련 개념 맵

개념 명칭	관계 및 시너지 설명
워킹 셋	스래싱을 방어하기 위해 프로세스에게 보장해야 할 최소한의 페이지 집합.
DoM	멀티프로그래밍 정도. 이 수치가 임계점을 넘으면 스래싱이 터짐.
PFF	페이지 폴트 빈도. 이 수치를 보고 프레임 할당량을 조절하여 스래싱을 예방.
Page-in/Out	스래싱 발생 시 CPU 연산 대신 수행되는 무거운 디스크 작업.
Locality	지역성이 높을수록 워킹 셋 크기가 작아져 스래싱에 강해짐.

👶 어린이를 위한 3줄 비유 설명

스래싱은 책상이 너무 좁아서 공부할 책 한 권도 다 못 펼쳐놓는 상황이에요.
수학 문제를 풀려고 하면 국어 책을 가방(디스크)에 넣어야 하고, 다시 국어 숙제를 하려면 수학 책을 넣어야 하죠.
결국 하루 종일 책을 가방에서 넣었다 뺐다만 하느라, 공부는 한 페이지도 못 하고 시간만 다 버리는 무서운 현상이랍니다!