Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://developers.redhat.com/blog/2025/06/23/feature-introduction-multiple-iothreads-openshift-virtualization
개요
이 새로운 기능을 사용하면 VM 디스크 I/O를 여러 제출 스레드에 분산할 수 있으며, 이 스레드는 VM 내부의 여러 디스크 대기열에도 매핑됩니다. 이 두 가지 옵션을 함께 사용하면 VM이 스레드 I/O 부하가 높은 기간 동안 vcpu와 호스트 CPU를 더욱 효율적으로 활용할 수 있으며, 이는 많은 경우 성능을 크게 향상시킬 수 있습니다.
KVM에서 이 기능이 어떻게 구현되는지에 대한 자세한 내용은 IOThread Virtqueue Mapping 에 대한 이 문서 와 RHEL 환경에서 실행되는 VM의 데이터베이스 작업 부하에 대한 성능 향상을 보여주는 이 동반 문서를 참조하세요.
기능 세부 정보
OpenShift Virtualization 4.19는 ioThreadsPolicy 옵션을 확장하여 새로운 supplementalPool 정책을 포함함으로써 이 기능을 VM에 제공합니다. VM 관리자는 supplementalPoolThreadCount 를 선택하여 VM의 I/O 제출에 사용할 호스트 스레드 수를 결정할 수도 있습니다. 이러한 I/O 스레드는 적응형 폴링을 사용하므로 I/O가 수행되지 않을 때 CPU 사이클을 낭비하지 않습니다. 오히려 여러 VCP가 I/O를 수행하는 VM이 단일 제출 스레드 때문에 병목 현상을 겪는 대신 호스트 리소스를 더욱 효율적으로 활용할 수 있도록 합니다.
활성화 방법
이 튜닝이 활성화된 예시 yaml 정의, 16개의 vcpus와 4개의 IOthread가 있는 VM:
spec:
domain:
cpu:
cores: 1
sockets: 16
threads: 1
memory:
guest: 16Gi
ioThreadsPolicy: supplementalPool
ioThreads:
supplementalPoolThreadCount: 4
devices:
blockMultiQueue: true
disks:
- name: rootdisk
disk:
bus: virtio위에 표시된 주요 튜닝 옵션은 다음과 같습니다.
- ioThreads정책
- ioThreads.supplementalPoolThreadCount
- 블록멀티큐
튜닝 팁
여기에 설명된 튜닝을 사용하여 다양한 I/O 워크로드 패턴과 총 워크로드 스레딩 양에 따라 일부 마이크로벤치마크에서 VM 스토리지 성능이 최대 2배 이상 향상되는 것을 측정했습니다. 많은 까다로운 스토리지 워크로드에 이 튜닝 옵션을 고려하는 것이 좋습니다.
- 여러 개의 vcpu가 있는 VM(예: 4개 이상)의 경우 작업 부하 I/O가 다중 스레드/다중 프로세스(즉, 여러 vcpu가 I/O를 수행함)일 가능성이 높으므로 이 튜닝을 활성화하는 것이 좋습니다. 특히 작업 부하가 높은 iodepth를 구동하는 경우 더욱 그렇습니다.
- 평균적인 작업 부하를 처리하기 위해 IOthread 수가 매우 많을 필요는 없다는 점을 명심하세요. ThreadCount를 4로 설정하면 성능이 크게 향상되는 것을 자주 볼 수 있습니다 . 경우에 따라 최대 8개 또는 16개의 스레드가 매우 빠른 스토리지 환경에서는 약간 더 높은 성능을 제공할 수 있습니다.
- IOthread는 기본적으로 오버커밋될 수 있지만, 경우에 따라 “전체” CPU 리소스를 구성하면 성능이 크게 향상될 수 있습니다. 자동 CPU 요청 값에 대한 기본 클러스터 동작 구성에 대한 자세한 내용은 CPU 할당 비율 설명서를 참조하십시오. VM CPU 리소스를 명시적으로 조정하는 방법에 대한 자세한 내용은 튜닝 및 확장 가이드를 참조하십시오 .
더 깊이 파고들기
기술 노트
- 이 새로운 supplementalPool 정책은 작업 부하 환경에서 더 많은 스레드가 필요할 때 디스크당 단일 스레드 전용 IOThread 동작을 제어하는 공유 또는 자동 정책을 대체할 수 있습니다 .
- supplementalPool IOthreads는 모든 VM 디스크에서 자동으로 공유되며 모든 디스크가 매우 활성화되어 있는 경우 여러 디스크를 처리할 수 있을 만큼 충분한 스레드를 구성합니다.
- 요청된 supplementalPoolThreadCount 값은 총 vcpu 값에 추가되며 이는 vmiCPUAllocationRatio 에 의해 결정되는 VM(및 virt-launcher pod)에 자동으로 할당되는 CPU 요청 수에 영향을 미칩니다.
- 예를 들어, 16개의 vcpus와 IO ThreadCount가 4인 VM의 경우:
- 기본 CPUAlloc 비율 10은 (16+4)*.10 = 2개의 CPU 요청을 구성합니다.
- CPU 할당 비율을 “1”로 설정하면 (16+4)*1 = 20개의 CPU 요청이 구성됩니다.
- VM 정의에 구성된 명시적 CPU 요청은 이 기본 동작으로 덮어쓰이지 않습니다.
- 예를 들어, 16개의 vcpus와 IO ThreadCount가 4인 VM의 경우:
- 이 기능을 사용하려면 몇 가지 조건이 필요합니다.
- bus: virtio
- 이것은 핫플러그되지 않은 디스크의 기본 유형입니다.
- 참고: virtio-scsi 지원을 위한 업스트림 작업이 진행 중입니다.
- blockMultiQueue: true
- 이를 통해 호스트 수준 IOthread가 게스트 내부의 여러 대기열에 자동으로 매핑되므로 작업이 vcpu 간에도 적절하게 분산됩니다.
- 참고: 대기열은 자동으로 총 vcpu 수로 설정됩니다.
- io: native
- 이 IO 모드는 volumeMode: Block PVCs를 사용할 때 VM 디스크에 대해 자동으로 구성됩니다.
- 파일 시스템 모드 PVC를 사용하는 경우 사전 할당을 사용하여 이를 활성화할 수 있습니다.
- bus: virtio
- 현재 supplementalPool 정책은 isolateEmulatorThread 또는 dedicatedCpuPlacement 와 함께 사용해서는 안 됩니다 (버그 추적기: CNV-64201 )
저수준 기능 세부 정보
VM 디스크별로 스레드가 어떻게 정의되는지 내부적으로 알아보려면 virt-launcher 포드에서 Libvirt XML을 덤프할 수 있습니다. 예:
# oc exec -it <-n namespace> virt-launcher-xx-xx -- bash bash-5.1$ virsh dumpxml 1
적격한 디스크의 경우, 드라이버 섹션에 정의된 대기열과 드라이브 아래에 나열된 여러 iothreads를 모두 확인해야 합니다. 예를 들어, 스레드가 4개인 경우:
<driver name='qemu' type='raw' cache='none' error_policy='stop' io='native' discard='unmap' queues='$vcpus'>
<iothreads>
<iothread id='1'/>
<iothread id='2'/>
<iothread id='3'/>
<iothread id='4'/>
</iothreads>
</driver>호스트 워커 노드에서 VM의 qemu-kvm pid의 pidstat 출력을 보면 멀티스레드 I/O 기간 동안 iothread의 실제 활용도를 확인할 수도 있습니다. 예:
oc debug node/<host_node> ## note: don’t chroot /host pidstat -t -p <qemu-kvm pid> 5
4개의 iothread가 약 70% 활용된 출력 예:
결론
보시다시피, OpenShift VM에서 이 기능을 활성화하면 멀티스레드 워크로드의 스토리지 성능이 크게 향상될 수 있습니다. 위에서 언급한 지침을 고려하여 이 튜닝 옵션이 VM 스토리지 성능을 크게 향상시킬 수 있는지 평가해 보세요!
향후 성능 및 확장 엔지니어링 블로그 에서 이 기능이 VM 성능을 어떻게 개선할 수 있는지에 대한 더 많은 예를 살펴보세요 !
