x86 / x64 가상화의 오버 헤드는 얼마입니까?


24

Intel 하드웨어 가상화를 사용하는 Win64 호스트 및 Linux64 게스트 각각에 대해 x86 / x64 가상화 (VirtualBox, 아마도 VMWare, 아마도 반가상 화가 아닐 것입니다)의 오버 헤드가 얼마나됩니까?

  • 순수한 CPU 바운드, 사용자 모드 64 비트 코드

  • 순수한 CPU 바운드, 사용자 모드 32 비트 코드

  • 하드 드라이브에 파일 I / O (대기 시간이 아닌 처리량을 주로 고려)

  • 네트워크 I / O

  • 스레드 동기화 기본 요소 (뮤텍스, 세마포어, 조건 변수)

  • 스레드 컨텍스트 스위치

  • 원자 연산 ( lock접두사 사용, 비교 및 스왑 등)

나는 주로 하드웨어 지원 x64 케이스 (인텔과 AMD 모두)에 관심이 있지만 보조 바이너리 변환과 x86 (즉, 32 비트 호스트 및 게스트) 케이스에 대해서는 들리지 않을 것입니다. 반 가상화에 관심이 없습니다.


(1) "x86"은 32 비트를 의미합니다. 64 비트 코드를 실행할 수 없습니다. AMD64 (x64라고도 함) 가상화에는 하드웨어 확장이 필요하므로 제한이 다릅니다. (2) 바이너리 변환 (x86 전용) 또는 하드웨어 지원 가상화 (VT)에 의한 x86 가상화를 의미합니까?
Skyhawk

@Miles : 질문을 명확하게했습니다.
dsimcha

답변:


26

나는 당신과 같은 질문에 대한 간단하고 절대적인 대답이 없다는 것을 알았습니다. 각 가상화 솔루션은 특정 성능 테스트에서 다르게 작동합니다. 또한 디스크 I / O 처리량과 같은 테스트는 여러 가지 테스트 (읽기, 쓰기, 다시 쓰기 등)로 나눌 수 있으며 결과는 솔루션마다, 시나리오마다 다릅니다. 그렇기 때문에 하나의 솔루션을 디스크 I / O에 가장 빠른 것으로 지정하는 것이 쉽지 않은 이유는 디스크 I / O의 오버 헤드와 같은 레이블에 대한 절대적인 대답이없는 이유입니다.

서로 다른 벤치 마크 테스트 간의 관계를 찾으려고하면 더 복잡해집니다. 내가 테스트 한 솔루션 중 어느 것도 미세 작업 테스트에서 우수한 성능을 발휘하지 못했습니다. 예를 들어 : VM 내에서 "gettimeofday ()"에 대한 단일 호출은 평균적으로 하드웨어에서보다 11.5 배 더 많은 클럭주기를 완료했습니다. 하이퍼 바이저는 실제 응용 프로그램에 최적화되어 있으며 미세 작업에는 적합하지 않습니다. 실제 응용 프로그램에 더 적합한 응용 프로그램에는 문제가되지 않을 수 있습니다. 즉, 마이크로-작동으로 1,000 클록 미만의 사이클을 소비하는 애플리케이션을 완료합니다 (2.6GHz CPU의 경우 1,000 클록 사이클은 385 나노초 또는 3.85e-7 초로 소비 됨).

x86 아키텍처를위한 데이터 센터 통합을위한 4 가지 주요 솔루션에 대한 광범위한 벤치 마크 테스트를 수행했습니다. VM 내부의 성능과 하드웨어 성능을 비교하는 거의 3000 개의 테스트를 수행했습니다. 하드웨어 내에서 측정 된 최대 성능과 VM 내부에서 측정 된 최대 성능의 차이를 '오버 헤드'라고했습니다.

솔루션 :

  • VMWare ESXi 5
  • Microsoft Hyper-V Windows 2008 R2 SP1
  • Citrix XenServer 6
  • Red Hat Enterprise Virtualization 2.2

게스트 OS :

  • Microsoft Windows 2008 R2 64 비트
  • Red Hat Enterprise Linux 6.1 64 비트

테스트 정보 :

  • 서버 : 2GB Sun Fire X4150, 각각 8GB RAM, 2X Intel Xeon E5440 CPU 및 4 기가비트 이더넷 포트
  • 디스크 : 기가비트 이더넷을 통한 iSCSI를 통한 6X 136GB SAS 디스크

벤치 마크 소프트웨어 :

  • CPU 및 메모리 : 32 비트 및 64 비트 모두에 대한 Linpack 벤치 마크 . 이것은 CPU와 메모리를 많이 사용합니다.

  • 디스크 I / O 및 지연 시간 : Bonnie ++

  • 네트워크 I / O : Netperf : TCP_STREAM, TCP_RR, TCP_CRR, UDP_RR 및 UDP_STREAM

  • 마이크로 오퍼레이션 : rdtscbench : 시스템 호출, 프로세스 간 파이프 통신

평균은 다음 매개 변수를 사용하여 계산됩니다.

  • CPU 및 메모리 : 평균 (HPL32, HPL64)

  • 디스크 I / O : 평균 (put_block, rewrite, get_block)

  • 네트워크 I / O : 평균 (tcp_crr, tcp_rr, tcp_stream, udp_rr, udp_stream)

  • 마이크로 연산 AVERAGE (getpid (), sysconf (), gettimeofday (), malloc [1M], malloc [1G], 2pipes [], simplemath [])

테스트 시나리오의 경우 메트릭을 사용하여 네 가지 가상화 솔루션의 결과 평균은 다음과 같습니다.

VM 계층 오버 헤드, Linux 게스트 :

  • CPU 및 메모리 : 14.36 %

  • 네트워크 I / O : 24.46 %

  • 디스크 I / O : 8.84 %

  • 읽기 디스크 대기 시간 : 2.41 배 느림

  • 마이크로 작업 실행 시간 : 10.84 배 느림

VM 계층 오버 헤드, Windows 게스트 :

  • 32 비트 및 64 비트 CPU 및 메모리 평균 : 13.06 %

  • 네트워크 I / O : 35.27 %

  • 디스크 I / O : 15.20 %

해당 값은 일반적이며 특정 사례 시나리오를 반영하지 않습니다.

전체 기사를 살펴보십시오 : http://petersenna.com/en/projects/81-performance-overhead-and-comparative-performance-of-4-virtualization-solutions


2
이 기사는 최신 정보가 없습니다
dyasny

1
For a 2.6 GHz CPU, 1,000 clock cycles are spent in 23 milliseconds, 1,000 클럭 사이클에 걸리는 시간 (초)을 얻기 위해 1,000을 2,600,000으로 간단하게 나누면 안됩니까? (23 밀리 초가 아님)
dvdvorle

2
@씨. 행복합니다 1000/3600000000 = 0.000000385 = 385 나노초로 385 나노초를 얻었습니다. 이것에 동의하십니까? 이것을 지적 해 주셔서 감사합니다.
피터 세나

@ dyasny, 업데이트 된 버전으로 테스트를 반복 할 하드웨어를 찾고 있습니다. 어디서 찾을 수 있습니까?
피터 세나

하드웨어는 상점에서 쉽게 찾을 수 있습니다
dyasny

4

귀하의 질문에 너무 많은 변수가 있지만 범위를 좁히려 고 시도 할 수 있습니다. VMware ESX를 사용하고 가상화를 지원하는 최신 CPU, 반 가상화 스토리지 및 네트워크 드라이버가있는 VMware 도구, 많은 메모리를 모두 사용한다고 가정 해 봅시다. 이제이 설정에서 단일 가상 머신을 실행한다고 가정하겠습니다. 내 경험으로는 CPU 바인딩 워크로드에 대해 ~ 90 %의 CPU 속도를 가져야합니다. 우리는 1Gbps 링크를 사용하고 있기 때문에 네트워크 속도에 대해 많이 말할 수 없으며 문제없이 채울 수 있지만 10Gbps 링크와 다를 수 있지만 그중 하나는 없습니다. 스토리지 처리량은 스토리지 유형에 따라 다르며 로컬 스토리지를 사용하면 스토리지 처리량의 약 80 %를 얻을 수 있지만 1Gbps NFS의 경우 네트워킹에 병목 현상이 발생하므로 100 %에 가깝습니다. 다른 측정 항목에 대해서는 말할 수 없습니다.

이 수치는 대략적인 수치이며로드 유형, 하드웨어, 네트워킹에 따라 크게 다릅니다. 서버에서 여러 워크로드를 실행할 때 훨씬 더 어려워집니다. 그러나 내가 여기서 말하고 싶은 것은 이상적인 조건 하에서 기본 성능의 90 %에 가까워 질 수 있다는 것입니다.

또한 내 경험상 고성능 응용 프로그램의 훨씬 더 큰 문제는 대기 시간이며 특히 클라이언트 서버 응용 프로그램에 해당됩니다. 우리는 30 명 이상의 고객으로부터 요청을 받고 짧은 계산을 수행하고 결과를 반환하는 계산 엔진을 가지고 있습니다. 베어 메탈에서는 일반적으로 CPU를 100 %로 푸시하지만 VMware의 동일한 서버는 CPU를 60-80 %로만로드 할 수 있으며 이는 주로 요청 / 응답 처리 지연으로 인한 것입니다.


하나의 VM으로 10GbE 링크를 포화시키는 것은 매우 어렵다는 경험을 통해 알 수 있습니다. 우리는 VMWare FT를 사용했는데, 이는 10Gbe 이상으로 자체적으로 1Gbps 링크를 쉽게 포화시킬 수 있으며 포화에 가깝지 않았습니다.
Mark Henderson

0

컨텍스트 전환 및 원자 연산과 같은 기본 프리미티브의 성능을 파헤 치지 않았지만 최근에 다른 하이퍼 바이저로 수행 한 무차별 대입 테스트 결과가 있습니다. 대부분 CPU 및 RAM 대역폭이 제한적일 경우 예상 할 수있는 것을 나타냅니다.

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/


2
Xen과 KVM에 대한 정보를 얻었으니 정말 좋습니다.하지만 가장 인기있는 두 하이퍼 바이저는 어떻습니까?! 그들은 완전히 빠졌습니다. 그리고 여러 유형 2 하이퍼 바이저를 포함 시켰습니다. 제정 된 SysAdmin은 프로덕션에이를 사용하지 않았습니다.
Chris S

다운 투표. 연결이 끊어졌습니다.
Tim Duncklee
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.