Berapa banyak pertengkaran di VMware?


21

Untuk sementara waktu sekarang saya telah mencoba mencari tahu mengapa beberapa sistem bisnis kritis kami mendapatkan laporan "kelambatan" mulai dari yang ringan sampai yang ekstrem. Saya baru-baru ini mengalihkan pandangan saya ke lingkungan VMware di mana semua server yang bersangkutan di-host.

Saya baru-baru ini mengunduh dan menginstal uji coba untuk paket manajemen Veeam VMware untuk SCOM 2012, tetapi saya mengalami kesulitan untuk percaya (dan begitu juga bos saya) angka-angka yang dilaporkan kepada saya. Untuk meyakinkan bos saya bahwa angka-angka yang diberitahukan kepada saya benar, saya mulai mencari ke dalam klien VMware itu sendiri untuk memverifikasi hasilnya.

Saya telah melihat artikel KB VMware ini ; khusus untuk definisi Co-Stop yang didefinisikan sebagai:

Jumlah waktu mesin virtual MP siap dijalankan, tetapi mengalami penundaan karena pertentangan penjadwalan co-vCPU

Yang saya terjemahkan

OS tamu memerlukan waktu dari tuan rumah tetapi harus menunggu sumber daya tersedia dan karenanya dapat dianggap "tidak responsif"

Apakah terjemahan ini tampaknya benar?

Jika demikian, di sinilah saya mengalami kesulitan untuk meyakini apa yang saya lihat: Tuan rumah yang berisi sebagian besar VM yang "lambat" saat ini menunjukkan rata-rata CPU-stop CPU 127.835,94 milidetik!

Apakah ini berarti bahwa rata-rata VM di host ini harus menunggu 2+ menit untuk waktu CPU ???

Tuan rumah ini memang memiliki dua CPU 4 inti di dalamnya dan memiliki tamu CPU 1x8 dan tamu CPU 14x4.


Dari pemahaman saya: untuk menghindari beberapa masalah semua CPU virtual dari VM dijadwalkan untuk berjalan pada saat yang sama. Jika ada pertentangan beberapa VM dapat berjalan sangat lambat. Catatan menetapkan lebih banyak vCPU ke VM untuk mencoba dan meningkatkan kinerja saat ini masalahnya akan membuat segalanya menjadi lebih buruk.
Brian

Tuan rumah ini memang memiliki dua CPU 4 inti di dalamnya dan memiliki tamu CPU 1x8 dan tamu CPU 14x4.
Chuck Herrington

Mengapa banyak tamu yang memiliki konfigurasi 4 vCPU?
ewwhite

6
Pertikaian penjadwalan bersama CPU membunuh Anda. Perlu mengurangi jumlah vCPU atau memindahkan beberapa VM dari sistem itu.
Brian

@ ChuckHerrington Anda harus menindaklanjuti atau menandai jawaban.
ewwhite

Jawaban:


17

Saya dapat menggambarkan beberapa pengalaman yang saya alami di bidang ini ...

Saya tidak percaya bahwa VMware melakukan pekerjaan yang memadai untuk mendidik pelanggan ( atau administrator ) tentang praktik terbaik, juga tidak memperbarui praktik terbaik sebelumnya karena produk mereka berkembang. Pertanyaan ini adalah contoh bagaimana konsep inti seperti alokasi vCPU tidak sepenuhnya dipahami. Pendekatan terbaik adalah mulai dari yang kecil, dengan satu vCPU, sampai Anda menentukan bahwa VM membutuhkan lebih banyak.

Untuk OP, server host ESXi memiliki dua CPU quad-core, menghasilkan 8 core fisik.

Tata letak mesin virtual yang dijelaskan adalah 15 total tamu; Sistem 1 x 8 vCPU dan 14 x 4 vCPU. Itu terlalu berlebihan, terutama dengan adanya tamu tunggal dengan 8 vCPU . Itu tidak masuk akal. Jika Anda membutuhkan VM sebesar itu, Anda kemungkinan membutuhkan server yang lebih besar.

Silakan coba ukuran kanan mesin virtual Anda. Saya cukup yakin sebagian besar dari mereka dapat hidup dengan 2 vCPU. Menambahkan CPU virtual tidak membuat segalanya berjalan lebih cepat, jadi jika itu adalah solusi untuk masalah kinerja, itu adalah pendekatan yang salah untuk dilakukan.

Di sebagian besar lingkungan, RAM adalah sumber daya yang paling terbatas. Tapi CPU bisa menjadi masalah jika ada terlalu banyak pertengkaran. Anda punya bukti tentang ini. RAM juga bisa menjadi masalah jika terlalu banyak dialokasikan untuk masing-masing VM .

Mungkin untuk memonitor ini. Metrik yang Anda cari adalah "CPU Ready%". Anda dapat mengakses ini dari klien vSphere dengan memilih VM dan pergi ke Performance>> OverviewGrafik CPU.

  • Di bawah 5% CPU Ready - Anda baik-baik saja.
  • 5-10% CPU Ready - Tetap perhatikan aktivitas.
  • Lebih dari 10% CPU Ready - Tidak bagus.

Perhatikan garis Kuning pada grafik di bawah ini. masukkan deskripsi gambar di sini

Maukah Anda memeriksa ini pada mesin virtual masalah Anda dan melaporkan kembali?


Hanya melihat grafik untuk server pertukaran yang kami miliki di host yang terlalu berkomitmen. Grafik saya terlihat kebalikan dari grafik Anda. Penggunaan CPU melayang di sekitar 25% dan CPU Ready lonjakan setinggi 200% tetapi rata-rata sekitar 100%.
Chuck Herrington

@ChuckHerrington Harap kurangi sumber daya dari mesin virtual 8 vCPU dan ukur lagi.
ewwhite

Satu-satunya perhatian dengan itu adalah tamu 8 cpu adalah salah satu server database server produksi utama sql. Kami telah mencoba mengurangi menjadi 4 sebelum dan semuanya berjalan ... serba salah. Kira sebaiknya kita coba lagi.
Chuck Herrington

Anda tidak dapat memiliki mesin virtual 8 vCPU di server dengan total 8 inti.
ewwhite

@Bahkan, sayangnya Anda bisa, Anda seharusnya tidak, tetapi Anda bisa.
Rqomey

46

Anda menyatakan dalam komentar Anda memiliki host ESXi quad-core ganda, dan Anda menjalankan satu VM 8vCPU, dan empat belas VM 4vCPU.

Jika ini adalah lingkungan saya, saya akan menganggap itu terlalu berlebihan. Saya paling tidak akan menempatkan empat hingga enam tamu 4vCPU pada perangkat keras itu. (Ini mengasumsikan bahwa VM yang bersangkutan memiliki beban yang mengharuskan mereka untuk memiliki jumlah vCPU yang tinggi.)

Saya berasumsi Anda tidak tahu aturan emas ... dengan VMware Anda tidak boleh menetapkan VM lebih banyak core dari yang dibutuhkan. Alasan? VMware menggunakan penjadwalan bersama yang agak ketat yang mempersulit VM untuk mendapatkan waktu CPU kecuali ada banyak core yang tersedia seperti yang diberikan oleh VM. Artinya, VM 4vCPU tidak dapat melakukan 1 unit kerja kecuali ada 4 core fisik yang terbuka pada saat yang sama. Dengan kata lain, secara arsitektur lebih baik memiliki VM 1vCPU dengan beban CPU 90%, kemudian memiliki VM 2vCPU dengan beban 45% per inti.

Jadi ... SELALU membuat VM dengan minimum vCPU, dan hanya menambahkannya saat itu dianggap perlu.

Untuk situasi Anda, gunakan Veeam untuk memantau penggunaan CPU pada tamu Anda. Kurangi jumlah vCPU sebanyak mungkin. Saya berani bertaruh bahwa Anda bisa turun ke 2vCPU pada hampir semua tamu 4vCPU Anda yang ada.

Memang, jika semua VM ini benar-benar memiliki beban CPU untuk memerlukan jumlah vCPU yang mereka miliki, maka Anda hanya perlu membeli perangkat keras tambahan.


20
Jawaban ini, saya suka, yang lain! (Menghancurkan cangkir kopi di tanah)
MonkeyZeus

2
Satu hal untuk ditambahkan .. Siapkan peringatan untuk CPU% siap. davidklee.net/articles/sql-server-articles/…
Stewpudaso

1
Bukankah itu harus di bawah ketentuan?
user253751

3
Apakah itu kebodohan VMWare masih berlaku? Hyper-V memiliki hal yang sama - dalam versi awal dan ditangani sesegera mungkin. Sekarang core dijadwalkan secara independen. Saya tidak bisa membayangkan ini masih menjadi kasus untuk VmWare di versi saat ini.
TomTom

2
@TomTom: menurut serverfault.com/a/642316/58957 "penjadwalan bersama yang ketat" digunakan dalam versi sebelum 3.x (lebih dari 10 tahun yang lalu!), Namun internet masih penuh dengan ini. Tetap saja rekomendasi untuk hanya menambah jumlah vCPU yang diperlukan adalah masuk akal.
Nickolay

2

127.835,94 milidetik adalah penjumlahan dan Anda harus membaginya dengan waktu sampel untuk mendapatkan nilai% RDY yang benar. Sepertinya Anda sudah mendapatkan pembacaan% RDY yang benar sekarang. Anda bisa naik cukup tinggi dengan vCPU ke rasio cpu fisik tetapi tidak seperti yang Anda lakukan.

Anda memiliki terlalu banyak quad vCPU VM dan bahkan 8 vCPU VM. Ada beberapa respons kualitas yang sudah membahas ukuran kanan dan beberapa konsekuensi dari tidak mengkonsolidasikan siklus menjadi vCPU yang lebih sedikit. Satu hal yang saya ingin klarifikasi adalah bahwa sementara itu bukan lagi kasus bahwa VM harus menunggu jumlah CPU fisik yang sama dengan jumlah vCPU yang akan tersedia sebelum instruksi dapat diproses, itu sangat merugikan untuk memiliki ketentuan yang terlalu besar sebesar ini dengan rasio VM multi-vCPU terhadap core fisik. 64 vCPU pada 8 core jauh melampaui rasio maksimum 4 banding 1. Saya berasumsi Anda memiliki HT pada prosesor ini sehingga Anda memiliki 16 core logis? Itu mungkin OK dengan VM vCPU 1 dan 2 yang memiliki beban ringan tetapi jika Anda memiliki beban berat pada VM akan sulit untuk dicapai.

FYI Prosesor HT tidak digunakan dalam perhitungan% CPU yang digunakan - artinya jika Anda memiliki 32 core logis berjalan pada 2,4 Ghz di server, Anda berada pada 100% penggunaan saat Anda menekan 38,4 GHz. Jadi, ketika Anda melihat rata-rata beban menunjukkan lebih dari 1.0, itu sebabnya.

Berikut ini adalah ESXi Host yang menjalankan rasio 3,5 banding 1 vCPU terhadap CPU fisik (termasuk inti HT) dengan rata-rata% RDY 3%.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

1

Kami telah menginstal Veeam ONE yang telah memberikan sedikit cahaya di mana masalah kinerja kami. Dengan melihat layar CPU Bottlenecks di Veeam ONE lalu menggunakan Troubleshooting mesin virtual yang telah berhenti merespons: VMM dan Guest CPU perbandingan penggunaan sebagai referensi kami telah menemukan di mana membagikan pertentangan kami "tidak dapat diterima" adalah.

Satu tip kecil yang ingin saya bagikan secara khusus adalah bahwa dalam satu kasus saya tidak bisa menghilangkan pertengkaran CPU sampai saya menghapus snapshot yang ada di VM. Semoga ini bisa membantu seseorang.


Astaga. Ada snapshot yang berjalan juga?
ewwhite
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.