iostat 및 iotop: 리눅스 스토리지 병목 현상 진단

리눅스 서버가 느리게 느껴질 때, 가장 먼저 살펴봐야 할 곳 중 하나는 스토리지입니다. iostat은 디스크가 과부하 상태인지 보여주고, iotop은 어떤 프로세스가 부하를 유발하고 있는지 보여줍니다. 이 두 도구를 함께 사용하면 중요한 두 가지 질문에 대한 답을 얻을 수 있습니다. 디스크가 실제로 병목 지점인지, 그렇다면 무엇이 디스크에 과부하를 주고 있는지 말이죠. 이 글에서는 설치 방법, 출력 결과 해석법(현대 하드웨어에서 iostat의 %util 메트릭이 현대 하드웨어에서 어디에 위치하는지 포함), 그리고 증상 파악부터 해결까지의 워크플로우를 다룹니다.

iostat 및 iotop 설치

iostat는 sysstat 패키지에 포함되어 있으며, iotop은 별도로 제공됩니다. 두 가지 모두 설치하십시오:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

Ubuntu에서는 sysstat이 기본적으로 비활성화되어 제공됩니다. 나중에 sar, 다음 파일을 편집하십시오 /etc/default/sysstat를 설정하고 ENABLED="true"를 설정하고 서비스를 재시작하십시오:

sudo systemctl restart sysstat

iotop은 root 권한으로 실행되어야 합니다. RHEL 9 및 그 이후 버전에서는 지연 시간 계정이 기본적으로 비활성화되어 있어, IO 및 SWAPIN 열이 비어 있게 됩니다. 다음 명령어로 활성화하십시오:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

다음 명령어를 추가합니다 kernel.task_delayacct = 1 를 /etc/sysctl.conf 파일에 추가하여 재부팅 후에도 설정이 유지되도록 하십시오.

iostat 출력 읽기

확장 통계 모드로 iostat를 실행하고, 부팅 이후의 평균값만 표시하는 첫 번째 샘플은 무시하십시오:

iostat -xz 2

-x 옵션은 -x 플래그는 확장된 통계를 추가하고, -z 유휴 장치를 숨기며, 2 2초마다 갱신합니다. 중요한 열은 다음과 같습니다:

• await: 큐 대기 시간을 포함하여 I/O 요청이 완료되는 데 걸리는 평균 시간(밀리초 단위). 사용자가 속도 저하를 호소할 때 가장 중요한 수치입니다.
• r/s 그리고 w/s: 읽기 및 쓰기 IOPS. rkB/s 이 수치들을 종합하면 wkB/s 이 수치들은 워크로드가 무작위(높은 IOPS, 낮은 처리량)인지 순차적(낮은 IOPS, 높은 처리량)인지를 알려줍니다.
• aqu-sz: 평균 큐 깊이. HDD의 경우, 1을 지속적으로 초과하면 디스크가 처리 속도를 따라가지 못한다는 의미입니다.
• %util: 장치에 최소 한 건의 진행 중인 I/O가 있었던 시간의 비율. HDD에서는 유용하지만, NVMe에서는 오해의 소지가 있습니다(아래 참조).

간단한 기준값 참고:

사용률(%util)이 어디에 위치하는지

%util 는 대부분의 사람들이 가장 먼저 확인하는 지표이지만, NVMe에서는 이는 명백히 오해를 불러일으킵니다. 커널은 %util "어떤 순간에든 진행 중인 모든 I/O"를 집계하는데, 이는 한 번에 하나의 요청만 처리하는 회전식 디스크에는 적합하지만, 하드웨어 큐를 통해 수천 개의 요청을 병렬로 처리하는 NVMe 장치에는 의미가 없습니다. NVMe 드라이브는 실제 용량의 5% 수준에서 작동하면서도 %util 상태를 유지할 수 있습니다.

NVMe에서는 r_await, w_await, aqu-sz 대신 이 지표를 신뢰하십시오. r_await 1ms 미만으로 유지되고 큐 깊이가 장치의 하드웨어 큐 깊이(대개 1024 이상)보다 훨씬 낮다면, %util 어떻게 표시되든 상관없이 실제로 포화 상태가 아닙니다.

kB/s 대신 MB/s 단위로 빠른 NVMe 성능을 확인하려면:

iostat -xm 1

장기적인 수집을 위해 나중에 애플리케이션 로그와 연관 지을 수 있습니다:

iostat -x -t 5 720 > /var/log/iostat.log

이는 1시간 동안 5초마다 샘플링합니다. sar 동일한 sysstat 패키지의

CPU iowait으로 확인하기

iostat에서 스토리지 부하가 표시되면, %iowait 열을 교차 확인하십시오. %iowait 15~20% 이상 지속되고 await 이 수치가 높으면 병목 현상이 스토리지에서 발생함을 확인합니다. 만약 %iowait 이 높지만 await 정상적으로 보인다면, vmstat 1 를 실행하여 si 및 so 열을 확인하십시오. 스왑 활동이 0이 아닌 경우 메모리 제약 상태이며, 디스크 트래픽은 애플리케이션 I/O가 아닌 페이징을 의미합니다.

iotop 출력 결과 해석

iostat으로 스토리지 병목 현상이 확인되면, iotop을 통해 해당 원인이 되는 프로세스를 파악할 수 있습니다. 다음 명령어로 시작하세요:

sudo iotop -o

- -o 플래그는 유휴 프로세스를 숨기고, I/O를 활발히 수행하는 프로세스만 표시합니다. 주목해야 할 열:

• DISK READ / DISK WRITE: 프로세스별 실시간 처리량. 명백한 I/O 부하를 일으키는 프로세스를 식별합니다.
• IO: 프로세스가 I/O로 인해 차단된 시간의 비율. 50 kB/s만 쓰는 프로세스라도 아주 작은 동기식 fsync() 호출을 수행 중이라면 99%의 IO를 나타낼 수 있습니다. 이 열은 단순한 처리량보다 더 중요합니다.
• SWAPIN: 스왑 페이지를 기다리는 시간의 비율입니다. 이 값이 0이 아니면 시스템이 페이징을 수행 중이며, 귀하의 "저장소 문제"는 실제로 메모리 문제입니다.

다중 스레드 애플리케이션(MySQL, PostgreSQL, Java 워크로드)의 경우, -P, 그리고 -a iotop이 시작된 이후 누적 합계를 계산합니다:

sudo iotop -oPa

`-c` -a 플래그는 한 번에 몇 초 동안만 실행되어 실시간 화면에서는 포착하기 어려운 백업 작업과 같은 간헐적인 워크로드를 감지하는 핵심입니다.

아무도 모니터링하지 않는 야간 시간대에 무인 로깅을 수행하려면:

sudo iotop -botqq -d 10 > /var/log/iotop.log

이 명령은 10초마다 비대화형 스냅샷을 기록합니다. 백업이나 cron 작업의 타임스탬프와 함께 사용하면 사후에 원인을 파악하는 데 도움이 됩니다.

진단 워크플로

대부분의 디스크 I/O 조사 과정은 다음과 같은 단계를 따릅니다:

1. iostat -xz 2 디스크가 실제로 병목 지점인지 확인합니다. 다음을 살펴보세요 await, aqu-sz, 그리고 %iowait를 확인하십시오. 이 항목들이 정상이라면 문제는 스토리지에 있는 것이 아니므로 완전히 다른 곳을 살펴봐야 합니다.
2. iotop -oPa 부하를 유발하는 프로세스를 찾으십시오. 처리량 열보다 I/O 열을 더 주의 깊게 관찰하십시오. 가장 큰 문제를 일으키는 것은 대개 가장 많은 바이트를 이동시키는 프로그램이 아니라, 수많은 작은 동기식 쓰기 작업을 수행하는 프로그램들입니다.
3. lsof -p <pid> 해당 프로세스가 어떤 파일을 다루고 있는지 확인합니다. 이를 통해 일반적으로 워크로드 유형을 즉시 파악할 수 있습니다: 데이터베이스 사전 기록 로그(WAL), 애플리케이션 로그 파일, 백업 마운트 지점, 임시 파일 등입니다.

알아두면 좋은 두 가지 패턴.

다음과 같은 커널 스레드가 보인다면 jbd2/... (ext4 저널)이나 txg_sync (ZFS)와 같은 커널 스레드가 iotop의 라이터 목록 상단에 있다면, 이들은 쓰기를 직접 시작하는 것이 아니라 다른 프로세스의 쓰기에 응답하고 있는 것입니다. 저널 트래픽을 유발하는 사용자 공간 프로세스가 실제 원인입니다. 계속 조사해 보세요.

VPS에서 await 값과 낮은 %util 는 전형적인 '시끄러운 이웃(noisy-neighbour)' 신호입니다. 다른 테넌트가 공유 스토리지를 독점하고 있어, 가상 디스크가 아닌 하이퍼바이저 측에서 I/O 대기열이 발생하고 있는 것입니다. 게스트 내부에서는 이를 확인할 수는 있지만 해결할 수는 없습니다. 해결책은 서비스 제공업체에 문제를 상신하거나, 스토리지 격리가 된 서버로 이전하는 것입니다.

일반적인 I/O 병목 현상 해결

디스크에 어떤 문제가 발생하는지 파악하면, 해결 방법은 대개 간단합니다.

비중요 I/O의 우선순위를 낮춥니다. ionice 프로세스를 유휴 스케줄링 클래스로 이동시키면, 다른 프로세스가 디스크 대역폭을 사용하지 않을 때만 이를 사용하게 됩니다:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

첫 번째 형식은 실행 중인 프로세스의 우선순위를 변경하고, 두 번째 형식은 이미 유휴 클래스에 속한 새로운 프로세스를 시작합니다. iotop 내에서 i 키를 누르면 실행 중인 프로세스의 우선순위를 대화형으로 변경할 수 있습니다.

부하가 높은 워크로드를 더 빠른 저장소로 이동시키세요. iostat에서 데이터베이스 쓰기 작업으로 인해 SATA 디스크에 과부하가 걸린 것으로 나타나고, 같은 시스템 내에 유휴 상태의 NVMe가 있다면 데이터베이스 데이터 디렉터리를 재배치하세요. IOPS의 차이는 수십 배에 달하므로, 이는 가장 효과적인 해결책입니다.

적절한 I/O 스케줄러를 설정하십시오. 최신 커널은 기본적으로 적절하게 설정되어 있지만, 확인해 볼 가치가 있습니다. NVMe 및 SSD의 경우 스케줄러를 none로 설정하십시오. 이 장치는 커널보다 하드웨어에서 큐잉을 더 잘 처리합니다:

echo none > /sys/block/nvme0n1/queue/scheduler

혼합 워크로드를 처리하는 HDD의 경우, mq-deadline 가 일반적인 선택입니다.

noatime 옵션을 사용하여 마운트하십시오. 기본적으로 읽기 작업마다 파일의 마지막 액세스 타임스탬프가 업데이트되어, 읽기마다 쓰기 작업이 발생합니다. 읽기 작업이 많은 파일 시스템에서는 이는 불필요한 I/O입니다. 마운트 옵션에 noatime 를 마운트 옵션에 추가하십시오 /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

버스트성 쓰기 작업이 발생할 경우 writeback을 조정하십시오. RAM이 충분한 서버에서는 기본 더티 페이지 임계값으로 인해 페이지 캐시에 기가바이트 단위의 미기록 데이터가 쌓였다가, 한 번에 대량으로 플러시됩니다. 이를 완화하려면 /etc/sysctl.conf 이 문제를 완화하십시오:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

디스크 자체는 대개 문제가 되지 않습니다. iostat에서 높은 IOPS와 낮은 처리량을 보인다면, 워크로드가 순차적으로 처리될 수 있는 데이터에 대해 무작위 I/O를 수행하고 있거나, 일괄 처리될 수 있는 수많은 작은 쓰기 작업을 실행하고 있는 것입니다. 하드웨어를 탓하기 전에 애플리케이션을 먼저 살펴보세요.

네트워크 속도가 디스크 속도를 앞지를 수 있는 서버에서 스토리지 집약적인 워크로드를 실행 중이라면, FDC의 NVMe 기반 전용 서버를 통해 위의 튜닝을 효율적으로 적용할 수 있는 여유를 확보할 수 있습니다.