디스크 부하: iostat과 iotop

디스크는 "CPU는 놀고 있는데 모든 게 느리다"는 상황의 가장 흔한 원인이에요. 프로세스들은 I/O를 기다리며 멈춰 있고, 부하 평균은 치솟는데 htop에서는 CPU%가 거의 0으로 보이죠. 이걸 숫자로 확인하는 방법을 살펴볼게요.

할당량

노드의 디스크는 NVMe지만 속도는 티어별로 제한돼요. 쓰기는 코어당 60 MB/s이되 최소 60, 최대 400 MB/s를 넘지 않아요. 읽기는 쓰기 속도의 두 배예요. 상한을 넘으면 30초 동안 세 배까지 버스트가 허용돼요. 압축 파일을 푸는 정도나 프로젝트를 빌드하는 데는 충분하지만, 테라바이트를 계속 업로드하기에는 부족하죠.

측정값이 정확히 이 숫자에 도달했다면 상한에 걸린 것이지, 뭔가 고장 난 게 아니에요. 그 이상은 티어를 올리는 수밖에 없어요.

iostat: 전체 그림

apt install -y sysstat       # Debian, Ubuntu
dnf install -y sysstat       # AlmaLinux, CentOS Stream

iostat -xz 2

이 명령은 2초마다 스냅샷을 출력해요. 첫 출력은 부팅 이후의 평균이니 건너뛰세요. vda 또는 sda 줄을 보세요.

• r/s, w/s — 초당 읽기와 쓰기 작업 수예요.
• rkB/s, wkB/s — 메가바이트 단위이니 1024로 나누세요. 위 표와 비교해 보세요.
• await — 작업당 평균 대기 시간(밀리초)이에요. 한 자릿수면 정상이고, 수십에서 수백이면 큐가 쌓인 거예요.
• %util — 디스크가 얼마나 바쁜지를 나타내요. 90~100 %가 꾸준히 유지되면 한계에 부딪힌 거예요.

vmstat 2도 유용해요. wa 열(io wait)은 CPU가 디스크를 기다리는 데 쓰는 시간을 백분율로 보여줘요.

iotop: 누가 쓰고 있는지

apt install -y iotop && iotop -oPa

-o는 활성 프로세스만, -P는 스레드 대신 프로세스를, -a는 실행 이후 누적량을 보여줘요. 1분쯤 지켜보면 진짜 범인을 알 수 있어요. 보통은 데이터베이스, 로그 수집기, 백업 중 하나예요.

대화형 UI 없이 한 번만 확인하려면:

iotop -boPan 3 | head -20

찾은 원인별 대처법

• 저널이 쓰고 있어요. 크기를 제한하세요. journalctl --vacuum-size=200M을 실행하고 /etc/systemd/journald.conf에 SystemMaxUse=200M을 설정하세요. 더 자세한 내용은 systemd 저널을 참고하세요.
• 데이터베이스가 쓰고 있어요. 인덱스가 없어서 전체 테이블 스캔이 돌고 있는지, 버퍼가 너무 작게 설정돼 모든 걸 디스크로 밀어내고 있는지 확인하세요.
• 업무 시간 중 백업이나 rsync. 속도를 제한하세요. rsync --bwlimit=20M을 쓰고, 아카이빙에는 ionice -c3 nice -n19 tar ...를 써서 작업이 양보하도록 하세요.
• 스왑. 디스크가 페이징으로 바쁘다면 문제는 디스크가 아니라 메모리예요. 메모리와 스왑을 읽어보세요.

흔한 실수

dd와 conv=fdatasync로 속도를 측정하고 한 번의 실행 결과로 결론을 내리는 것: 처음 몇 초는 버스트로 돌아가서 부풀려진 결과가 나와요. 올바른 방법은 디스크와 네트워크 속도 벤치마크에 있어요.

디스크가 꽉 차도 "모든 게 느리다"처럼 보여요. 여유 공간이 없으면 서비스가 임시 파일을 쓰지 못하고 멈춰버리죠. 먼저 df -h를 확인하세요. 1초면 돼요.