1. HDD 성능 최적화: 병합(Merge)과 정렬(Sort)

HDD는 물리적 헤드 이동 비용이 크기 때문에 커널 I/O 스케줄러가 두 가지 최적화를 수행한다.

병합 (Merge)

인접한 I/O 요청을 하나로 합쳐 헤드 이동 횟수와 시스템 콜 오버헤드를 줄인다.

요청 A: sector 100~107
요청 B: sector 108~115
→ 병합: sector 100~115 한 번에 처리

• Back merge: 새 요청이 기존 요청 뒤에 붙는 경우 (가장 일반적)
• Front merge: 새 요청이 기존 요청 앞에 붙는 경우

정렬 (Sort) — 엘리베이터 알고리즘

요청을 섹터 번호 순으로 정렬해 헤드가 한 방향으로 쭉 이동하며 처리한다.

입력 순서: 500 → 100 → 300 → 800
정렬 후:   100 → 300 → 500 → 800

→ Seek time(탐색 시간) 최소화

핵심: SSD는 탐색 시간이 없으므로 정렬이 오히려 지연을 유발 → NOOP/none 스케줄러 권장

2. I/O 스케줄러와 cgroup의 관계

cgroup이 **정책(얼마나 쓸 수 있는지)**을 정의하면, I/O 스케줄러가 그 정책을 실제 디스크 요청 순서로 구현한다.

프로세스 → cgroup (그룹화) → I/O 스케줄러 (자원 배분)

cgroup v1 — blkio 서브시스템

cgroup v2 — io 서브시스템

• blkio → io로 통합, 스케줄러 독립적 설계
• BFQ 스케줄러와 결합 시 컨테이너/프로세스별 I/O QoS 보장
• Docker/k8s 기본 환경

3. Deadline 스케줄러가 데이터베이스에 적합한 이유

Deadline의 3가지 큐

1. Sort queue   — 섹터 순 정렬 처리 (평상시)
2. Read FIFO    — 만료 시간 500ms
3. Write FIFO   — 만료 시간 5000ms

평소엔 Sort queue로 처리하다가, FIFO queue에서 만료된 요청이 생기면 즉시 우선 처리.

데이터베이스에 적합한 3가지 이유

CFQ의 문제점

CFQ는 공평한 배분이 목적이라, DB 백그라운드 쓰기(checkpoint)가 큐를 점유하면 SELECT 요청이 starvation에 빠질 수 있다.

스케줄러 선택 기준 요약