VM 환경에서 CPU steal time은 무엇을 의미할까?

운영 서버에서 자원 효율이 중요한 이유

운영 중인 서버 자원을 효율적으로 사용하기 위한 방법 중 하나로 가상화 환경을 고려할 수 있습니다.

 

VM은 Virtual Machine, 즉 가상화 환경 위에서 동작하는 가상 머신을 의미합니다.

 

VM은 물리 서버의 CPU, 메모리, 디스크, 네트워크를 직접 사용하는 것이 아니라,

하이퍼바이저(Hypervisor)가 제공하는 vCPU, vMemory, vDisk, vNIC과 같은 가상 자원을 사용합니다.

 

VM 환경에서는 CPU, 메모리, 디스크, 네트워크 지표를 함께 보되,

각 지표가 Guest OS 내부 문제인지 하이퍼바이저 계층의 문제인지 구분해서 해석해야 합니다.

 

가상화 환경 성능의 구성

가상화 환경에서의 성능은 단순히 CPU 하나로만 결정되지 않습니다.

 

VM은 하이퍼바이저를 통해 여러 종류의 가상 자원을 제공받기 때문에, CPU, 메모리, 디스크, 네트워크, 그리고 하이퍼바이저 계층을 함께 살펴봐야 합니다.

구성 요소	VM에서 보이는 형태	주요 확인 지표
CPU	vCPU	%usr, %sys, %idlle, %steal, load average
Memory	vMemory	used, free, cache, swap
Disk	vDisk	%iowait, IOPS, latency
Network	vNIC	throughput, packet drop, latency
Hypervisor	Xen	CPU scheduling, overcommit, steal time

 

VM 환경에서는 CPU 사용률만으로 성능을 판단하면 안 됩니다.

 

VM은 물리 CPU를 직접 사용하는 것이 아니라 하이퍼바이저가 제공하는 vCPU를 사용하기 때문에,

하이퍼바이저로부터 CPU 시간을 제대로 배정받고 있는지도 함께 확인해야 합니다.

 

이번 글에서는 가상화 환경의 여러 성능 요소 중 CPU 영역에 집중합니다.

 

특히 Xen 기반 Ubuntu VM에서 CPU steal time이 무엇인지 이해하고,

mpstat, vmstat, top을 이용해 실제로 어떻게 확인하고 해석할 수 있는지 실습을 진행해보겠습니다.

 

 

CPU steal time이란?

가상화 환경의 구조를 단순화하면 다음과 같습니다.

-- 가상화 구조 예시

Physical Server
    ├─ Physical CPU
    ├─ Memory
    ├─ Disk
    └─ Network
        ↓
Hypervisor, Xen
        ↓
VM
    ├─ vCPU
    ├─ vMemory
    ├─ vDisk
    └─ vNIC
        ↓
Guest OS, Ubuntu

 

CPU steal time은 VM이 CPU를 사용하려 했지만, 하이퍼바이저가 물리 CPU 시간을 배정하지 못해 기다린 시간을 의미합니다.

즉, VM 내부의 프로세스는 CPU를 사용하려고 했지만, 하이퍼바이저가 해당 VM의 vCPU에 실제 물리 CPU 시간을 배정하지 못해 대기한 시간이 CPU steal time으로 기록됩니다.

이러한 대기는 같은 물리 호스트의 다른 VM과 CPU를 경쟁하거나, 하이퍼바이저의 CPU 스케줄링 정책, CPU overcommit 등의 이유로 발생할 수 있습니다.

 

예를 들어 특정 측정 구간에서 다음과 같은 값이 나타났다고 가정하겠습니다.

VM 내부 CPU 사용 시간: 40%
CPU steal time: 20%

 

이 경우 전체 vCPU 시간 중 40%는 VM 내부 작업을 처리하는 데 사용되었고,

20%는 VM이 CPU를 사용하려 했지만 하이퍼바이저로부터 실제 CPU 시간을 배정받지 못해 기다린 시간으로 해석할 수 있습니다.

 

즉, CPU steal time이 지속적으로 높다면 VM 내부 애플리케이션 문제만이 아니라

물리 호스트의 CPU 경합, CPU overcommit, 하이퍼바이저의 스케줄링 지연과 같은 가상화 계층의 문제를 함께 의심해야 합니다.

 

다만 Guest VM 내부에서는 하이퍼바이저의 실제 자원 배분 상태를 완전히 확인할 수는 없습니다.

 

대신 CPU steal time을 통해 VM이 하이퍼바이저로부터 CPU 시간을 충분히 배정받고 있는지 간접적으로 추정할 수 있습니다.

이제 실제 VM에서 이 값이 어떻게 보이는지 살펴보겠습니다.

실습 환경 확인

먼저 이 서버가 실제로 VM인지 확인하겠습니다.

명령어	목적	확인할 내용
fastfetch	서버 전체 요약 정보 확인	OS, Kernel, Host, CPU, Memory, Disk
systemd-detect-virt	가상화 환경 여부 확인	Xen, KVM, VMware 등
lscpu	CPU와 가상화 관련 상세 정보 확인	vCPU 개수, Hypervisor vendor, Virtualization type

 

 

fastfetch

 

fastfetch 명령어를 실행한 화면

 

$ systemd-detect-virt
xen

 

 

lscpu

 

lscpu 명령어를 실행한 화면

 

 

 

실행 결과를 정리하면 다음과 같습니다.

OS: Ubuntu 24.04.4 LTS
Host: HVM domU
Virtualization: Xen
Virtualization type: full
Hypervisor vendor: Xen
CPU(s): 4

 

systemd-detect-virt 결과는 xen으로 나타났고, lscpu 결과에서도 Hypervisor vendor: Xen을 확인할 수 있었습니다.

또한 CPU(s): 4는 Guest OS에서 4개의 CPU가 보인다는 의미이며, 현재 VM에 4개의 vCPU가 할당된 것으로 해석할 수 있습니다.

 

CPU 상태 확인

CPU 상태를 확인하기 위해 top, vmstat, mpstat을 사용할 수 있습니다.

 

세 명령어 모두 CPU steal time을 확인할 수 있지만, 보여주는 관점이 다릅니다.

 

명령어	특징	장점
top	실시간 프로세스와 CPU 상태 확인	현재 어떤 프로세스가 CPU를 쓰는지 보기 좋음
vmstat	시스템 전체 상태를 간단히 주기적으로 출력	CPU, memory, I/O, steal time을 한 번에 보기 좋음
mpstat	CPU 사용률을 자세히 출력	전체 CPU와 vCPU별 %steal 확인에 좋음

 

top은 실시간 프로세스 관찰에 좋고, vmstat은 전체 시스템 상태를 간단히 보는 데 좋으며, mpstat은 CPU별 사용률을 자세히 분석하는 데 좋습니다.

 

mpstat으로 vCPU별 CPU steal time 확인

먼저 mpstat으로 vCPU별 CPU steal time을 확인하겠습니다.

sudo apt update
sudo apt install -y sysstat

mpstat -P ALL 1 10

 

mpstat -P ALL 1 10 명령은 전체 CPU와 각 vCPU별 CPU 사용률을 1초 간격으로 10번 출력합니다.

여기서 ALL은 전체 평균뿐 아니라 CPU 0, CPU 1, CPU 2, CPU 3처럼 각 vCPU별 사용률도 함께 확인하겠다는 의미입니다.

 

mpstat -P ALL 1 10 명령어 실행 화면

 

출력에서 주로 볼 항목은 다음입니다.

%usr     사용자 영역에서 사용한 CPU 시간 비율
%sys     커널 영역에서 사용한 CPU 시간 비율
%iowait  I/O 요청 완료를 기다린 시간 비율
%idle    실행할 작업이 없어 CPU가 유휴 상태였던 시간 비율
%steal   VM이 실행 가능한 상태였지만 하이퍼바이저로부터 물리 CPU 시간을 배정받지 못해 기다린 시간 비율

 

이번 평상시 측정 결과에서 %steal 값은 0 또는 낮은 수준으로 나타났습니다.

즉, 측정 시점에는 이 VM이 하이퍼바이저로부터 CPU 시간을 기다리는 상황이 거의 없었다고 볼 수 있습니다.

 

 

vmstat과 top으로 전체 시스템 상태와 실시간 CPU 상태를 함께 확인할 수 있습니다.

 

vmstat으로 전체 시스템 상태 확인

vmstat 1 10

 

vmstat 1 10 실행 화면

 

 

vmstat의 첫 번째 출력은 현재 1초 구간만의 값이 아니라 부팅 이후 누적 평균에 가까운 값으로 보일 수 있습니다.

따라서 현재 상태를 해석할 때는 두 번째 줄 이후의 반복 출력 값을 중심으로 보는 것이 좋습니다.

 

us  사용자 영역 CPU 사용률
sy  커널 영역 CPU 사용률
id  idle 시간
wa  I/O 대기 시간
st  steal time

 

여기서 st 값이 CPU steal time입니다. 이번 측정 결과에서 st 값이 0에 가깝다면,

측정 시점 기준으로 현재 VM이 하이퍼바이저로부터 CPU 시간을 기다리는 상황은 거의 없었다고 해석할 수 있습니다.

 

또한 wa 값이 낮다면 디스크 I/O 대기 역시 크지 않은 상태로 볼 수 있습니다.

 

r 컬럼은 실행 중이거나 CPU 실행을 기다리는 프로세스 수를 의미합니다.

 

현재 VM은 4 vCPU 환경이므로 r 값이 지속적으로 4를 크게 넘는다면 CPU 대기열이 증가하고 있다고 볼 수 있습니다.

 

top으로 실시간 CPU 상태 확인

top

 

top 실행 화면

 

 

top은 CPU 상태와 동시에 어떤 프로세스가 CPU를 많이 사용하고 있는지 확인할 수 있다는 장점이 있습니다.

 

상단의 CPU 요약 영역에는 다음과 같은 항목이 표시됩니다.

us  사용자 영역 CPU 사용률
sy  커널 영역 CPU 사용률
id  idle 시간
wa  I/O 대기 시간
st  steal time

 

여기서 st 값이 높다면 VM이 CPU를 사용하려 했지만 하이퍼바이저로부터 실제 CPU 시간을 충분히 배정받지 못하고 있을 가능성을 의심할 수 있습니다.

 

 

CPU 부하 테스트와 steal time 관찰

CPU 부하 상황에서 CPU 사용률과 CPU steal time이 어떻게 달라지는지 관찰해보겠습니다.

 

먼저 이해해야 할 점은 stress-ng는 내 VM 내부에 CPU 부하를 만드는 도구라는 것입니다.

 

즉, VM 내부의 %usr 값을 증가시키고 %idle 값을 감소시킬 수는 있지만, CPU steal time을 반드시 증가시키는 도구가 아닙니다.

 

CPU steal time은 내 VM이 CPU를 사용하려는 상태에서 하이퍼바이저가 실제 물리 CPU 시간을 즉시 배정하지 못할 때 증가합니다.

 

 

CPU 부하를 발생시키기 위해 stress-ng를 설치합니다.

sudo apt install -y stress-ng

 

실제 운영 중인 서버에 직접 부하 테스트를 수행하면 서비스에 영향을 줄 수 있습니다.

따라서 이번 실습은 운영 서비스에 영향이 없는 개발용 VM 또는 테스트 환경에서 제한된 시간 동안 수행하였습니다.

 

1단계: 평상시 상태 저장

먼저 CPU 부하를 발생시키기 전의 상태를 확인합니다.

mpstat -P ALL 1 30

 

이 결과를 통해 평상시의 %usr, %idle, %steal 값을 확인합니다.

 

평상시 상태에서 %steal 값이 0 또는 매우 낮은 수준이라면, 측정 시점 기준으로 하이퍼바이저로부터 CPU 시간을 기다리는 상황이 거의 없었다고 해석할 수 있습니다.

 

평상시 상태를 확인한 이미지

 

2단계: 부하 중 CPU 상태 관찰 준비

CPU 부하가 발생하는 동안 상태 변화를 보기 위해, 먼저 모니터링용 터미널에서 다음 명령어를 실행합니다.

mpstat -P ALL 1

 

이 명령을 실행한 상태에서 다른 터미널을 열어 CPU 부하를 발생시킵니다.

 

 

3단계: 다른 터미널에서 CPU 부하 발생

다른 터미널에서 다음 명령어를 실행합니다.

stress-ng --cpu 4 --timeout 60s --metrics-brief

 

 

명령어를 실행한 화면

 

현재 VM은 4개의 vCPU가 할당되어 있으므로 --cpu 4 옵션을 사용했습니다.

 

이는 VM 내부에서 4개의 CPU worker를 실행하여 vCPU 개수만큼 CPU 부하를 발생시키겠다는 의미입니다.

 

 

4단계: 부하 중 CPU 상태 확인

부하가 발생하는 동안 mpstat 결과에서 다음 항목을 확인합니다.

%usr    VM 내부에서 사용자 프로세스가 CPU를 사용한 시간
%idle   CPU가 유휴 상태였던 시간
%steal  VM이 CPU를 사용하려 했지만 하이퍼바이저로부터 CPU 시간을 받지 못해 기다린 시간

 

부하가 발생한 화면

 

 

부하 발생 전과 부하 발생 중의 상태를 비교하면 다음과 같이 정리할 수 있습니다.

 

구분	%usr	%idel	%steal	해석
평상시	낮은 수준	높은 수준	0 또는 낮음	VM 내부 CPU 여유가 있고, 하이퍼바이저 대기 시간이 거의 없음
부하 중	평상시보다 증가	평상시보다 감소	0 또는 낮음	VM 내부 CPU 부하는 증가했지만, 하이퍼바이저 대기는 지속적으로 증가하지 않음

 

평상시 %steal은 0 또는 낮은 수준이었으며, 부하 중에도 %steal은 지속적으로 상승하지 않았습니다.

 

반면 stress-ng 실행 후에는 %usr 값이 증가하고 %idle 값이 감소했습니다. 즉, VM 내부에서는 CPU 부하가 실제로 발생했습니다.

이 결과는 stress-ng가 VM 내부 CPU 부하를 만드는 도구일 뿐, CPU steal time을 직접 증가시키는 도구는 아니라는 점을 보여줍니다.

 

CPU steal time이 증가하려면 단순히 VM 내부에서 CPU를 많이 사용하는 것만으로는 부족합니다.

 

VM이 CPU를 사용하려는 상태에서, 하이퍼바이저 또는 물리 호스트 수준의 CPU 경합으로 인해 vCPU가 실제 물리 CPU 시간을 기다리는 상황이 함께 발생해야 합니다.

 

이번 실습에서는 VM 내부 CPU 부하는 만들 수 있었지만, 하이퍼바이저 또는 물리 호스트 수준의 CPU 경합은 관찰되지 않았습니다.

 

따라서 %usr 값은 증가하고 %idle 값은 감소했지만, %steal 값은 0 또는 낮은 수준으로 유지되었습니다.

 

이는 측정 시점 기준으로 하이퍼바이저가 이 VM에 CPU 시간을 비교적 원활하게 배정하고 있었다는 의미로 해석할 수 있습니다.

 

 

CPU steal time을 실제로 증가시키려면?

CPU steal time의 증가를 더 명확하게 관찰하려면 Guest VM 내부의 부하만으로는 한계가 있습니다.

CPU steal time은 하이퍼바이저가 물리 CPU 시간을 충분히 배정하지 못할 때 증가하기 때문에, 다음과 같은 조건이 필요합니다.

- 같은 물리 호스트에 있는 다른 VM에서도 동시에 CPU 부하 발생
- 하이퍼바이저 수준에서 CPU overcommit 발생
- Xen dom0에서 vCPU pinning으로 여러 VM을 같은 물리 CPU에 배치
- VM에 CPU cap 또는 quota 설정
- 운영 피크 시간대에 다른 VM과 CPU 경합 발생

 

 

하지만 현재 실습 환경은 Guest VM 내부입니다.

 

Guest VM 내부에서는 같은 물리 호스트에 어떤 VM들이 함께 실행 중인지, 물리 CPU가 얼마나 사용 중인지, 하이퍼바이저가 어떤 방식으로 CPU를 스케줄링하는지 직접 확인하기 어렵습니다.

 

 

운영 환경에서 CPU steal time이 높다면?

운영 환경에서 CPU steal time이 지속적으로 높게 나타난다면 Guest VM 내부에서만 해결하기 어려운 문제일 수 있습니다.

이 경우 다음과 같은 항목을 함께 확인해야 합니다.

- VM 내부 애플리케이션의 CPU 사용 패턴 확인
- load average와 `%steal`이 함께 증가하는지 확인
- `%iowait`이 높은지 확인하여 디스크 I/O 문제와 구분
- 다른 물리 호스트로 VM 마이그레이션 검토
- 하이퍼바이저 또는 클라우드 제공자 측 CPU overcommit 상태 확인
- Xen dom0 접근 권한이 있다면 scheduler weight, cap, vCPU pinning 상태 확인

 

즉, CPU steal time이 높다는 것은 단순히 VM 내부 프로세스를 줄이는 것만으로 해결되지 않을 수 있습니다.

VM이 실행되는 하이퍼바이저와 물리 호스트의 자원 배분 상태까지 함께 봐야 합니다.

 

정리

이번 실습에서는 Xen 기반 Ubuntu VM에서 CPU steal time을 확인했습니다.

 

현재 서버는 하이퍼바이저 위에서 동작하는 Guest VM이며, Guest OS에서는 4개의 vCPU가 할당된 것으로 확인되었습니다.

 

CPU steal time은 mpstat의 %steal, vmstat과 top의 st 항목을 통해 확인할 수 있습니다.

 

평상시 측정 결과에서 %steal 값은 0 또는 매우 낮은 수준으로 나타났습니다. 이는 측정 시점 기준으로 현재 VM이 하이퍼바이저로부터 CPU 시간을 기다리는 상황이 거의 없었다는 의미로 해석할 수 있습니다.

 

이후 stress-ng를 사용해 VM 내부에 CPU 부하를 발생시켰습니다.

 

부하 중에는 %usr 값이 증가하고 %idle 값이 감소했지만, %steal 값은 지속적으로 높아지지 않았습니다.

 

이를 통해 CPU steal time은 VM 내부 CPU 부하 자체로 증가하는 값이 아니라,

하이퍼바이저가 물리 CPU 시간을 얼마나 원활하게 배정하는지와 관련된 지표라는 점을 확인할 수 있었습니다.

 

다만 이번 실습은 Guest VM 내부에서 수행했기 때문에,

같은 물리 호스트의 다른 VM 상태나 Xen dom0의 스케줄링 정책까지는 직접 확인할 수 없었습니다.

 

따라서 이번 실습의 핵심은 CPU steal time을 강제로 증가시키는 것이 아니라,

CPU steal time이 VM 내부 부하와는 다른 가상화 계층의 지표라는 점을 이해하는 데 있습니다.

 

 

결국 VM 환경에서 CPU 성능을 분석할 때는 CPU 사용률만 볼 것이 아니라, CPU steal time, load average, iowait를 함께 확인해야 합니다. 이를 통해 VM 내부 CPU 부하, 디스크 I/O 대기, 하이퍼바이저 수준의 CPU 대기를 구분할 수 있습니다.