Page Cache Eviction은 어떤 기준으로 이루어질까?

페이지 캐시 축출은 어떤 기준으로 이루어질까요

컴퓨터를 사용하면서 ‘캐시’라는 단어를 한 번쯤 들어보셨을 것입니다. 웹 브라우저 캐시, CPU 캐시 등 다양한 캐시가 있지만, 그중에서도 운영체제가 디스크 I/O 성능을 향상시키기 위해 사용하는 핵심적인 메커니즘이 바로 ‘페이지 캐시’입니다. 페이지 캐시는 디스크에서 읽어온 데이터를 메모리(RAM)에 임시로 저장해두는 공간으로, 다음에 같은 데이터에 접근할 때 디스크까지 가지 않고 메모리에서 바로 가져와 훨씬 빠르게 처리할 수 있게 해줍니다. 하지만 메모리 공간은 한정적입니다. 따라서 새로운 데이터가 계속 들어오면, 언젠가는 기존의 데이터를 내보내야 할 때가 오는데, 이를 ‘페이지 캐시 축출(Page Cache Eviction)’이라고 합니다. 이 축출 과정이 어떤 기준으로 이루어지는지 이해하는 것은 시스템 성능을 최적화하고 문제를 진단하는 데 매우 중요합니다.

페이지 캐시의 기본 원리와 중요성

페이지 캐시는 운영체제가 관리하는 특별한 메모리 영역입니다. 프로그램이 디스크에서 파일을 읽으려고 할 때, 운영체제는 해당 파일의 내용을 페이지 단위로 읽어와 페이지 캐시에 저장합니다. 만약 다른 프로그램이나 같은 프로그램이 나중에 동일한 파일의 같은 부분을 읽으려고 하면, 운영체제는 디스크까지 가지 않고 이미 메모리에 있는 페이지 캐시에서 데이터를 즉시 제공합니다. 이는 디스크 I/O가 CPU나 메모리 접근보다 수백, 수천 배 느리기 때문에 시스템 전반의 반응 속도를 크게 향상시키는 핵심적인 기술입니다.

페이지 캐시는 읽기 작업뿐만 아니라 쓰기 작업에도 사용됩니다. 프로그램이 파일에 데이터를 쓸 때, 운영체제는 먼저 해당 데이터를 페이지 캐시에 기록하고, 나중에 이 데이터를 ‘더티(Dirty) 페이지’로 표시합니다. 더티 페이지는 일정 시간 후 또는 시스템의 특정 조건에 따라 디스크에 실제로 기록됩니다. 이렇게 하면 쓰기 작업도 즉시 완료된 것처럼 느껴지게 하여 프로그램의 반응성을 높일 수 있습니다. 하지만 더티 페이지가 너무 많아지면 시스템의 메모리 압박이 커지고, 갑작스러운 전원 손실 시 데이터 유실의 위험도 커집니다.

페이지 캐시 축출의 주요 알고리즘

메모리 공간이 부족해지면 운영체제는 어떤 페이지를 축출할지 결정해야 합니다. 이 결정을 내리는 데 다양한 알고리즘이 사용되며, 각 알고리즘은 특정 상황에서 장단점을 가집니다.

LRU 가장 최근에 사용되지 않은 페이지

LRU(Least Recently Used)는 가장 널리 사용되고 직관적인 캐시 축출 알고리즘 중 하나입니다. 이 알고리즘은 ‘가장 오랫동안 사용되지 않은 페이지가 앞으로도 사용될 가능성이 가장 낮다’는 가정을 기반으로 합니다. 페이지가 접근될 때마다 해당 페이지의 ‘최근 사용 시간’을 갱신하고, 메모리가 부족해지면 이 시간이 가장 오래된 페이지부터 축출합니다.

• 장점: 일반적인 워크로드에서 좋은 성능을 보여줍니다. 구현이 비교적 간단합니다.

• 단점: 순차적인 대용량 파일 읽기(예: 비디오 스트리밍, 대규모 데이터 백업)와 같은 특정 워크로드에서는 문제가 발생할 수 있습니다. 이런 경우, 새로 읽어 들인 데이터가 캐시를 가득 채우면서 이전에 자주 사용되던 유용한 페이지들을 모두 밀어내 버릴 수 있습니다. 이를 ‘스캔 저항(Scan Resistance)’ 문제라고 부르기도 합니다.

LFU 가장 적게 사용된 페이지

LFU(Least Frequently Used) 알고리즘은 ‘가장 적게 사용된 페이지가 앞으로도 사용될 가능성이 가장 낮다’는 가정을 따릅니다. 각 페이지마다 접근 횟수를 기록하고, 메모리가 부족해지면 접근 횟수가 가장 적은 페이지부터 축출합니다.

• 장점: 한 번 접근된 후 오랫동안 사용되지 않았지만, 과거에 매우 자주 사용되었던 페이지를 캐시에 유지하는 데 효과적일 수 있습니다.

• 단점: 과거에 많이 사용되었지만 현재는 더 이상 사용되지 않는 페이지가 캐시에 불필요하게 오래 남아있을 수 있습니다. 접근 횟수를 계속 추적해야 하므로 LRU보다 오버헤드가 더 클 수 있습니다. 페이지 캐시에서는 LRU보다 덜 사용됩니다.

클럭 알고리즘과 그 변형

실제 운영체제 커널에서는 순수한 LRU나 LFU보다는 ‘클럭(Clock) 알고리즘’과 같은 변형된 알고리즘이 많이 사용됩니다. 클럭 알고리즘은 ‘2차 기회(Second-Chance)’ 알고리즘이라고도 불리며, LRU의 단점을 보완하면서도 구현 복잡도를 낮춥니다.

• 작동 방식: 각 페이지에 ‘참조 비트(Reference Bit)’를 둡니다. 페이지가 접근될 때마다 이 비트가 1로 설정됩니다. 운영체제는 원형 리스트를 따라 페이지들을 스캔하면서 축출할 페이지를 찾습니다. 만약 참조 비트가 1이면 이 페이지는 최근에 사용되었다는 뜻이므로, 비트를 0으로 바꾸고 다음 페이지로 넘어갑니다(즉, ‘두 번째 기회’를 줍니다). 참조 비트가 0인 페이지를 만나면 이 페이지는 최근에 사용되지 않았다는 뜻이므로 축출 대상으로 선택합니다.

• 장점: 순수한 LRU보다 구현이 간단하고 오버헤드가 적으면서도 LRU와 유사한 성능을 제공합니다. 스캔 저항 문제에 어느 정도 대처할 수 있습니다.

ARC 적응형 교체 캐시

ARC(Adaptive Replacement Cache)는 IBM에서 개발한 고급 캐시 알고리즘으로, LRU와 LFU의 장점을 결합하여 워크로드 변화에 ‘적응’하는 능력을 가집니다. ARC는 두 개의 LRU 리스트를 사용하여 최근에 접근된 페이지와 자주 접근된 페이지를 동시에 추적하며, 이 두 리스트의 크기를 워크로드에 따라 동적으로 조절합니다.

• 장점: 다양한 워크로드에서 LRU보다 뛰어난 성능을 보이는 경우가 많습니다. 특히 스캔 저항 문제에 강합니다.

• 단점: 구현이 복잡하고 오버헤드가 더 높을 수 있습니다.

페이지 캐시 축출에 영향을 미치는 요인

알고리즘 외에도 여러 요인이 페이지 캐시 축출에 영향을 미칩니다.

• 메모리 압박: 가장 중요한 요인입니다. 시스템의 물리적 메모리가 부족해지면 운영체제는 페이지 캐시를 포함한 다양한 메모리 영역에서 페이지를 적극적으로 축출하여 여유 공간을 확보하려고 합니다.

• 워크로드 유형:
  • 순차적 읽기: 대용량 파일 복사, 백업 등은 캐시를 한 번만 사용하고 버려질 데이터로 가득 채워 기존의 유용한 캐시 데이터를 밀어낼 수 있습니다.
  • 랜덤 읽기: 데이터베이스 쿼리와 같이 작은 데이터 블록에 무작위로 접근하는 경우, 캐시 적중률이 높을수록 성능 향상 효과가 큽니다.
  • 쓰기 작업: ‘더티 페이지’를 생성하며, 이 페이지들은 디스크에 기록되기 전까지 캐시에 남아있어야 합니다. 더티 페이지가 너무 많아지면 메모리 압박을 가중시킵니다.

• 시스템 설정: 운영체제는 페이지 캐시 동작을 제어하는 여러 커널 파라미터를 제공합니다.
  • vm.dirty_ratio, vm.dirty_background_ratio: 더티 페이지의 비율을 제어하여 디스크에 데이터를 플러시(기록)하는 시점을 결정합니다. 이 값을 너무 높게 설정하면 메모리 압박이 커질 수 있고, 너무 낮게 설정하면 쓰기 성능이 저하될 수 있습니다.
  • vm.vfs_cache_pressure: 페이지 캐시(파일 데이터)와 inode/dentry 캐시(파일 시스템 메타데이터) 중 어느 쪽을 더 적극적으로 회수할지 결정하는 값입니다. 기본값은 100이며, 이 값을 높이면 페이지 캐시보다 inode/dentry 캐시를 더 빨리 회수하고, 낮추면 그 반대입니다.

• 파일 시스템 유형: 파일 시스템 자체의 특성이나 설정이 페이지 캐시의 동작 방식에 미묘한 영향을 줄 수 있습니다. 예를 들어, 특정 파일 시스템은 메타데이터를 캐시하는 방식이 다를 수 있습니다.

실생활에서의 활용 방법과 유용한 팁

페이지 캐시의 축출 기준을 이해하는 것은 단순히 이론적인 지식에 그치지 않고, 실제 시스템 성능을 개선하는 데 큰 도움이 됩니다.

• 시스템 모니터링:
  • free -h: 현재 메모리 사용량을 확인하여 ‘buff/cache’ 항목을 통해 페이지 캐시의 크기를 파악합니다.
  • vmstat: 가상 메모리, 프로세스, CPU 활동 등을 실시간으로 모니터링하여 ‘si'(swap in), ‘so'(swap out) 값을 통해 스왑 활동, 즉 메모리 압박 정도를 확인합니다.
  • iostat: 디스크 I/O 통계를 확인하여 디스크 사용량이 높은지, 캐시 미스로 인해 디스크 접근이 잦아지는지 등을 파악합니다.
  • atop: 시스템 전반의 리소스 사용량을 상세하게 보여주며, 캐시 관련 통계도 제공합니다.

• 커널 파라미터 튜닝:
  • 쓰기 작업이 많은 시스템(데이터베이스 서버 등)에서는 vm.dirty_ratio와 vm.dirty_background_ratio 값을 조절하여 더티 페이지의 플러시 시점을 최적화할 수 있습니다. 너무 자주 플러시하면 쓰기 성능이 저하되고, 너무 늦게 플러시하면 메모리 부족 현상이 발생할 수 있습니다.
  • 특정 애플리케이션이 파일 시스템 메타데이터를 많이 사용하는 경우(예: 웹 서버에서 작은 파일을 많이 다루는 경우), vm.vfs_cache_pressure 값을 낮춰 inode/dentry 캐시를 더 오래 유지하도록 설정할 수 있습니다.

• 애플리케이션 수준 캐싱 활용: 운영체제의 페이지 캐시 외에도 Redis, Memcached와 같은 애플리케이션 수준의 캐시 솔루션을 함께 사용하여 특정 데이터에 대한 접근 속도를 더욱 높일 수 있습니다. 이는 특히 데이터베이스 쿼리 결과나 자주 접근하는 API 응답과 같이 애플리케이션 로직에서 발생하는 데이터에 유용합니다.

• 적절한 메모리 용량 확보: 시스템의 워크로드에 맞는 충분한 RAM을 확보하는 것이 가장 중요합니다. RAM이 충분하면 페이지 캐시가 더 많은 데이터를 유지할 수 있어 디스크 I/O를 최소화할 수 있습니다.
• SSD 활용: SSD는 HDD보다 훨씬 빠른 속도를 제공하므로, 페이지 캐시 미스가 발생하더라도 성능 저하의 폭이 줄어듭니다. 하지만 SSD를 사용하더라도 페이지 캐시는 여전히 성능 향상에 필수적입니다.

흔한 오해와 사실 관계

• 오해: “비어있는 RAM은 낭비되는 RAM이다.”
  • 사실: 리눅스 같은 운영체제는 사용되지 않는 RAM을 자동으로 페이지 캐시로 활용합니다. ‘Free’ 메모리가 적다고 해서 시스템 성능이 나쁜 것은 아닙니다. 오히려 ‘buff/cache’ 메모리가 높다는 것은 캐시가 효율적으로 작동하고 있다는 좋은 신호일 수 있습니다.

• 오해: “페이지 캐시는 읽기 전용 데이터만 저장한다.”
  • 사실: 페이지 캐시는 읽기 데이터뿐만 아니라 수정된 쓰기 데이터, 즉 ‘더티 페이지’도 저장합니다. 이 더티 페이지는 나중에 디스크에 기록됩니다.

• 오해: “메모리가 가득 차면 시스템이 느려진다.”
  • 사실: ‘buff/cache’ 영역이 가득 차 있는 것은 시스템이 캐시를 잘 활용하고 있다는 의미일 수 있습니다. 시스템이 느려지는 것은 메모리 부족으로 인해 캐시 축출이 빈번하게 일어나고 스왑(swap) 공간을 사용하게 될 때 발생합니다.

전문가의 조언

시스템 엔지니어들은 페이지 캐시 관리의 중요성을 강조하며 다음과 같은 조언을 합니다.

• “페이지 캐시는 운영체제의 핵심적인 성능 최적화 도구입니다. 이를 이해하지 못하고 시스템 성능을 논하는 것은 불가능합니다.”

• “단순히 ‘메모리가 부족하다’고 단정하기 전에, vmstat, iostat, free 명령어를 통해 캐시 사용량과 스왑 활동, 디스크 I/O 패턴을 면밀히 분석해야 합니다. 많은 경우, 메모리 부족이 아니라 캐시의 비효율적인 사용이나 특정 애플리케이션의 비정상적인 I/O 패턴이 문제의 원인일 수 있습니다.”
• “커널 파라미터 튜닝은 신중하게 접근해야 합니다. 기본값이 대부분의 워크로드에서 최적화되어 있으므로, 섣부른 변경은 오히려 성능 저하를 야기할 수 있습니다. 변경 전후로 반드시 성능 테스트를 수행하고 모니터링해야 합니다.”
• “클라우드 환경에서는 메모리 용량을 유연하게 조절할 수 있습니다. 하지만 불필요하게 높은 사양의 메모리를 사용하는 것은 비용 낭비로 이어질 수 있으므로, 실제 워크로드에 기반한 적절한 메모리 프로비저닝이 중요합니다.”

비용 효율적인 활용 방법

페이지 캐시를 이해하고 효과적으로 관리하는 것은 시스템 운영 비용을 절감하는 데도 기여합니다.

• RAM의 적절한 규모 예측: 애플리케이션의 메모리 사용 패턴, 데이터 액세스 패턴, 디스크 I/O 요구 사항 등을 분석하여 필요한 RAM의 양을 정확하게 예측합니다. 과도한 RAM은 비용 낭비로 이어질 수 있으며, 부족한 RAM은 성능 저하로 이어져 사용자 경험을 해치거나 더 많은 리소스를 요구하게 만듭니다.

• 불필요한 디스크 I/O 최소화: 애플리케이션 코드를 최적화하여 디스크에 접근하는 횟수를 줄입니다. 예를 들어, 자주 사용되는 설정 파일이나 작은 데이터는 메모리에 로드하여 사용하는 것이 효율적입니다.
• 모니터링을 통한 지속적인 최적화: 시스템을 지속적으로 모니터링하여 페이지 캐시의 효율성을 확인하고, 워크로드 변화에 따라 필요한 경우 커널 파라미터를 조절하거나 RAM을 증설하는 등의 조치를 취합니다. 이를 통해 장기적으로 안정적인 성능을 유지하면서도 불필요한 하드웨어 업그레이드 비용을 줄일 수 있습니다.

자주 묻는 질문

Q 페이지 캐시를 수동으로 비울 수 있나요

네, 리눅스 시스템에서는 sync; echo 3 > /proc/sys/vm/drop_caches 명령어를 사용하여 페이지 캐시를 수동으로 비울 수 있습니다. 그러나 이는 일반적으로 프로덕션 시스템에서는 권장되지 않습니다. 캐시를 비우면 시스템 성능이 일시적으로 저하될 수 있으며, 디버깅이나 특정 테스트 상황에서만 사용해야 합니다. 운영체제는 캐시를 스스로 효율적으로 관리하도록 설계되어 있습니다.

Q 페이지 캐시에 얼마나 많은 RAM을 할당해야 하나요

페이지 캐시는 운영체제가 가용한 메모리를 동적으로 활용하는 영역이므로, 특정 양을 ‘할당’하는 개념은 아닙니다. 대신, 시스템 전체에 충분한 RAM을 확보하는 것이 중요합니다. 운영체제는 필요한 만큼 페이지 캐시에 메모리를 사용하고, 다른 애플리케이션이 메모리를 요청하면 페이지 캐시의 일부를 회수하여 제공합니다.

Q 페이지 캐시가 가득 차 있으면 시스템이 느려진다는 뜻인가요

아닙니다. 페이지 캐시가 가득 차 있다는 것은 오히려 운영체제가 디스크 I/O를 줄이기 위해 메모리를 효율적으로 사용하고 있다는 좋은 신호일 수 있습니다. 시스템이 느려지는 것은 페이지 캐시가 가득 찬 상태에서 새로운 데이터가 계속 들어와 유용한 페이지들이 빈번하게 축출되고, 이로 인해 디스크 접근이 잦아지며, 심지어 스왑 공간까지 사용하게 될 때 발생합니다.

Q 페이지 캐시와 버퍼 캐시는 같은 건가요

과거에는 페이지 캐시와 버퍼 캐시가 별도의 개념으로 사용되기도 했지만, 현대 리눅스 커널에서는 이 둘이 통합되어 ‘페이지 캐시’라는 이름으로 관리됩니다. free 명령어의 ‘buff/cache’ 항목은 이 통합된 페이지 캐시의 사용량을 보여줍니다. 일반적으로 ‘페이지 캐시’는 파일 데이터 자체를 캐시하고, ‘버퍼 캐시’는 파일 시스템의 메타데이터(inode, dentry)나 블록 장치 버퍼를 캐시하는 데 사용된다고 볼 수 있지만, 커널 내부에서는 유기적으로 통합되어 작동합니다.