26M05f

Young-Kyoo Kim·2026년 3월 6일

Linux에서 파일시스템의 읽기/쓰기 성능을 확인하는 가장 간단하고 대중적인 방법은 dd 명령어를 사용하는 것입니다. 별도의 설치 없이 바로 실행 가능하며, 대략적인 성능 지표를 파악하기에 아주 좋습니다.

조금 더 정밀한 분석이 필요하다면 fio를 추천합니다.

1. `dd` 명령어로 하는 초간단 테스트

가장 원시적이지만 확실한 방법입니다.

쓰기 속도 테스트

데이터를 디스크에 실제로 기록하는 속도를 측정합니다.

dd if=/dev/zero of=testfile bs=1G count=1 oflag=dsync

if=/dev/zero: 0으로 채워진 데이터를 입력으로 사용합니다.
of=testfile: 'testfile'이라는 이름으로 파일을 생성합니다.
bs=1G count=1: 1GB 크기의 블록을 1번 씁니다.
oflag=dsync: 캐시를 거치지 않고 실제 디스크에 기록될 때까지 기다립니다. (정확한 물리 속도 측정)

읽기 속도 테스트

생성한 파일을 다시 읽어 들이는 속도를 측정합니다.

# 먼저 캐시를 비워야 정확한 측정이 가능합니다 (루트 권한 필요)
sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

dd if=testfile of=/dev/null bs=1G count=1

2. `fio`를 이용한 정밀 테스트 (권장)

dd는 순차적인 읽기/쓰기만 측정할 수 있지만, 실제 시스템 성능은 랜덤 읽기/쓰기(IOPS)가 더 중요합니다. fio는 이를 전문적으로 측정합니다.

설치

sudo apt install fio  # Ubuntu/Debian
sudo yum install fio  # CentOS/RHEL

실행 (랜덤 읽기/쓰기 혼합 테스트)

fio --name=randrw_test --ioengine=libaio --rw=randrw --bs=4k --direct=1 --size=512M --numjobs=1 --runtime=30 --group_reporting

--rw=randrw: 랜덤 읽기/쓰기를 혼합해서 테스트합니다.
--bs=4k: OS의 기본 블록 크기인 4KB 단위로 테스트합니다 (실제 체감 성능에 중요).
--direct=1: 버퍼 캐시를 사용하지 않고 직접 I/O를 수행합니다.

3. 요약 및 주의사항

방법	장점	단점
`dd`	설치 불필요, 사용법이 매우 간단함	단순 순차 속도만 측정 가능, 신뢰도 낮음
`fio`	실제 워크로드(랜덤 I/O) 측정 가능, 전문적임	옵션이 복잡하고 별도 설치 필요

[!WARNING]
주의: 테스트가 끝나면 생성된 testfile이나 randrw_test.0.0 같은 임시 파일은 용량 확보를 위해 삭제해 주세요. (rm testfile)

어느 정도의 성능(예: SSD인지 HDD인지, 혹은 클라우드 인스턴스인지)을 기대하고 계신가요? 상황에 맞는 더 구체적인 fio 옵션을 알려드릴 수도 있습니다.

SSD의 진정한 성능을 확인하려면 단순한 순차 속도보다는 IOPS(초당 입출력 횟수)와 Latency(지연 시간)를 확인하는 것이 핵심입니다. SSD의 특성에 맞춰 부하를 제대로 줄 수 있는 세부 설정값들을 정리해 드릴게요.

SSD 성능 측정을 위한 `fio` 정밀 옵션

SSD는 여러 작업을 동시에 처리하는 능력이 탁월하므로, iodepth(비동기 처리 깊이)를 조절하는 것이 중요합니다.

1. 4K 랜덤 읽기/쓰기 (IOPS 측정)

가장 체감 성능에 가까운 테스트입니다. 운영체제가 수많은 작은 파일을 읽고 쓸 때의 성능을 보여줍니다.

fio --name=ssd_randrw \
  --filename=testfile \
  --ioengine=libaio \
  --direct=1 \
  --rw=randrw \
  --bs=4k \
  --size=1G \
  --numjobs=4 \
  --iodepth=32 \
  --runtime=60 \
  --time_based \
  --group_reporting

--ioengine=libaio: 리눅스에서 비동기 I/O를 수행하기 위한 엔진입니다.
--iodepth=32: 한 번에 32개의 I/O 요청을 쌓아둡니다. NVMe SSD라면 32~64 정도가 적당합니다.
--numjobs=4: 4개의 프로세스를 동시에 띄워 부하를 줍니다. (CPU 코어 수에 맞춰 조절)
--time_based: 지정한 runtime 동안 계속 테스트를 반복합니다.

2. 순차 읽기/쓰기 (처리량 MB/s 측정)

대용량 파일을 복사할 때의 성능을 확인하고 싶을 때 사용합니다.

fio --name=ssd_seq_read \
  --filename=testfile \
  --ioengine=libaio \
  --direct=1 \
  --rw=read \
  --bs=1M \
  --size=2G \
  --numjobs=1 \
  --iodepth=8 \
  --runtime=30 \
  --group_reporting

--bs=1M: 블록 크기를 키워 대역폭(Bandwidth)을 최대한 끌어올립니다.
--rw=read: 쓰기 성능을 보려면 write로 변경하세요.

결과 해석하는 방법 (핵심 지표)

fio 실행 후 출력되는 리포트에서 다음 항목들을 중점적으로 보세요.

read/write: IOPS=xxx: 초당 처리된 작업 수입니다. 높을수록 좋습니다.
bw=xxxMB/s: 초당 전송 속도입니다.
lat (msec/usec): 지연 시간입니다. 낮을수록 응답 속도가 빠른 SSD입니다. 특히 99.00th 백분위수 지연 시간이 낮아야 안정적인 성능입니다.

💡 팁: 더 정확한 측정을 원하신다면?

파일 생성: --filename 옵션으로 경로를 지정할 때, 테스트하려는 SSD가 마운트된 경로(예: /mnt/ssd/testfile)를 정확히 지정하세요.
Preconditioning: SSD는 빈 상태와 데이터가 가득 찬 상태의 성능이 다릅니다. 더 엄격한 테스트를 원하신다면 --size를 10G 이상으로 늘려 테스트해 보세요.

테스트 결과에서 특정 수치가 예상보다 낮게 나오나요? 그렇다면 현재 마운트 옵션이나 연결된 슬롯(SATA3 vs NVMe Gen4 등)을 점검해 드릴 수 있습니다. 어떤 환경인가요?

containerd의 임시 파일(Snapshot, Overlay 레이어 등)이 쌓이는 공간은 주로 작은 파일의 빈번한 생성/삭제와 메타데이터 업데이트가 핵심입니다. 따라서 단순한 대역폭(MB/s)보다는 저지연(Low Latency)과 높은 IOPS를 견딜 수 있는지 테스트하는 것이 적절합니다.

컨테이너 환경의 특성을 반영한 fio 최적 옵션을 제안해 드립니다.

1. Containerd 환경 맞춤형 테스트 옵션

이 옵션은 컨테이너가 레이어를 쌓거나 로그를 남길 때 발생하는 4K~16K 사이의 혼합 I/O 상황을 가정합니다.

fio --name=containerd_temp_test \
  --directory=/var/lib/containerd/tmp \
  --ioengine=libaio \
  --direct=1 \
  --rw=randrw \
  --rwmixread=70 \
  --bsrange=4k-16k \
  --size=2G \
  --numjobs=8 \
  --iodepth=16 \
  --runtime=60 \
  --time_based \
  --group_reporting \
  --refill_buffers

💡 주요 옵션 설명 (왜 이렇게 설정했나?)

--directory=/var/lib/containerd/tmp: containerd의 실제 임시 경로(또는 마운트된 경로)를 지정하여 해당 파일시스템의 특성을 직접 확인합니다.
--rw=randrw --rwmixread=70: 컨테이너 환경은 이미지 레이어를 읽으면서 로그/임시 데이터를 쓰는 작업이 동시에 일어납니다. 읽기 70%, 쓰기 30% 설정이 일반적인 워크로드와 유사합니다.
--bsrange=4k-16k: 고정된 4K보다는 컨테이너 메타데이터와 로그 파일 크기를 고려해 범위를 지정했습니다.
--numjobs=8: 여러 개의 컨테이너가 동시에 구동되는 멀티테넌시 환경을 시뮬레이션합니다.
--refill_buffers: SSD의 데이터 압축 기능을 무력화하여 실제 물리적인 쓰기 부하를 정확히 측정합니다.

2. 결과에서 집중해서 볼 지표 (Latency)

임시 파일 저장소에서 가장 중요한 것은 clat (Completion Latency)입니다. 파일이 생성될 때 시스템이 얼마나 빨리 응답하느냐가 컨테이너 시작 속도나 앱 반응성에 직결됩니다.

lat (usec) 99.00th: 99%의 작업이 완료되는 시간입니다. SSD라면 이 수치가 밀리초( $ms$ ) 단위로 튀지 않고 마이크로초( $\mu s$ ) 대를 유지해야 안정적입니다.
fsync 지표: 만약 데이터의 안전성이 중요한 임시 파일(데이터베이스 임시 테이블 등)이라면, 옵션에 --fsync=1을 추가하여 커밋 속도를 확인하는 것도 좋습니다.

3. 추가 점검 사항

임시 파일이 쌓이는 속도가 너무 빠르거나 성능이 안 나온다면 다음을 확인해 보세요:

Disk Full 상황: SSD는 용량이 80~90% 이상 차면 쓰기 성능이 급격히 저하됩니다. (df -h로 확인)
Inodes 부족: 아주 작은 임시 파일이 수만 개 생기면 용량은 남았는데 Inode가 부족해 에러가 날 수 있습니다. (df -i로 확인)
Trim 지원: fstrim 명령어가 주기적으로 실행되는지 확인하여 SSD 셀의 성능 하락을 방지하세요.

혹시 특정 컨테이너가 "Disk I/O Error"를 내뿜어서 테스트하시려는 건가요? 그렇다면 실제 오류 로그를 바탕으로 설정을 더 다듬어 드릴 수 있습니다. 어느 경로에 마운트해서 사용 중이신가요?

노드 간 네트워크 성능 테스트는 단순히 "인터넷이 빠르냐"를 보는 것이 아니라, 대역폭(Bandwidth), 지연 시간(Latency), 그리고 패킷 손실(Packet Loss)을 확인하는 것이 핵심입니다.

가장 표준적으로 사용되는 도구 3가지를 정리해 드립니다.

1. iperf3 (대역폭 측정의 표준)

두 지점 간의 최대 전송 속도를 측정할 때 가장 많이 사용합니다. 한쪽은 서버, 한쪽은 클라이언트로 동작합니다.

설치

sudo apt install iperf3  # Ubuntu/Debian
sudo yum install iperf3  # CentOS/RHEL

실행 방법

A 노드 (수신 측/서버):

iperf3 -s

B 노드 (송신 측/클라이언트):

# -t: 테스트 시간(초), -P: 병렬 스트림 수(성능 극대화)
iperf3 -c [A 노드 IP] -t 10 -P 4

2. qperf (지연 시간 및 대역폭 상세 측정)

iperf3보다 더 상세한 지연 시간(Latency)과 TCP/UDP 성능을 한 번에 볼 수 있어 대규모 클러스터(Kubernetes 노드 간 등) 점검 시 유용합니다.

실행 방법

A 노드 (서버): qperf 실행 후 대기
B 노드 (클라이언트):

# TCP 대역폭과 지연 시간을 동시에 측정
qperf [A 노드 IP] tcp_bw tcp_lat

tcp_bw: Bandwidth (대역폭)
tcp_lat: Latency (지연 시간 - 낮을수록 좋음)

3. Netperf 또는 Netcat (간이 테스트)

별도 도구 설치가 어려운 환경에서 nc(netcat)를 이용해 데이터 전송 시간을 측정할 수 있습니다.

# A 노드: 포트 열고 데이터 받기
nc -l 12345 > /dev/null

# B 노드: 1GB 데이터를 보내며 시간 측정
dd if=/dev/zero bs=1M count=1024 | time nc [A 노드 IP] 12345

💡 컨테이너/쿠버네티스 환경이라면?

만약 containerd를 사용하는 K8s 환경에서 노드 간 통신을 테스트하신다면 다음 사항을 꼭 체크하세요.

MTU 값 확인: 노드 간 네트워크 장비와 컨테이너 네트워크(CNI, 예: Calico/Flannel)의 MTU 값이 맞지 않으면 패킷 파편화로 성능이 급격히 떨어집니다.
UDP 테스트: 컨테이너 간 통신(VXLAN 등)은 UDP 캡슐화를 사용하는 경우가 많습니다. iperf3 -u 옵션으로 UDP 성능을 별도로 보세요.
PPS(Packet Per Second): 작은 패킷을 대량으로 주고받는 환경이라면 iperf3 --length 64 처럼 작은 버퍼 크기로 테스트하여 초당 처리량을 확인해야 합니다.

결과 분석 팁

Bandwidth: 네트워크 카드의 물리적 한계(1G, 10G 등)에 근접하는가?
Retr (Retransmission): iperf3 결과에 재전송(Retr) 수치가 높다면 네트워크 혼잡이나 케이블/스위치 불량을 의심해야 합니다.

어떤 구간(예: 동일 랙 내 노드 vs 다른 리전 노드)의 성능이 궁금하신가요? 구간에 따라 기대 수치가 달라질 수 있습니다.

Young-Kyoo Kim

engineer

이전 포스트

26M5d

다음 포스트

26M05f

1. `dd` 명령어로 하는 초간단 테스트

쓰기 속도 테스트

읽기 속도 테스트

2. `fio`를 이용한 정밀 테스트 (권장)

설치

실행 (랜덤 읽기/쓰기 혼합 테스트)

3. 요약 및 주의사항

SSD 성능 측정을 위한 `fio` 정밀 옵션

1. 4K 랜덤 읽기/쓰기 (IOPS 측정)

2. 순차 읽기/쓰기 (처리량 MB/s 측정)

결과 해석하는 방법 (핵심 지표)

💡 팁: 더 정확한 측정을 원하신다면?

1. Containerd 환경 맞춤형 테스트 옵션

💡 주요 옵션 설명 (왜 이렇게 설정했나?)

2. 결과에서 집중해서 볼 지표 (Latency)

3. 추가 점검 사항

1. iperf3 (대역폭 측정의 표준)

설치

실행 방법

2. qperf (지연 시간 및 대역폭 상세 측정)

실행 방법

3. Netperf 또는 Netcat (간이 테스트)

💡 컨테이너/쿠버네티스 환경이라면?

결과 분석 팁

26M5d

26M11a

0개의 댓글

26M05f

1. dd 명령어로 하는 초간단 테스트

쓰기 속도 테스트

읽기 속도 테스트

2. fio를 이용한 정밀 테스트 (권장)

설치

실행 (랜덤 읽기/쓰기 혼합 테스트)

3. 요약 및 주의사항

SSD 성능 측정을 위한 fio 정밀 옵션

1. 4K 랜덤 읽기/쓰기 (IOPS 측정)

2. 순차 읽기/쓰기 (처리량 MB/s 측정)

결과 해석하는 방법 (핵심 지표)

💡 팁: 더 정확한 측정을 원하신다면?

1. Containerd 환경 맞춤형 테스트 옵션

💡 주요 옵션 설명 (왜 이렇게 설정했나?)

2. 결과에서 집중해서 볼 지표 (Latency)

3. 추가 점검 사항

1. iperf3 (대역폭 측정의 표준)

설치

실행 방법

2. qperf (지연 시간 및 대역폭 상세 측정)

실행 방법

3. Netperf 또는 Netcat (간이 테스트)

💡 컨테이너/쿠버네티스 환경이라면?

결과 분석 팁

26M5d

26M11a

0개의 댓글

1. `dd` 명령어로 하는 초간단 테스트

2. `fio`를 이용한 정밀 테스트 (권장)

SSD 성능 측정을 위한 `fio` 정밀 옵션