리눅스 Page Cache의 Dirty Page가 파일 저장 속도에 미치는 영향

리눅스 페이지 캐시와 더티 페이지가 파일 저장 성능에 미치는 영향

컴퓨터를 사용하다 보면 대용량 파일을 복사하거나 데이터베이스 로그를 기록할 때 처음에는 매우 빠르게 진행되다가 갑자기 속도가 크게 떨어지는 현상을 경험할 수 있습니다.

파일 복사 프로그램에 표시되는 속도가 초반에는 저장장치의 실제 성능보다 높게 나오다가 일정 시간이 지나면 급격히 낮아지는 경우도 있습니다. 이는 컴퓨터가 고장 난 것이 아니라 리눅스 운영체제의 핵심 메커니즘인 페이지 캐시와 더티 페이지 처리 방식에서 발생하는 현상일 수 있습니다.

이 과정을 이해하면 단순히 저장장치의 성능만 확인하는 데서 벗어나 시스템의 실제 입출력 병목을 파악하고 최적화하는 데 도움이 됩니다.

페이지 캐시란 무엇인가

리눅스 커널은 사용하지 않는 물리 메모리의 일부를 디스크에 저장된 데이터의 복사본을 보관하는 공간으로 활용합니다. 이를 페이지 캐시(Page Cache)라고 부릅니다.

디스크와 SSD는 RAM보다 접근 속도가 느리기 때문에 운영체제는 자주 읽거나 쓰는 데이터를 메모리에 임시로 보관해 입출력 성능을 높입니다.

사용자가 파일을 읽으려고 할 때 필요한 데이터가 페이지 캐시에 남아 있다면 저장장치에 다시 접근하지 않고 메모리에서 바로 가져올 수 있습니다. 처음 실행했을 때보다 같은 프로그램이나 파일을 두 번째로 열었을 때 더 빠르게 느껴지는 이유 중 하나도 페이지 캐시입니다.

페이지 캐시는 특정 크기로 고정된 공간이 아닙니다. 시스템의 메모리 사용 상황에 따라 크기가 동적으로 변하며, 애플리케이션에서 메모리가 필요하면 커널이 캐시 일부를 정리해 공간을 확보합니다.

따라서 리눅스에서 사용 가능한 메모리가 적게 표시되더라도 상당 부분이 페이지 캐시로 사용되고 있다면 반드시 메모리 부족을 의미하는 것은 아닙니다.

더티 페이지의 정의와 작동 원리

사용자가 파일에 데이터를 기록할 때 운영체제는 모든 데이터를 즉시 물리적인 저장장치에 쓰지 않습니다. 우선 메모리의 페이지 캐시에 내용을 반영한 뒤 애플리케이션에는 쓰기가 처리된 것처럼 응답할 수 있습니다.

이때 메모리의 데이터는 변경됐지만 아직 디스크에는 반영되지 않은 상태가 됩니다. 이렇게 수정됐으나 저장장치에 기록되지 않은 페이지를 더티 페이지(Dirty Page)라고 부릅니다.

운영체제가 이러한 방식을 사용하는 이유는 저장장치 쓰기 작업이 메모리 접근보다 훨씬 느리기 때문입니다. 작은 데이터를 요청할 때마다 디스크에 개별적으로 기록하면 입출력 요청이 지나치게 많아지고 시스템의 전체 처리량도 떨어집니다.

리눅스는 변경된 데이터를 메모리에 일정 시간 모아두었다가 한꺼번에 저장장치로 내보냅니다. 이를 지연 쓰기 또는 Writeback이라고 합니다.

커널은 더티 페이지가 일정량 이상 쌓이거나 일정 시간이 지나면 백그라운드 쓰기 작업을 시작합니다. 이 과정에서 메모리에 있던 변경 내용이 실제 저장장치에 반영됩니다.

성능 병목이 발생하는 이유

대용량 파일 복사 도중 발생하는 급격한 속도 저하는 더티 페이지가 저장장치로 반영되는 과정과 관련이 있습니다.

복사 초반에는 데이터가 메모리의 페이지 캐시에 빠르게 쌓이기 때문에 실제 디스크 성능보다 높은 전송 속도가 표시될 수 있습니다. 하지만 더티 페이지가 계속 증가해 임계치에 가까워지면 운영체제는 데이터를 저장장치로 내보내는 속도를 높여야 합니다.

이때 SSD나 하드디스크의 실제 쓰기 속도가 메모리에 데이터가 쌓이는 속도를 따라가지 못하면 새로운 쓰기 요청도 영향을 받게 됩니다. 상황에 따라 애플리케이션의 쓰기 속도가 제한되거나 저장 작업이 끝날 때까지 대기할 수 있습니다.

실제로 대용량 파일을 복사하면서 시스템 상태를 확인해보면 CPU 사용률은 높지 않은데도 작업 반응이 느려지는 경우가 있습니다. 이때 iostat으로 확인하면 디스크 대기 시간과 사용률이 크게 올라가 있는 모습을 볼 수 있습니다.

사용자 입장에서는 파일 복사 속도가 잠시 0에 가까워지거나 프로그램이 멈춘 것처럼 보일 수 있지만, 내부에서는 메모리에 쌓인 데이터를 저장장치로 내보내는 작업이 진행되고 있을 가능성이 큽니다.

이러한 현상은 흔히 I/O Wait 증가와 함께 나타나지만, 모든 I/O Wait가 더티 페이지 때문에 발생하는 것은 아닙니다. 저장장치 자체의 성능 저하, 동시 입출력 작업, 파일 시스템 상태도 함께 확인해야 합니다.

더티 페이지 제어와 관련된 주요 설정

리눅스에서는 /proc/sys/vm 경로의 커널 파라미터를 통해 더티 페이지의 처리 방식을 조정할 수 있습니다.

환경에 따라 설정값을 변경할 수 있지만, 단순히 수치를 낮추거나 높인다고 시스템이 무조건 빨라지는 것은 아닙니다. 현재 서버의 메모리 크기와 저장장치 성능, 쓰기 패턴을 함께 고려해야 합니다.

dirty_ratio

dirty_ratio는 전체 시스템 메모리를 기준으로 더티 페이지가 증가할 수 있는 상한선을 비율로 지정합니다.

더티 페이지가 해당 수준에 가까워지면 데이터를 생성하는 프로세스도 저장장치 쓰기에 참여하거나 쓰기 속도가 제한될 수 있습니다. 이 과정에서 파일 저장이나 로그 기록의 응답 시간이 갑자기 길어질 수 있습니다.

메모리 용량이 매우 큰 서버에서는 같은 비율이라도 실제 더티 페이지의 양이 지나치게 커질 수 있습니다. 이런 환경에서는 비율 대신 절대 용량을 지정하는 설정을 검토하기도 합니다.

dirty_background_ratio

dirty_background_ratio는 커널이 백그라운드에서 더티 페이지를 저장장치로 내보내기 시작하는 기준입니다.

이 값을 낮추면 더티 페이지가 적게 쌓인 상태부터 백그라운드 쓰기가 시작됩니다. 한꺼번에 많은 데이터가 기록되는 현상을 완화해 응답 시간을 일정하게 유지하는 데 도움이 될 수 있습니다.

다만 값을 지나치게 낮추면 작은 쓰기 작업이 자주 발생해 저장장치의 전체 처리량이 떨어질 수 있습니다.

테스트 환경에서 이 값을 낮춰보면 순간적인 속도 급락은 줄어드는 대신 최고 복사 속도가 낮아지는 경우도 있습니다. 결국 최대 처리량을 우선할지, 일정한 응답 속도를 우선할지에 따라 적절한 값이 달라집니다.

dirty_expire_centisecs

dirty_expire_centisecs는 더티 페이지가 오래된 것으로 판단되기까지의 시간을 지정합니다. 설정 단위는 100분의 1초입니다.

해당 시간이 지난 더티 페이지는 백그라운드 Writeback 작업의 대상이 됩니다. 값을 너무 크게 설정하면 변경된 데이터가 메모리에 오래 머물 수 있으며, 갑작스러운 전원 차단이나 시스템 장애가 발생했을 때 손실될 수 있는 데이터 범위도 커질 수 있습니다.

반대로 값을 너무 작게 설정하면 저장장치에 데이터를 자주 기록하게 돼 입출력 효율이 떨어질 수 있습니다.

실생활에서의 활용과 최적화 방법

일반적인 데스크톱이나 개인용 컴퓨터에서는 운영체제의 기본 설정으로도 충분한 경우가 많습니다.

하지만 대용량 파일을 자주 복사하거나 지속적으로 로그를 생성하는 서버, 백업 서버, 데이터 처리 시스템에서는 워크로드에 맞는 설정을 검토할 필요가 있습니다.

파일 복사 속도가 일정 시간마다 크게 떨어진다면 먼저 dirty_background_ratio를 무작정 변경하기보다 현재 더티 페이지의 양과 디스크 처리 속도를 확인해야 합니다.

/proc/meminfo에서 Dirty와 Writeback 항목을 확인하면 현재 메모리에 남아 있는 더티 페이지와 저장장치로 기록 중인 데이터양을 파악할 수 있습니다.

데이터 무결성이 중요한 환경에서는 프로그램이 fsync나 fdatasync와 같은 시스템 호출을 사용해 필요한 데이터를 저장장치에 반영하도록 설계해야 합니다.

리눅스의 sync 명령어를 실행하면 시스템 전반에 쌓인 변경 데이터를 저장장치로 내보낼 수 있지만, 대량의 더티 페이지가 존재할 때 실행하면 순간적으로 높은 입출력 부하가 발생할 수 있습니다. 따라서 운영 서버에서 습관적으로 반복 실행하기보다 필요한 상황에서 신중하게 사용해야 합니다.

물리 메모리를 늘리면 페이지 캐시와 더티 페이지를 수용할 공간도 커지므로 짧은 구간의 쓰기 성능은 개선될 수 있습니다. 하지만 저장장치의 지속 쓰기 속도 자체가 높아지는 것은 아닙니다.

메모리가 많아지면 더 많은 데이터를 빠르게 받아들일 수 있는 대신, 나중에 한꺼번에 기록해야 하는 데이터도 늘어날 수 있습니다. 장시간 지속되는 쓰기 작업에서는 메모리 증설보다 저장장치 처리량과 Writeback 정책이 더 중요한 경우도 있습니다.

흔한 오해와 진실

많은 사람이 저장장치의 속도만 빠르면 파일 저장 성능 문제가 모두 해결된다고 생각합니다.

NVMe SSD를 사용하면 하드디스크나 SATA SSD보다 더티 페이지를 빠르게 처리할 수 있어 체감 성능이 개선되는 것은 사실입니다. 하지만 저장장치의 처리량보다 더 빠른 속도로 데이터가 계속 생성된다면 NVMe 환경에서도 쓰기 지연은 발생할 수 있습니다.

근본적으로는 애플리케이션이 데이터를 생성하는 속도와 저장장치가 데이터를 반영하는 속도 사이의 균형이 중요합니다.

또 다른 오해는 더티 페이지를 최대한 줄이는 것이 항상 좋다는 생각입니다. 더티 페이지는 작은 쓰기 요청을 모아 효율적으로 처리하기 위한 정상적인 기능입니다.

이를 지나치게 제한하면 저장장치에 작은 쓰기 요청이 자주 발생하고 시스템의 전체 처리량이 떨어질 수 있습니다. SSD 환경에서는 불필요하게 잦은 쓰기 작업이 발생해 효율이 낮아질 가능성도 있습니다.

반대로 더티 페이지를 지나치게 많이 허용하면 평상시에는 빠르게 보이지만 임계치에 도달했을 때 긴 지연이 한꺼번에 발생할 수 있습니다.

전문가들의 조언

대규모 데이터 처리 시스템을 구성할 때는 더티 페이지 설정만 보지 말고 입출력 스케줄러와 파일 시스템, 저장장치의 특성을 함께 확인해야 합니다.

대용량 로그를 처리하는 서버에서는 EXT4나 XFS 같은 파일 시스템의 특성과 마운트 옵션이 쓰기 성능에 영향을 줄 수 있습니다. 다만 마운트 옵션을 변경하면 데이터 안정성이나 복구 방식에도 영향을 줄 수 있으므로 충분한 검증이 필요합니다.

쓰기 작업이 집중되는 시간대에는 iostat을 사용해 디스크 사용률과 대기 시간, 처리량을 확인하는 것이 좋습니다. vmstat과 /proc/meminfo를 함께 살펴보면 메모리에 더티 페이지가 얼마나 쌓이고 있는지도 파악할 수 있습니다.

비슷한 성능 저하를 점검할 때 파일 복사 프로그램에 표시되는 속도만 확인하면 원인을 잘못 판단하기 쉽습니다. 복사 속도가 떨어지는 시점의 Dirty, Writeback, 디스크 대기 시간을 함께 비교해야 페이지 캐시 문제인지 저장장치 자체의 문제인지 구분할 수 있습니다.

성능 튜닝에는 항상 트레이드오프가 존재합니다. 더티 페이지를 자주 기록하도록 설정하면 갑작스러운 지연은 줄어들 수 있지만 최대 처리량이 낮아질 수 있습니다.

반대로 메모리에 더 많은 데이터를 쌓아두면 순간적인 쓰기 성능은 높아지지만 시스템 장애가 발생했을 때 손실될 수 있는 데이터양과 이후 Writeback 부하가 커질 수 있습니다.

시스템이 읽기 중심인지 쓰기 중심인지, 일정한 응답 시간이 중요한지, 데이터 보존이 얼마나 중요한지를 먼저 파악하는 것이 최적화의 시작입니다.

자주 묻는 질문

파일 복사 중 속도가 0으로 떨어지는 것은 고장인가요?

반드시 고장을 의미하는 것은 아닙니다. 메모리에 모여 있던 더티 페이지가 한꺼번에 저장장치로 기록되면서 일시적인 지연이 발생할 수 있습니다.

복사하려는 파일이 크거나 저장장치의 지속 쓰기 속도보다 빠르게 페이지 캐시에 데이터가 쌓일 때 이러한 현상이 나타나기 쉽습니다.

다만 속도 저하가 지나치게 오래 지속되거나 입출력 오류가 함께 발생한다면 저장장치 상태와 파일 시스템 오류도 확인해야 합니다.

설정값을 변경하면 시스템이 빨라지나요?

무조건 빨라지는 것은 아닙니다. 더티 페이지 설정은 최대 처리량과 응답 지연의 균형을 조절하는 과정에 가깝습니다.

잘못된 설정은 파일 저장 속도를 낮추거나 시스템 전체의 응답성을 해칠 수 있습니다. 한 번에 큰 폭으로 변경하기보다 모니터링 지표를 확인하면서 작은 단위로 조정해야 합니다.

SSD 수명에 영향이 있나요?

SSD는 기록되는 데이터양이 많을수록 NAND 플래시 셀의 마모가 증가합니다.

적절한 Writeback 설정은 작은 쓰기 작업을 모아 효율적으로 처리하는 데 도움이 될 수 있지만, 설정만으로 애플리케이션이 생성하는 전체 데이터양을 없앨 수는 없습니다.

오히려 지나치게 잦은 플러시를 유도하면 작은 쓰기 작업이 늘어날 수 있으므로 SSD 수명만을 이유로 값을 무조건 낮추는 것은 적절하지 않습니다.

특정 프로세스만 더티 페이지를 제어할 수 있나요?

dirty_ratio와 같은 커널 설정은 기본적으로 시스템 전체에 영향을 줍니다.

특정 프로그램에서 데이터 기록 시점을 직접 관리하려면 fsync, fdatasync, 직접 입출력 방식과 같은 기능을 애플리케이션 수준에서 검토해야 합니다.

다만 동기식 저장을 지나치게 자주 수행하면 요청마다 디스크 기록을 기다리게 돼 성능이 크게 떨어질 수 있습니다.

효율적인 시스템 운영을 위한 제언

시스템의 입출력 성능은 단순히 CPU, 메모리, 저장장치의 사양만으로 결정되지 않습니다.

리눅스 커널이 페이지 캐시를 어떻게 사용하고 더티 페이지를 언제 저장장치로 내보내는지 이해해야 실제 병목을 정확하게 판단할 수 있습니다.

복잡한 설정값부터 변경하기보다 먼저 현재 시스템에서 어떤 입출력 패턴이 발생하는지 모니터링하는 것이 중요합니다. 파일 복사 속도와 함께 더티 페이지의 양, 디스크 처리량, 대기 시간을 확인하면 성능 저하가 발생하는 지점을 구체적으로 파악할 수 있습니다.

중요한 데이터를 다루는 환경이라면 성능보다 데이터 무결성을 우선해야 합니다. 커널 설정을 과도하게 변경해 성능을 끌어올리기보다 충분한 저장장치 성능과 메모리, 안정적인 백업 전략을 함께 구성하는 편이 안전합니다.

결국 가장 비용 효율적인 방식은 하나의 수치를 극단적으로 조정하는 것이 아니라 애플리케이션의 쓰기 패턴, 리눅스의 Writeback 정책, 저장장치의 실제 처리 능력을 균형 있게 맞추는 것입니다.