[CS 지식20.] OS 캐시와 디스크 I/O: MySQL, Redis 퍼포먼스 분석

구분	설명
Page Cache	파일을 읽을 때 OS가 디스크 내용을 메모리에 복사
Buffer Cache	블록 디바이스에 대한 쓰기 캐시 (쓰기 지연 등 포함)
Dirty Page	디스크로 아직 flush되지 않은 메모리의 변경된 페이지

캐시가 잘 안 되는 상황은?

운영체제가 자동으로 캐시를 잘 써주지만, 다음과 같은 경우는 주의가 필요하다.

상황	설명
빈번한 drop_caches 실행	모니터링 자동화 스크립트에서 의도치 않게 캐시를 삭제
메모리 부족	다른 앱이 메모리를 과점 → OS는 캐시보다 프로세스를 우선 유지
direct I/O 옵션 사용	일부 DB/파일 시스템은 커널 캐시를 생략하고 직접 I/O 수행 (예: O_DIRECT)
대용량 파일 순차 접근	캐시 효율이 낮아지고 디스크 부하 증가

디스크 I/O vs 캐시 접근 속도 비교

항목	평균 접근 속도	단위
CPU Cache (L1/L2)	1~10 ns	나노초
메인 메모리 (RAM)	100 ns	나노초
SSD (NVMe)	10~100 µs	마이크로초
HDD	5~10 ms	밀리초

즉, OS 캐시는 수천 ~ 수만 배 빠르다.
캐시 적중률이 높을수록 I/O 대기 시간이 줄고 TPS는 기하급수적으로 향상된다.

MySQL: Buffer Pool vs OS 캐시

MySQL InnoDB는 자체적인 Buffer Pool 을 갖고 있으며, 여기에 자주 사용하는 인덱스/데이터 페이지를 유지한다.

하지만 모든 데이터를 캐싱할 수는 없다.

→ 결국 일부 쿼리는 여전히 디스크 I/O를 수행하게 되고, 이때 OS 캐시가 동작한다.

성능 향상 팁

`innodb_buffer_pool_size` 는 가능한 한 전체 메모리의 60~80%로 설정
OS 캐시도 일정 수준 확보되도록 전체 메모리 조절
`SHOW ENGINE INNODB STATUS` → 디스크 read 비율 확인

실무 장애 사례: OS 캐시로 인한 성능 저하

Case #1. MySQL 성능 저하

이슈: 밤 12시마다 자동 `drop_caches` 스크립트 실행
증상: 새벽 12시 직후 MySQL TPS 급감, 디스크 `read IOPS` 폭등
원인: Buffer Pool + OS 캐시 모두 날아가 `cold start` 발생
해결: `drop_caches` 제거 + `innodb_buffer_pool_dump/restore` 설정 활용

Case #2. Redis AOF 지연

이슈: AOF 파일 사이즈가 커졌는데 flush 속도 느림
원인: OS 캐시에는 쓰였으나 디스크 flush가 지연됨 → `fsync` 강제 주기 재조정
해결: AOF 백그라운드 `rewrite` + SSD 성능 점검 + `vm.dirty_ratio` 설정 튜닝

Redis: 전부 메모리인데 왜 캐시?

Redis는 메모리 DB지만 AOF나 RDB 파일 저장 시 디스크를 사용한다.
이때도 OS 캐시는 중요한 역할을 한다.

예: Redis가 AOF(Append-Only File) 파일에 쓰기할 때 `fsync` 타이밍이 `everysec` 으로 설정되어 있다면,

→ 실질적으로는 OS 캐시 버퍼에 쓰이고, 1초마다 디스크로 flush

이 구조 덕분에 쓰기 지연 없이 빠르게 처리되며, 동시성도 확보된다.

실전 예시: 캐시 적중률 모니터링

Linux에서 Page Cache 상태 확인

# 캐시 히트율 확인 (읽기 기준)
cat /proc/meminfo | grep -E 'Cached|MemTotal'

# 캐시 flush (주의: 성능 테스트나 학습 목적만!)
sync; echo 3 > /proc/sys/vm/drop_caches

MySQL에서 캐시 미스 비율 확인

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
-- 미스율 = reads / read_requests

모니터링 도구로 캐시 상태 추적하기

도구	특징
`htop`, `free -m`	메모리 전체 사용량과 캐시 확인 가능
`vmstat 1`	I/O wait, 페이지 in/out, context switch 추적
`iotop`, `dstat`	실시간 디스크 read/write 추적
`perf`, `bcc`, `eBPF`	고급 커널 캐시 hit/miss 추적 가능

특히 BPF 기반 도구는 OS 레벨에서 Cache Miss가 왜 발생했는지까지 추적 가능

🔚 마무리

OS 캐시는 메모리를 활용해 디스크 I/O를 추상화한 레이어다.

MySQL의 InnoDB, Redis의 디스크 백업 기능 모두 OS 캐시의 덕을 보며,
이것이 메모리가 부족하지 않으면 시스템이 유연하게 동작하는 이유다.

퍼포먼스를 높이고 싶다면?
단순히 DB 설정뿐 아니라 시스템의 메모리 사용 방식, 캐시 히트율까지 관찰하자.

“빠른 DB는 잘 설계된 OS 캐시와 짝을 이룬다”는 사실을 기억하자.

OS 캐시는 단순한 메모리 보조 수단이 아닌, 시스템 성능의 핵심 가속기이다.
MySQL의 Buffer Pool, Redis의 디스크 저장도 결국 OS 캐시의 도움 없이는 빠르게 동작할 수 없다.

캐시 적중률이 높은 환경을 구축하려면, DB 내부 튜닝뿐만 아니라 OS의 메모리 정책까지 통합적으로 고려해야 한다.

성능 병목을 시스템 전체의 시각으로 진단하고 싶은 개발자와 인프라 엔지니어라면, 이 구조에 대한 이해는 필수이다.

"빠른 디스크보다, 잘 쓰는 캐시가 더 중요하다."

Reference

728x90

'CS 지식' 카테고리의 다른 글

[CS 지식22.] TLS Handshake와 인증서 구조 (0)	2025.09.10
[CS 지식21.] top에 나오는 load average, 진짜 뜻은? (2)	2025.08.27
[CS 지식19.] C/C++ 개발자도 다시 보는 메모리 구조 (3)	2025.07.30
[CS 지식18.] Quantum Computing(양자 컴퓨팅) (2)	2024.11.22
[CS 지식17.] IPsec vs SSL/TLS (0)	2024.11.11

현재글[CS 지식20.] OS 캐시와 디스크 I/O: MySQL, Redis 퍼포먼스 분석

Somaz의 IT 공부 일지