디스크 I/O 지연이 의심되는데 iostat이나 top 같은 도구로는 정확히 어느 단계(큐잉, 병합, 드라이버 전달, 디바이스 처리)에서 시간이 걸리는지 알기 어려울 때가 있다. blktrace는 커널 블록 계층(Block Layer)의 트레이스포인트를 이용해 이 단계별 소요 시간을 직접 들여다볼 수 있게 해주는 도구다. 이 글에서는 blktrace 설치부터 blkparse/btt를 이용한 결과 분석까지 실습 위주로 정리한다.
blktrace란?
blktrace는 리눅스 블록 디바이스 계층에서 발생하는 I/O 이벤트를 커널 트레이스포인트를 통해 수집하는 도구다. 커널 2.6.17부터 메인라인에 포함되어 있어 별도 커널 패치 없이 사용할 수 있다.
- 실시간 추적, 또는 파일로 저장 후 사후 분석 모두 가능
- HDD/SSD/NVMe 등 블록 디바이스 대부분에 적용 가능
- 큐잉 지연, 병합률, 디바이스 처리 시간 등 I/O 스택 단계별 소요 시간 분석에 사용
설치 및 환경 준비
Ubuntu/Debian 계열에서는 apt로 설치한다.
sudo apt update
sudo apt install blktrace설치 후 버전을 확인한다.
$ blktrace --version
blktrace version 2.0.0기본 개념
리눅스 I/O 스택은 아래처럼 여러 계층을 거친다.
애플리케이션의 read()/write() 호출은 파일시스템(ext4, xfs 등)과 VFS/I/O 스케줄러를 거쳐 Block Layer에서 실제 요청(request)으로 조립된 뒤, 드라이버를 통해 하드웨어 디바이스에 전달된다. blktrace는 이 중 Block Layer 단계에서 발생하는 이벤트(큐잉, 병합, 디스패치, 완료)를 캡처한다.
주요 이벤트 코드 (blkparse 기준)
| 이벤트 코드 | 의미 |
|---|---|
Q | 큐잉 의도(queued) — 아직 실제 request는 만들어지지 않음 |
I | 삽입됨(inserted) — I/O 스케줄러 내부 큐에 request로 등록됨 |
M | 병합됨(merged) — 기존에 삽입된 request와 병합(back/front merge) |
D | 디스패치됨(issued) — 드라이버로 전달됨 |
C | 완료됨(complete) |
즉 하나의 I/O는 대체로 Q → I(또는 M) → D → C 순서로 기록되며, btt는 이 타임스탬프 차이를 이용해 구간별 지연을 계산한다.
blktrace 기본 사용법
디바이스 단위 실시간 추적
sudo blktrace -d /dev/sda -o - | blkparse -i --d /dev/sda: 추적할 디바이스-o -: 표준 출력으로 내보냄blkparse -i -: 표준 입력으로 받은 이진 트레이스를 사람이 읽을 수 있는 형태로 해석
파일로 저장하고 나중에 분석
sudo blktrace -d /dev/sda -o trace_sda이후 저장된 파일을 분석한다.
blkparse -i trace_sda.blktrace.*여러 디바이스 동시 추적
sudo blktrace -d /dev/sda -d /dev/sdb -o trace_all-d를 여러 번 지정하면 각 디바이스별로 trace_all.blktrace.<device>.<cpu> 형태의 파일이 개별 생성된다.
정해진 시간만 추적하기
sudo blktrace -d /dev/sda -o trace_sda -w 10-w 10은 10초 후 자동으로 추적을 종료한다는 뜻이다. 지정하지 않으면 Ctrl+C로 직접 중단할 때까지 계속 기록한다.
btt로 결과 분석
btt는 blkparse 출력을 입력으로 받아 구간별 지연 통계를 계산한다.
blkparse -i trace_sda.blktrace.* -o - | btt -i -출력 예시 항목
| 항목 | 의미 |
|---|---|
| Q2Q | 연속된 요청이 큐잉되는 간격 (요청 발생 빈도) |
| Q2D | 큐잉부터 디스패치(드라이버 전달)까지 걸린 시간 |
| D2C | 디스패치부터 완료까지, 즉 디바이스 자체 처리 시간 |
| Q2C | 큐잉부터 완료까지 전체 소요 시간 |
Q2D가 크면 I/O 스케줄러 대기나 큐 혼잡을, D2C가 크면 디바이스/컨트롤러 자체의 처리 지연을 의심할 수 있다.
실전 예제: SSD와 HDD 비교
같은 워크로드를 SSD와 HDD 각각에서 추적하면 btt 결과로 두 디바이스의 특성 차이를 직접 확인할 수 있다.
sudo blktrace -d /dev/sda -o ssd_trace -w 10
blkparse -i ssd_trace.blktrace.* -o - | btt -i -
sudo blktrace -d /dev/sdb -o hdd_trace -w 10
blkparse -i hdd_trace.blktrace.* -o - | btt -i -일반적으로 SSD는 탐색(seek) 비용이 없어 D2C가 짧고 병합(merge) 이득도 크지 않은 반면, HDD는 헤드 이동 비용 때문에 D2C가 훨씬 크고 인접한 요청을 병합했을 때 성능 이득이 뚜렷하다. 다만 정확한 수치는 컨트롤러, 파일시스템, 워크로드 패턴에 따라 크게 달라지므로 위 명령으로 직접 측정한 btt 출력을 기준으로 판단해야 한다.
사용 시 주의사항
| 주의점 | 설명 |
|---|---|
| root 권한 필요 | 커널 트레이스포인트 접근에 sudo가 필요 |
| 추적 자체의 오버헤드 | 이벤트를 기록하는 동안 약간의 I/O 성능 저하가 발생할 수 있음 |
| 디스크 여유 공간 | 추적 시간이 길거나 I/O가 많으면 트레이스 파일이 빠르게 커짐 |
| NVMe 지원 | 최신 커널에서는 nvme0n1 등 NVMe 디바이스도 동일하게 추적 가능 |
요약
| 단계 | 명령어 예시 |
|---|---|
| blktrace 실행 | blktrace -d /dev/sda -o trace -w 10 |
| 로그 해석 | blkparse -i trace.blktrace.* |
| 통계 분석 | btt -i trace.blktrace.* |