리눅스 cgroup v2 io.max 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

리눅스 cgroup v2의 io.max는 특정 블록 장치에 대해 읽기·쓰기 대역폭이나 IOPS 상한을 거는 인터페이스입니다. 같은 서버에서 백업, 인덱싱, 배치 작업처럼 디스크를 많이 쓰는 작업이 서비스 응답 시간을 흔들 때 검토할 수 있습니다. 다만 모든 I/O 문제를 해결하는 만능 설정은 아니며, 우선순위 조정이 필요한지 절대 상한이 필요한지부터 구분해야 합니다.

2026년 9월 30일 확인 기준 Linux kernel의 cgroup v2 문서는 io.weight를 상대 가중치, io.max를 BPS 또는 IOPS 기반 제한으로 설명합니다. systemd 환경에서는 IOWeight=, IOReadBandwidthMax=, IOWriteBandwidthMax=, IOReadIOPSMax=, IOWriteIOPSMax= 같은 unit 설정이 cgroup v2의 io 컨트롤러와 연결됩니다.

io.max는 언제 쓰는가

기준은 "이 작업이 남는 디스크 용량을 모두 써도 되는가"입니다. 백업이나 로그 압축처럼 늦어져도 괜찮지만 운영 서비스와 같은 장치를 공유하는 작업이라면, 절대 상한을 두는 것이 도움이 될 수 있습니다. io.max는 제한값을 넘는 소비를 허용하지 않는 방식이므로, 장치가 한가해도 설정한 상한을 초과하지 않는다는 점이 핵심입니다.

반대로 여러 작업 사이의 상대 우선순위만 조정하고 싶다면 io.weight가 먼저 후보입니다. weight 방식은 같은 부모 아래 형제 cgroup 사이에서 비율을 조정하는 성격이 강합니다. 절대 속도를 고정하고 싶을 때 io.max, 경쟁 상황에서 더 많이 또는 덜 받게 하고 싶을 때 io.weight로 나누어 생각하면 됩니다.

io.max 파일은 어떤 형식인가

io.max는 non-root cgroup에 존재하는 read-write nested-keyed 파일입니다. 각 줄은 MAJOR:MINOR 장치 번호를 키로 하고, 그 뒤에 읽기·쓰기 제한 값을 붙입니다. Linux kernel 문서는 rbps, wbps, riops, wiops 키를 정의합니다.

# 예: 8:16 장치에 읽기 2MiB/s, 쓰기 120 IOPS 상한
echo "8:16 rbps=2097152 wiops=120" > io.max

여기서 8:16은 블록 장치의 major:minor 번호입니다. 실제 운영에서는 제한하려는 파일 시스템이 어떤 블록 장치 위에 있는지 확인해야 합니다. 단순 파티션이면 비교적 명확하지만, LVM, RAID, dm-crypt, 컨테이너 스토리지 계층처럼 복잡한 구성이면 어느 장치에 제한을 걸어야 하는지 별도로 확인해야 합니다.

rbps, wbps, riops, wiops는 어떻게 고를까

대역폭 제한은 초당 바이트 수 기준입니다. 대용량 순차 읽기·쓰기 작업이 장치를 오래 점유할 때는 rbps 또는 wbps가 이해하기 쉽습니다. 예를 들어 백업 읽기 작업을 제한하려면 rbps, 로그 변환 결과를 많이 쓰는 작업을 제한하려면 wbps를 봅니다.

IOPS 제한은 초당 I/O 횟수 기준입니다. 작은 랜덤 I/O가 많은 작업은 대역폭이 작아 보여도 지연을 크게 만들 수 있으므로 riops나 wiops가 더 직접적일 수 있습니다. 어느 쪽이 맞는지는 작업의 I/O 패턴과 장치 특성에 따라 달라집니다.

키	의미	주로 보는 상황
rbps	읽기 bytes per second 상한	백업, 스캔, 대량 읽기
wbps	쓰기 bytes per second 상한	로그 변환, 덤프 생성, 대량 쓰기
riops	읽기 IOPS 상한	작은 랜덤 읽기 부하
wiops	쓰기 IOPS 상한	작은 랜덤 쓰기 부하

 

 

systemd에서는 어떻게 대응되나

서비스 단위로 관리하는 시스템에서는 직접 cgroup 파일에 쓰기보다 systemd unit 설정을 쓰는 편이 운영하기 쉽습니다. man-pages의 systemd.resource-control(5) 문서는 IOWeight=가 io.weight를, IOReadBandwidthMax=와 IOWriteBandwidthMax=가 io.max의 bandwidth 제한을 제어한다고 설명합니다.

[Service]
IOReadBandwidthMax=/dev/disk/by-id/example-disk 20M
IOWriteIOPSMax=/dev/disk/by-id/example-disk 200

systemd 설정은 장치 경로와 사람이 읽기 쉬운 단위를 받을 수 있다는 장점이 있습니다. 다만 문서가 설명하듯 파일 경로에서 backing block device를 찾는 방식은 단순한 파일 시스템 배치에서 더 잘 맞고, 복잡한 RAID나 볼륨 관리 구성에서는 한계가 있을 수 있습니다. 중요한 서비스라면 설정 후 실제 cgroup 파일과 측정 지표를 함께 확인해야 합니다.

io.max 적용 전 점검 기준

첫째, cgroup v2 계층과 io 컨트롤러가 실제로 사용되는지 확인해야 합니다. cgroup v2는 단일 계층을 사용하며, 컨트롤러는 부모의 cgroup.subtree_control에서 자식에게 활성화됩니다. unit 기반으로 관리한다면 systemd가 만든 cgroup 구조와 resource-control 설정을 기준으로 확인하는 편이 안전합니다.

둘째, 제한 대상 장치를 명확히 잡아야 합니다. io.max의 키는 서비스 이름이나 마운트 경로가 아니라 블록 장치 번호입니다. systemd 설정에서는 장치 노드나 파일 경로를 받을 수 있지만, 그 경로가 어떤 backing device로 해석되는지 운영 환경마다 확인이 필요합니다.

셋째, 상한값은 너무 낮게 시작하지 않는 편이 좋습니다. io.max는 남는 용량이 있어도 더 쓰지 못하게 만드는 설정입니다. 과도하게 낮은 값은 배치 시간이 길어지고, 큐가 밀리며, 오히려 운영 시간대 전체에 부하를 늘릴 수 있습니다. 먼저 관측값을 보고 목표치를 정한 뒤 조금씩 낮추는 방식이 안전합니다.

io.stat은 무엇을 확인하나

io.stat은 cgroup의 I/O 통계를 보는 핵심 파일입니다. Linux kernel 문서는 read bytes, write bytes, I/O 횟수 같은 기본 통계 외에도 설정된 컨트롤러에 따라 추가 필드가 나타날 수 있다고 설명합니다. 제한을 넣었다면 실제 읽기·쓰기 양이 줄었는지, 서비스 지연이 개선됐는지, 배치 완료 시간이 지나치게 늘지 않았는지를 함께 봐야 합니다.

여기서 주의할 점은 io.max 자체가 애플리케이션 성능 목표를 자동으로 맞추는 기능은 아니라는 것입니다. 어떤 장치가 병목인지, 읽기와 쓰기 중 무엇이 문제인지, IOPS와 bandwidth 중 무엇이 지연을 만드는지는 관측으로 확인해야 합니다.

io.max가 맞지 않는 경우

첫째, 작업 간 우선순위만 조정하면 되는 경우입니다. 이때는 io.weight가 더 자연스럽습니다. io.max는 hard limit에 가까운 상한이므로 남는 장치 성능까지 일부러 버릴 수 있습니다.

둘째, 애플리케이션 내부 동시성 문제가 원인인 경우입니다. 너무 많은 worker가 동시에 파일을 열거나, 데이터베이스 쿼리가 비효율적으로 디스크를 읽는다면 cgroup 제한은 증상을 눌러 줄 뿐 원인을 해결하지 못합니다.

셋째, 네트워크 파일 시스템이나 스토리지 가상화 계층처럼 cgroup의 블록 I/O 모델과 직접 맞지 않는 구성이 있을 수 있습니다. 이 경우에는 해당 스토리지 계층의 QoS, 데이터베이스 설정, 작업 스케줄링 기준을 함께 봐야 합니다.

FAQ

Q. io.max를 쓰면 특정 프로세스 하나만 제한되나?

아닙니다. cgroup에 속한 프로세스들의 I/O가 제한 대상입니다. systemd service에 설정하면 보통 그 unit에 속한 프로세스들이 같은 resource-control 기준을 받습니다.

Q. root cgroup에도 io.max를 설정할 수 있나?

cgroup v2 문서는 resource control interface file이 root cgroup에는 없어야 한다고 설명합니다. 일반적으로 제한은 non-root cgroup, 즉 특정 서비스나 하위 그룹에 적용합니다.

Q. bandwidth와 IOPS를 동시에 걸어도 되나?

io.max는 같은 장치 키에 여러 제한 키를 함께 쓸 수 있습니다. 다만 실제 병목이 무엇인지 모르는 상태에서 모두 낮게 잡으면 원인 분석이 어려워집니다. 먼저 bandwidth 또는 IOPS 중 하나를 중심으로 관측하는 편이 낫습니다.

정리하면, io.max는 "이 작업은 이 장치에서 여기까지만 쓰게 하겠다"는 절대 상한 도구입니다. 남는 I/O 성능을 활용해도 되는 작업에는 io.weight를 먼저 보고, 운영 서비스 보호를 위해 배경 작업의 상한이 필요할 때 io.max를 검토하는 것이 기준입니다. 설정 후에는 io.stat, 서비스 지연, 작업 완료 시간을 함께 확인해야 합니다.

이 글은 2026년 9월 30일 기준 Linux kernel cgroup v2 문서와 systemd.resource-control(5) 문서를 바탕으로 정리했습니다.

참고 문서

• Linux kernel documentation: Control Group v2
• man7.org: systemd.resource-control(5)