Hyper Threading dan Mesin Virtual?


15

Saya sudah melihat utas ini: Hyper-V dan Hyper-threading: Hidup atau mati?, tetapi satu-satunya jawaban adalah khusus Windows ....

Saya sedang membangun server VM (menggunakan Proxmox VE jika itu membuat perbedaan) dan bertanya-tanya tentang bagaimana hyper threading dapat mempengaruhi mesin virtual ...

Khususnya, jika saya memaksimalkan jumlah mesin virtual, akankah hyper threading membantu, atau merusak kinerja?

Juga, mesin virtual terbesar adalah Server Terminal dengan ~ 30 klien (4 Core / 8 GB RAM), dan server file jika itu membantu.

Pembaruan: Server adalah Dell R410 dengan RAID 1TB 10, 32 GB RAM dan Dual Intel Xeon E5530 (Saya tidak yakin tentang model yang tepat, tetapi itu adalah E55xx dengan 2+ Ghz)

Pembaruan: Kebanyakan VM akan menggunakan KVM.


Harap berikan spesifikasi server yang ingin Anda gunakan.
ewwhite

Penasaran juga. Mengapa Promox VE versus ESXi?
ewwhite

Mungkin karena batas ESXI 16GB ram pada lisensi gratis
Tacticus

3
Saya memilih Proxmox daripada ESXi karena Proxmox memiliki beberapa fitur tambahan seperti manajemen lengkap dari web gui, pengelompokan, spesifikasi server tidak secara artifisial dibatasi oleh lisensi dan beberapa lainnya saya tidak begitu ingat. Plus, 2.0 akan menyertakan otentikasi AD yang sangat berguna bagi kami, tidak yakin apakah ESXi tidak ...
Soviero

1
Apakah Anda sudah melihat oVirt?
dyasny

Jawaban:


12

Secara umum, saya membiarkan HyperThreading ON untuk server host VM (VMWare ESXi, KVM, HyperV, dll.). Ini berlaku untuk Intel Nehalem dan CPU yang lebih baru (seri 5500 dan lebih tinggi). Utas tambahan tersedia untuk menjadwalkan banyak VM.

Anda mungkin juga ingin mengevaluasi kembali ukuran sistem tamu Anda. Biasanya, yang terbaik adalah memulai dari kecil pada alokasi CPU dengan mesin virtual. Karena Anda berbicara tentang server terminal, saya sebenarnya akan memindahkannya ke 2 CPU virtual daripada 4 vCPU. Lebih mudah bagi hypervisor untuk menjadwalkan waktu CPU untuk VM dengan jumlah inti lebih kecil . RAM masih kritis, jadi pastikan untuk menyediakan banyak.

Lihat: http://omtconcepts.com/wp/?p=14


Bagaimana tepatnya dua utas lebih cepat dari empat?
Soviero

3
Tidak lebih cepat ... Lebih mudah dengan jadwal. Lihat hasil edit saya. Mesin yang Anda sebutkan akan memiliki total 8 inti (16, dengan HyperThreading). Mencoba menemukan sumber daya untuk menjadwalkan tamu 4-vCPU lebih sulit daripada 2-vCPU. Anda akan memiliki lebih banyak pertengkaran (dan karenanya, kinerja yang lebih rendah). Jika Anda berencana untuk menjalankan tamu virtual lain di server ini, masuk akal untuk menggunakan 1 dan 2 tamu vCPU.
ewwhite

3
Poin Anda tentang penjadwalan hanya berlaku untuk hypervisor yang melakukan "penjadwalan geng" di mana mereka mencoba untuk menjalankan beberapa perkiraan "semua atau tidak sama sekali" dari prosesor virtual pada saat yang sama. Untuk hypervisor yang melakukan ini, menambahkan lebih banyak prosesor virtual akan membuat VM lebih sulit untuk dijadwalkan. Saya mengerti bahwa Kevin memperbarui pertanyaannya untuk menyatakan bahwa dia ingin menggunakan KVM, kebanyakan. Tapi saya ingin menunjukkan bahwa Hyper-V tidak melakukan penjadwalan geng. Itu bergantung pada paravirtualization dari OS tamu untuk menghindari perlunya penjadwalan geng.
Jake Oshins

Saya tidak tahu tentang Hyper-V, tetapi ini berlaku untuk hypervisor utama lainnya.
ewwhite

1
KVM tidak menjadwalkan geng. Bahkan, hanya VMWare yang melakukan ini, dan bahkan mereka telah menambahkan beberapa mekanisme untuk mengendurkan kegilaan penjadwalan geng dalam v5
dyasny

4

Itu sangat tergantung. Jika, seperti yang Anda katakan, Anda akan "max out", yang saya kira berarti secara keseluruhan CPU (menetapkan lebih banyak core CPU virtual daripada yang Anda miliki, atau persis sebanyak yang Anda miliki), maka HT pasti harus di.

Jika Anda tidak melakukan keseluruhan, maka biasanya lebih baik untuk menguji di bawah beban spesifik Anda - kadang-kadang HT benar-benar dapat merusak kinerja.


Saya berencana untuk mengalokasikan tepat sebanyak inti / utas yang tersedia, tetapi saya tidak berencana untuk mengalokasikan secara berlebihan.
Soviero

Apakah Anda pikir OS host tidak memerlukan waktu CPU sama sekali? Dan jika Anda mengalokasikan v-core sebanyak yang Anda miliki dengan HT, Anda sebenarnya secara keseluruhan setidaknya 70-80%, karena bahkan ketika HT menambah kinerja, biasanya dengan puncak 20-30%, bukan oleh 100%, seperti yang dapat diasumsikan dari jumlah utas.
dyasny

Ok, jadi tidak lebih dari 12 "core" (75% dari 16) dialokasikan?
Soviero

1
Kira saya tidak cukup jelas. Anda BISA secara keseluruhan menempatkan, dan tergantung pada beban di VM, CPU mungkin tidak menjadi hambatan sama sekali. Selain itu, Anda tidak boleh menugaskan lebih banyak CPU ke VM daripada yang dibutuhkan, karena semakin banyak CPU yang dimiliki VM, semakin sulit menjadwalkannya, sehingga banyak v-cpus yang sebenarnya dapat menghambat kinerja. Sedangkan untuk peningkatan kinerja 20% oleh hyperthreading - ini bukan mutlak, jumlahnya bisa sedikit lebih tinggi, lebih rendah, nol atau bahkan negatif - tergantung pada beban VM.
dyasny

Oh oke. Terima kasih.
Soviero

3

Ada banyak variabel yang mempengaruhi kinerja VM. HT hanyalah salah satu dari variabel lain tetapi juga tergantung pada bagaimana VM dikonfigurasikan.

Salah satu variabel yang mempengaruhi HT tergantung pada jenis Hypervisor yang digunakan.

Jika Anda menggunakan mesin virtual ringan seperti VZ, VServer, dll, maka cukup jelas bahwa HT akan membawa manfaat yang sesuai karena VM ini tidak benar-benar terisolasi dan lebih seperti menjalankan perangkat lunak multi-threaded.

Jika Anda menggunakan mesin virtual kelas berat seperti KVM, Xen HVM, dll, maka ada kemungkinan bahwa HT akan mengganggu hal-hal misalnya ketika VM dialokasikan dua CPU tetapi akhirnya menggunakan satu HT masing-masing pada core yang berbeda.

Jadi, hal terbaik untuk dilakukan adalah masih menguji pengaturan Anda untuk melihat apa yang cocok untuk Anda.

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.