Berapa overhead yang dimiliki virtualisasi x86 / x64?


24

Berapa banyak overhead yang dimiliki virtualisasi x86 / x64 (saya mungkin akan menggunakan VirtualBox, VMWare possbly, jelas bukan paravirtualization) miliki untuk masing-masing operasi berikut host Win64 dan tamu Linux64 menggunakan virtualisasi perangkat keras Intel?

  • Murni yang terikat CPU, mode pengguna kode 64-bit

  • Murni-terikat-CPU, mode pengguna kode 32-bit

  • File I / O ke hard drive (kebanyakan saya peduli tentang throughput, bukan latensi)

  • I / O jaringan

  • Primitif sinkronisasi utas (mutex, semaphores, variabel kondisi)

  • Sakelar konteks utas

  • Operasi atom (menggunakan lockawalan, hal-hal seperti bandingkan-dan-tukar)

Saya terutama tertarik pada perangkat keras yang dibantu kasus x64 (baik Intel dan AMD) tetapi tidak keberatan mendengar tentang terjemahan biner yang tidak dibantu dan kasus-kasus x86 (yaitu host dan tamu 32-bit) juga. Saya tidak tertarik pada paravirtualization.


(1) "x86" berarti 32-bit. Anda tidak akan dapat menjalankan kode 64-bit. Virtualisasi AMD64 (juga dikenal sebagai x64) memiliki batasan berbeda karena memerlukan ekstensi perangkat keras. (2) Maksud Anda virtualisasi x86 dengan terjemahan biner (hanya x86) atau virtualisasi berbantuan perangkat keras (VT)?
Skyhawk

@Miles: Saya sudah mengklarifikasi pertanyaannya.
dsimcha

Jawaban:


26

Saya menemukan bahwa tidak ada jawaban yang sederhana dan absolut untuk pertanyaan seperti milik Anda. Setiap solusi virtualisasi berperilaku berbeda pada tes kinerja spesifik. Juga, tes seperti disk I / O throughput dapat dibagi dalam banyak tes yang berbeda (baca, tulis, tulis ulang, ...) dan hasilnya akan bervariasi dari solusi ke solusi, dan dari skenario ke skenario. Inilah sebabnya mengapa tidak sepele untuk menunjuk satu solusi sebagai yang tercepat untuk disk I / O, dan inilah mengapa tidak ada jawaban absolut untuk label seperti overhead untuk disk I / O.

Semakin rumit ketika mencoba menemukan hubungan antara tes benchmark yang berbeda. Tak satu pun dari solusi yang saya uji memiliki kinerja yang baik pada tes operasi mikro. Misalnya: Di dalam VM satu panggilan tunggal ke "gettimeofday ()" mengambil, rata-rata, 11,5 kali lebih banyak siklus clock untuk diselesaikan daripada pada perangkat keras. Hypervisor dioptimalkan untuk aplikasi dunia nyata dan tidak berkinerja baik pada operasi mikro. Ini mungkin bukan masalah bagi aplikasi Anda yang mungkin lebih cocok dengan aplikasi dunia nyata. Maksud saya dengan operasi mikro aplikasi apa pun yang menghabiskan kurang dari 1.000 siklus clock untuk menyelesaikan (Untuk CPU 2,6 GHz, 1.000 siklus clock dihabiskan dalam 385 nanodetik, atau 3,85e-7 detik).

Saya melakukan pengujian benchmark yang luas pada empat solusi utama untuk konsolidasi pusat data untuk arsitektur x86. Saya melakukan hampir 3000 tes membandingkan kinerja di dalam VM dengan kinerja perangkat keras. Saya menyebut 'overhead' perbedaan kinerja maksimum yang diukur di dalam VM (s) dengan kinerja maksimum yang diukur pada perangkat keras.

Solusi:

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

OS tamu:

  • Microsoft Windows 2008 R2 64 bit
  • Red Hat Enterprise Linux 6.1 64 bit

Info Tes:

  • Server: 2X Sun Fire X4150 masing-masing dengan 8GB RAM, 2X Intel Xeon E5440 CPU, dan empat port Ethernet gigabit
  • Disk: 6X 136GB SAS disk lebih dari iSCSI melalui gigabit ethernet

Perangkat Lunak Benchmark:

  • CPU dan Memory: Linpack benchmark untuk 32 dan 64 bit. Ini adalah CPU dan memori yang intensif.

  • Disk I / O dan Latency: Bonnie ++

  • Jaringan I / O: Netperf: TCP_STREAM, TCP_RR, TCP_CRR, UDP_RR dan UDP_STREAM

  • Operasi mikro: rdtscbench : Panggilan sistem, komunikasi pipa antar proses

Rata-rata dihitung dengan parameter:

  • CPU dan Memori: AVERAGE (HPL32, HPL64)

  • Disk I / O: AVERAGE (put_block, rewrite, get_block)

  • Jaringan I / O: AVERAGE (tcp_crr, tcp_rr, tcp_stream, udp_rr, udp_stream)

  • AVERAGE operasi mikro (getpid (), sysconf (), gettimeofday (), malloc [1M], malloc [1G], 2pipes [], simplemath [])

Untuk skenario pengujian saya, menggunakan metrik saya, rata-rata hasil dari empat solusi virtualisasi adalah:

Overhead lapisan VM, tamu Linux:

  • CPU dan Memori: 14,36%

  • Jaringan I / O: 24,46%

  • Disk I / O: 8,84%

  • Disk latensi untuk membaca: 2,41 kali lebih lambat

  • Waktu pelaksanaan operasi mikro: 10,84 kali lebih lambat

Overhead lapisan VM, tamu Windows:

  • CPU dan Memori rata-rata untuk 32 dan 64 bit: 13,06%

  • Jaringan I / O: 35,27%

  • Disk I / O: 15,20%

Harap dicatat bahwa nilai-nilai itu bersifat umum, dan tidak mencerminkan skenario kasus tertentu.

Silakan lihat artikel lengkapnya: http://petersenna.com/en/projects/81-performance-overhead-and-comparative-performance-of-4-virtualization-solusi


2
Artikel ini kedaluwarsa
dyasny

1
For a 2.6 GHz CPU, 1,000 clock cycles are spent in 23 milliseconds, bukankah seharusnya itu pembagian sederhana 1.000 oleh 2.600.000 untuk mendapatkan jumlah detik 1.000 siklus clock? (yang bukan 23 milidetik)
dvdvorle

2
@Bapak. Senang, kamu benar. Saya mendapat 385 nanodetik per: 1000/2600000000 = 0,000000385 = 385 nanodetik. Apakah kamu setuju dengan ini? Terima kasih telah menunjukkan ini.
Peter Senna

@dyasny, saya mencari perangkat keras untuk mengulang tes dengan versi yang diperbarui. Ada ide di mana saya bisa menemukannya?
Peter Senna

perangkat keras dapat dengan mudah ditemukan di toko
dyasny

4

Ada terlalu banyak variabel dalam pertanyaan Anda, namun saya dapat mencoba mempersempitnya. Mari kita asumsikan bahwa Anda menggunakan VMware ESX, Anda melakukan segalanya dengan benar - CPU terbaru dengan dukungan untuk virtualisasi, alat VMware dengan penyimpanan paravirtualized dan driver jaringan, banyak memori. Sekarang mari kita asumsikan bahwa Anda menjalankan mesin virtual tunggal pada pengaturan ini. Dari pengalaman saya, Anda harus memiliki ~ 90% kecepatan CPU untuk beban kerja yang terikat CPU. Saya tidak bisa memberi tahu Anda banyak tentang kecepatan jaringan, karena kami menggunakan tautan 1Gbps dan saya dapat menjenuhkannya tanpa masalah, mungkin berbeda dengan tautan 10Gbps namun kami tidak memilikinya. Throughput penyimpanan tergantung pada jenis penyimpanan, dengan saya bisa mendapatkan ~ 80% throughput penyimpanan dengan penyimpanan lokal, tetapi untuk 1Gbps NFS mendekati 100% karena jaringan mengalami hambatan di sini. Tidak dapat memberi tahu tentang metrik lainnya,

Angka-angka ini sangat perkiraan dan sangat tergantung pada jenis beban Anda, perangkat keras Anda, jaringan Anda. Semakin fuzzier ketika Anda menjalankan beberapa beban kerja di server. Tapi apa yang ingin saya katakan di sini adalah bahwa dalam kondisi ideal Anda harus bisa mendekati 90% dari kinerja asli.

Juga dari pengalaman saya, masalah yang jauh lebih besar untuk aplikasi berkinerja tinggi adalah latensi dan ini terutama berlaku untuk aplikasi server klien. Kami memiliki mesin perhitungan yang menerima permintaan dari 30+ klien, melakukan perhitungan pendek dan mengembalikan hasil. Pada bare metal biasanya mendorong CPU ke 100% tetapi server yang sama pada VMware hanya dapat memuat CPU ke 60-80% dan ini terutama karena latensi dalam menangani permintaan / balasan.


Saya dapat berbicara dari pengalaman bahwa menjenuhkan tautan 10GbE dengan satu VM sangat sulit. Kami telah menggunakan VMWare FT, yang dapat dengan mudah menjenuhkan tautan 1Gbps sendiri, lebih dari 10Gbe dan tidak mendekati menjenuhkannya.
Mark Henderson

0

Saya belum menggali kinerja primitif dasar seperti pengalihan konteks dan operasi atom, tetapi ini adalah hasil tes brute force yang saya lakukan baru-baru ini dengan hypervisor yang berbeda. Ini harus menunjukkan apa yang Anda harapkan jika sebagian besar CPU dan bandwidth RAM Anda terbatas.

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


2
Itu bagus bahwa Anda punya beberapa info untuk Xen dan KVM ... Tapi bagaimana dengan dua Hypervisor paling populer ?! Mereka benar-benar hilang. Dan Anda sudah memasukkan beberapa Hypervisor Tipe 2, tidak ada SysAdmin waras yang akan menggunakannya untuk produksi.
Chris S

Turunkan suara. Tautan sudah mati.
Tim Duncklee
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.