가상 메모리 트래싱과 Working Set 기반 대응

페이지 교체가 실제 작업을 밀어내는 상태

트래싱(Thrashing)은 가상 메모리 환경에서 페이지 부재(Page Fault)가 지나치게 늘어나면서, 프로세스가 본래 작업보다 페이지 적재와 교체에 더 많은 시간을 쓰는 현상이다. CPU 이용률은 급격히 낮아지고 응답 시간은 늘어나며, 시스템 전체 처리량도 현저히 감소한다.

문제는 페이지 부재가 한 번 발생하는 데서 끝나지 않는다는 점이다. 너무 많은 프로세스가 제한된 메모리를 경쟁하면 프로세스별로 확보할 수 있는 메모리가 줄어든다. 페이지 부재와 페이징 작업이 늘고 CPU가 유휴 상태에 가까워지면, 운영체제가 프로세스를 더 적재하면서 상황을 악화시키는 순환이 생길 수 있다.

⤢✕

메모리 압박이 트래싱으로 이어지는 조건

물리 메모리의 크기가 모든 프로세스의 Working Set 총합보다 작으면 각 프로세스에 필요한 페이지를 충분히 유지하기 어렵다. 프로세스별 할당 페이지 수가 부족하거나 메모리 누수로 가용 메모리가 줄어든 경우도 같은 압박을 만든다.

동시 실행 프로세스가 시스템 수용 범위를 넘는 경우에는 각 프로세스의 Working Set을 함께 수용할 수 없다. 여기에 지역성(Locality)을 고려하지 않는 페이지 교체 정책이나 글로벌(Global) 교체 정책이 더해지면, 프로세스 간 페이지 경쟁이 심해질 수 있다.

CPU 이용률만을 기준으로 프로세스 적재를 늘리고 Working Set 크기나 적응형 메모리 관리를 고려하지 않는 설계도 트래싱의 원인이 된다.

다중 프로그래밍 수준이 넘어서면

다중 프로그래밍 수준이 늘어나는 동안에는 CPU 이용률이 증가하고, 적정 범위까지는 성능이 향상된다. 그러나 임계점을 넘으면 양상이 바뀐다. 페이징 I/O만 증가하고 실제 작업은 정체되며, 디스크 I/O 대기 시간도 급증한다.

⤢✕

Working Set으로 필요한 페이지를 판단한다

Peter Denning이 제안한 Working Set 모델은 지역성을 바탕으로 메모리를 관리한다. 특정 시간 창(Time Window) Δ 동안 참조된 페이지 집합을 Working Set으로 보고, 프로세스가 효율적으로 실행되기 위해 필요한 최소 페이지 수를 판단한다. Working Set의 크기는 WSS(Working Set Size)로 표현한다.

WS(t, Δ)는 시간 t에서 과거 Δ 시간 동안 참조된 페이지의 집합이다. Δ가 너무 작으면 지역성을 충분히 포착하지 못하고, 너무 크면 여러 지역성이 함께 포함되어 비효율적일 수 있다.

페이지 교체에서는 프로세스의 Working Set을 메모리에 유지하고 그 밖의 페이지를 교체 대상으로 삼는다. 모든 프로세스의 WSS 합이 메모리 크기를 넘으면 일부 프로세스를 스왑 아웃해 남은 프로세스의 Working Set을 보장한다.

⤢✕

메모리 경쟁을 줄이는 운영 방법

지역 교체 정책(Local Replacement)은 각 프로세스에 고정된 페이지 프레임을 할당하고 자신의 페이지만 교체하게 한다. 프로세스 간 간섭을 줄일 수 있지만, 전체 메모리 활용도가 낮아질 가능성은 있다.

우선순위 교체 정책(Priority Replacement)은 우선순위가 낮은 프로세스의 페이지를 먼저 교체해 중요 프로세스의 Working Set을 보호하고 서비스 품질(QoS)을 보장한다.

PFF(Page Fault Frequency) 기법은 페이지 부재율을 관찰하면서 상한(Upper Bound)과 하한(Lower Bound)을 둔다. PFF가 상한보다 높으면 페이지 프레임을 추가로 할당하고, 하한보다 낮으면 프레임을 회수해 메모리 할당량을 동적으로 조절한다.

다중 프로그래밍 수준 자체를 낮춰야 할 때는 일부 프로세스를 디스크로 스왑 아웃한다. 중기 스케줄러(Medium-term Scheduler)를 활용하면 남은 프로세스의 Working Set을 확보할 수 있다. 물리 메모리 증설은 근본적인 대응이지만 비용과 하드웨어 제약을 함께 고려해야 한다.

징후를 확인하는 지표와 명령

페이지 부재율이 높은 상태로 지속되고, 특히 사용자 모드에서 CPU 이용률이 급격히 떨어지며 페이징 I/O가 증가한다면 트래싱을 의심할 수 있다. 응답 시간 증가와 처리량 감소도 함께 확인할 지표다.

Linux에서는 vmstat로 페이징 활동을 볼 수 있다. Windows에서는 Performance Monitor의 페이지 부재 카운터를, Solaris/Unix에서는 sar를 활용할 수 있으며 top과 htop은 실시간 시스템 상태를 확인하는 데 쓰인다.

# Linux vmstat 예시
vmstat 1
# si (swap in), so (swap out) 값이 지속적으로 높으면 thrashing 의심

환경별로 나타나는 모습

웹 서버에서는 동시 접속자가 급증하고 세션별 메모리 요구량이 커질 때 트래싱이 발생할 수 있다. 로드 밸런싱, 연결 제한, 메모리 캐시 최적화가 대응 수단이 된다.

데이터베이스 시스템에서는 대용량 쿼리 실행 중 버퍼 풀이 부족하거나 인덱스 스캔으로 랜덤 페이지 접근이 많아질 때 문제가 나타난다. 쿼리 최적화, 버퍼 풀 크기 조정, 인덱스 재설계를 검토한다.

가상화 환경에서는 VM(Virtual Machine)을 과도하게 생성하거나 메모리 오버커밋(Overcommit) 설정이 부적절할 때 메모리 경쟁이 심해진다. VM 수 제한과 메모리 벌룬(Balloon) 드라이버 활용이 대응 방법이다.