Jika anda mentadbir infrastruktur maya berdasarkan VMware vSphere (atau mana-mana timbunan teknologi lain), anda mungkin sering mendengar aduan daripada pengguna: "Mesin maya lambat!" Dalam siri artikel ini, saya akan menganalisis metrik prestasi dan memberitahu anda perkara dan sebab ia perlahan dan cara memastikan ia tidak perlahan.
Saya akan mempertimbangkan aspek prestasi mesin maya berikut:
- CPU,
- RAM,
- CAKERA,
- Rangkaian.
Saya akan mulakan dengan CPU.
Untuk menganalisis prestasi kami memerlukan:
- Kaunter Prestasi vCenter β kaunter prestasi, graf yang boleh dilihat melalui Pelanggan vSphere. Maklumat mengenai kaunter ini tersedia dalam mana-mana versi klien (βtebalβ dalam C#, klien web dalam Flex dan klien web dalam HTML5). Dalam artikel ini kami akan menggunakan tangkapan skrin daripada klien C#, hanya kerana ia kelihatan lebih baik dalam bentuk kecil :)
- ESXTOP β utiliti yang dijalankan dari baris arahan ESXi. Dengan bantuannya, anda boleh mendapatkan nilai pembilang prestasi dalam masa nyata atau memuat naik nilai ini untuk tempoh tertentu ke dalam fail .csv untuk analisis lanjut. Seterusnya, saya akan memberitahu anda lebih lanjut tentang alat ini dan menyediakan beberapa pautan berguna kepada dokumentasi dan artikel mengenai topik tersebut.
Sedikit teori
Dalam ESXi, proses berasingan β dunia dalam terminologi VMware β bertanggungjawab untuk operasi setiap vCPU (teras mesin maya). Terdapat juga proses perkhidmatan, tetapi dari sudut pandangan menganalisis prestasi VM ia kurang menarik.
Proses dalam ESXi boleh berada dalam salah satu daripada empat keadaan:
- Main β proses melakukan beberapa kerja yang berguna.
- Tunggu β proses tidak melakukan apa-apa kerja (terbiar) atau sedang menunggu input/output.
- Costop β keadaan yang berlaku dalam mesin maya berbilang teras. Ia berlaku apabila penjadual CPU hipervisor (Penjadual CPU ESXi) tidak boleh menjadualkan pelaksanaan serentak semua teras mesin maya aktif pada teras pelayan fizikal. Dalam dunia fizikal, semua teras pemproses berfungsi selari, OS tetamu di dalam VM menjangkakan tingkah laku yang serupa, jadi hypervisor perlu memperlahankan teras VM yang mempunyai keupayaan untuk menyelesaikan kitaran jam mereka dengan lebih cepat. Dalam versi moden ESXi, penjadual CPU menggunakan mekanisme yang dipanggil penjadualan bersama santai: hypervisor mempertimbangkan jurang antara teras mesin maya "paling cepat" dan "paling perlahan" (skew). Jika jurang melebihi ambang tertentu, teras pantas memasuki keadaan costop. Jika teras VM menghabiskan banyak masa dalam keadaan ini, ia boleh menyebabkan masalah prestasi.
- Sedia β proses memasuki keadaan ini apabila hypervisor tidak dapat memperuntukkan sumber untuk pelaksanaannya. Nilai sedia yang tinggi boleh menyebabkan masalah prestasi VM.
Kaunter prestasi CPU mesin maya asas
Penggunaan CPU, %. Menunjukkan peratusan penggunaan CPU untuk tempoh tertentu.
Bagaimana untuk menganalisis? Jika VM secara konsisten menggunakan CPU pada 90% atau terdapat puncak sehingga 100%, maka kita menghadapi masalah. Masalah boleh dinyatakan bukan sahaja dalam operasi "perlahan" aplikasi di dalam VM, tetapi juga dalam ketidakbolehaksesan VM melalui rangkaian. Jika sistem pemantauan menunjukkan bahawa VM jatuh secara berkala, perhatikan kemuncak dalam graf Penggunaan CPU.
Terdapat Penggera standard yang menunjukkan beban CPU mesin maya:
Apa yang perlu dilakukan? Jika Penggunaan CPU VM sentiasa melalui bumbung, maka anda boleh memikirkan tentang meningkatkan bilangan vCPU (malangnya, ini tidak selalu membantu) atau mengalihkan VM ke pelayan dengan pemproses yang lebih berkuasa.
Penggunaan CPU dalam MHz
Dalam graf pada Penggunaan vCenter dalam % anda hanya boleh melihat untuk keseluruhan mesin maya; tiada graf untuk teras individu (dalam Esxtop terdapat % nilai untuk teras). Untuk setiap teras anda boleh melihat Penggunaan dalam MHz.
Bagaimana untuk menganalisis? Ia berlaku bahawa aplikasi tidak dioptimumkan untuk seni bina berbilang teras: ia menggunakan hanya satu teras 100%, dan selebihnya melahu tanpa beban. Contohnya, dengan tetapan sandaran lalai, MS SQL memulakan proses pada satu teras sahaja. Akibatnya, sandaran menjadi perlahan bukan kerana kelajuan cakera yang perlahan (inilah yang pengguna aduan pada mulanya), tetapi kerana pemproses tidak dapat mengatasinya. Masalahnya diselesaikan dengan menukar parameter: sandaran mula berjalan selari dalam beberapa fail (masing-masing, dalam beberapa proses).
Contoh beban tidak sekata pada teras.
Terdapat juga situasi (seperti dalam graf di atas) apabila teras dimuatkan secara tidak sekata dan sebahagian daripadanya mempunyai puncak 100%. Seperti memuatkan hanya satu teras, penggera untuk Penggunaan CPU tidak akan berfungsi (ia adalah untuk keseluruhan VM), tetapi akan ada masalah prestasi.
Apa yang perlu dilakukan? Jika perisian dalam mesin maya memuatkan teras secara tidak sekata (hanya menggunakan satu teras atau sebahagian daripada teras), tidak ada gunanya menambah bilangannya. Dalam kes ini, adalah lebih baik untuk memindahkan VM ke pelayan dengan pemproses yang lebih berkuasa.
Anda juga boleh cuba menyemak tetapan penggunaan kuasa dalam BIOS pelayan. Banyak pentadbir mendayakan mod Prestasi Tinggi dalam BIOS dan dengan itu melumpuhkan teknologi penjimatan tenaga C-states dan P-states. Pemproses Intel moden menggunakan teknologi Turbo Boost, yang meningkatkan kekerapan teras pemproses individu dengan mengorbankan teras lain. Tetapi ia hanya berfungsi apabila teknologi penjimatan tenaga dihidupkan. Jika kita melumpuhkannya, pemproses tidak dapat mengurangkan penggunaan kuasa teras yang tidak dimuatkan.
VMware mengesyorkan supaya tidak melumpuhkan teknologi penjimatan kuasa pada pelayan, tetapi memilih mod yang menyerahkan pengurusan kuasa kepada hypervisor sebanyak mungkin. Dalam kes ini, dalam tetapan penggunaan kuasa hipervisor, anda perlu memilih Prestasi Tinggi.
Jika anda mempunyai VM individu (atau teras VM) dalam infrastruktur anda yang memerlukan peningkatan kekerapan CPU, pelarasan penggunaan kuasa dengan betul boleh meningkatkan prestasinya dengan ketara.
CPU Sedia
Jika teras VM (vCPU) berada dalam keadaan Sedia, ia tidak melaksanakan kerja yang berguna. Keadaan ini berlaku apabila hipervisor tidak menemui teras fizikal percuma yang mana proses vCPU mesin maya boleh diberikan.
Bagaimana untuk menganalisis? Biasanya, jika teras mesin maya berada dalam keadaan Sedia lebih daripada 10% masa, anda akan melihat isu prestasi. Ringkasnya, lebih daripada 10% masa VM menunggu sumber fizikal tersedia.
Dalam vCenter anda boleh melihat 2 kaunter yang berkaitan dengan CPU Ready:
- kesediaan,
- Sedia.
Nilai kedua-dua pembilang boleh dilihat untuk keseluruhan VM dan untuk teras individu.
Kesediaan menunjukkan nilai serta-merta sebagai peratusan, tetapi hanya dalam Masa Nyata (data untuk jam terakhir, selang pengukuran 20 saat). Adalah lebih baik untuk menggunakan kaunter ini hanya untuk mencari masalah "panas pada tumit".
Nilai kaunter sedia juga boleh dilihat dari perspektif sejarah. Ini berguna untuk mewujudkan corak dan untuk analisis masalah yang lebih mendalam. Sebagai contoh, jika mesin maya mula mengalami masalah prestasi pada masa tertentu, anda boleh membandingkan selang nilai Sedia CPU dengan jumlah beban pada pelayan tempat VM ini berjalan dan mengambil langkah untuk mengurangkan beban (jika DRS gagal).
Bersedia, tidak seperti Kesediaan, ditunjukkan bukan sebagai peratusan, tetapi dalam milisaat. Ini ialah pembilang jenis Penjumlahan, iaitu, ia menunjukkan berapa lama dalam tempoh pengukuran teras VM berada dalam keadaan Sedia. Anda boleh menukar nilai ini kepada peratusan menggunakan formula mudah:
(Nilai penjumlahan sedia CPU / (selang kemas kini lalai carta dalam saat * 1000)) * 100 = CPU sedia %
Sebagai contoh, untuk VM dalam graf di bawah, nilai Sedia puncak untuk keseluruhan mesin maya adalah seperti berikut:
Apabila mengira peratusan Sedia, anda harus memberi perhatian kepada dua mata:
- Nilai Sedia untuk keseluruhan VM ialah jumlah Sedia merentas teras.
- Selang pengukuran. Untuk Masa Nyata ia adalah 20 saat, dan, sebagai contoh, pada carta harian ialah 300 saat.
Dengan penyelesaian masalah yang aktif, perkara mudah ini mudah terlepas dan masa yang berharga boleh dibazirkan untuk menyelesaikan masalah yang tidak wujud.
Mari kita mengira Sedia berdasarkan data daripada graf di bawah. (324474/(20*1000))*100 = 1622% untuk keseluruhan VM. Jika anda melihat intinya, ia tidak begitu menakutkan: 1622/64 = 25% setiap teras. Dalam kes ini, tangkapan agak mudah dikesan: nilai Sedia tidak realistik. Tetapi jika kita bercakap tentang 10β20% untuk keseluruhan VM dengan beberapa teras, maka bagi setiap teras nilainya mungkin berada dalam julat normal.
Apa yang perlu dilakukan? Nilai Sedia yang tinggi menunjukkan bahawa pelayan tidak mempunyai sumber pemproses yang mencukupi untuk operasi biasa mesin maya. Dalam keadaan sedemikian, yang tinggal hanyalah mengurangkan lebihan langganan oleh pemproses (vCPU:pCPU). Jelas sekali, ini boleh dicapai dengan mengurangkan parameter VM sedia ada atau dengan memindahkan sebahagian daripada VM ke pelayan lain.
Berhenti bersama
Bagaimana untuk menganalisis? Kaunter ini juga daripada jenis Penjumlahan dan ditukar kepada peratusan dengan cara yang sama seperti Sedia:
(Nilai penjumlahan henti bersama CPU / (selang kemas kini lalai carta dalam saat * 1000)) * 100 = % berhenti bersama CPU
Di sini anda juga perlu memberi perhatian kepada bilangan teras pada VM dan selang pengukuran.
Dalam keadaan costop, kernel tidak melakukan kerja yang berguna. Dengan pemilihan saiz VM yang betul dan beban biasa pada pelayan, kaunter henti bersama hendaklah hampir kepada sifar.
Dalam kes ini, beban jelas tidak normal :)
Apa yang perlu dilakukan? Jika beberapa VM dengan bilangan teras yang banyak dijalankan pada satu hipervisor dan terdapat lebihan langganan pada CPU, maka kaunter henti bersama mungkin meningkat, yang akan membawa kepada masalah dengan prestasi VM ini.
Selain itu, henti bersama akan meningkat jika teras aktif satu VM menggunakan benang pada satu teras pelayan fizikal dengan hyper-treading didayakan. Situasi ini mungkin timbul, sebagai contoh, jika VM mempunyai lebih banyak teras daripada yang tersedia secara fizikal pada pelayan tempat ia berjalan, atau jika tetapan "preferHT" didayakan untuk VM. Anda boleh membaca tentang tetapan ini .
Untuk mengelakkan masalah dengan prestasi VM akibat hentian bersama yang tinggi, pilih saiz VM mengikut pengesyoran pengeluar perisian yang berjalan pada VM ini dan keupayaan pelayan fizikal tempat VM berjalan.
Jangan tambah teras dalam simpanan; ini boleh menyebabkan masalah prestasi bukan sahaja untuk VM itu sendiri, tetapi juga untuk jirannya pada pelayan.
Metrik CPU lain yang berguna
Main β berapa banyak masa (ms) dalam tempoh pengukuran vCPU berada dalam keadaan RUN, iaitu, ia sebenarnya menjalankan kerja yang berguna.
Melahu β berapa lama (ms) dalam tempoh pengukuran vCPU berada dalam keadaan tidak aktif. Nilai Terbiar yang tinggi tidak menjadi masalah, vCPU hanya "tiada kena mengena".
Tunggu β berapa lama (ms) semasa tempoh pengukuran vCPU berada dalam keadaan Tunggu. Memandangkan IDLE disertakan dalam kaunter ini, nilai Tunggu yang tinggi juga tidak menunjukkan masalah. Tetapi jika Tunggu IDLE rendah apabila Tunggu tinggi, ini bermakna VM sedang menunggu operasi I/O selesai, dan ini, seterusnya, mungkin menunjukkan masalah dengan prestasi cakera keras atau mana-mana peranti maya VM.
Maks terhad β berapa lama (ms) dalam tempoh pengukuran vCPU berada dalam keadaan Sedia disebabkan oleh had sumber yang ditetapkan. Jika prestasi tidak dapat dijelaskan rendah, maka adalah berguna untuk menyemak nilai kaunter ini dan had CPU dalam tetapan VM. VM mungkin mempunyai had yang anda tidak ketahui. Sebagai contoh, ini berlaku apabila VM diklon daripada templat yang had CPU ditetapkan.
Tukar tunggu β berapa lama dalam tempoh pengukuran vCPU menunggu operasi dengan VMkernel Swap. Jika nilai kaunter ini melebihi sifar, maka VM pasti mempunyai masalah prestasi. Kami akan bercakap lebih lanjut mengenai SWAP dalam artikel tentang pembilang RAM.
ESXTOP
Jika kaunter prestasi dalam vCenter bagus untuk menganalisis data sejarah, maka analisis operasi masalah lebih baik dilakukan dalam ESXTOP. Di sini, semua nilai dibentangkan dalam bentuk siap pakai (tidak perlu menterjemah apa-apa), dan tempoh pengukuran minimum ialah 2 saat.
Skrin ESXTOP untuk CPU dipanggil dengan kekunci "c" dan kelihatan seperti ini:
Untuk kemudahan, anda boleh meninggalkan proses mesin maya sahaja dengan menekan Shift-V.
Untuk melihat metrik bagi teras VM individu, tekan "e" dan masukkan GID VM yang diminati (30919 dalam tangkapan skrin di bawah):
Izinkan saya menyemak secara ringkas lajur yang dibentangkan secara lalai. Lajur tambahan boleh ditambah dengan menekan "f".
NWLD (Bilangan Dunia) β bilangan proses dalam kumpulan. Untuk mengembangkan kumpulan dan melihat metrik bagi setiap proses (contohnya, untuk setiap teras dalam VM berbilang teras), tekan "e". Jika terdapat lebih daripada satu proses dalam kumpulan, maka nilai metrik untuk kumpulan adalah sama dengan jumlah metrik untuk proses individu.
%DIGUNAKAN β berapa banyak kitaran CPU pelayan digunakan oleh proses atau kumpulan proses.
%RUN β berapa lama dalam tempoh pengukuran proses berada dalam keadaan RUN, i.e. melakukan kerja yang berguna. Ia berbeza daripada %USED kerana ia tidak mengambil kira hyper-threading, penskalaan kekerapan dan masa yang dibelanjakan untuk tugas sistem (%SYS).
%SYS β masa yang dihabiskan untuk tugasan sistem, contohnya: pemprosesan gangguan, I/O, operasi rangkaian, dsb. Nilai boleh menjadi tinggi jika VM mempunyai I/O yang besar.
%OVRLP β berapa lama masa teras fizikal di mana proses VM dijalankan dibelanjakan untuk tugasan proses lain.
Metrik ini berkaitan antara satu sama lain seperti berikut:
%USED = %RUN + %SYS - %OVRLP.
Biasanya metrik %USED adalah lebih bermaklumat.
%TUNGGU β berapa lama dalam tempoh pengukuran proses berada dalam keadaan Tunggu. Mendayakan IDLE.
%IDLE β berapa lama dalam tempoh pengukuran proses berada dalam keadaan IDLE.
%SWPWT β berapa lama dalam tempoh pengukuran vCPU menunggu operasi dengan VMkernel Swap.
%VMWAIT β berapa lama dalam tempoh pengukuran vCPU berada dalam keadaan menunggu acara (biasanya I/O). Tiada kaunter serupa dalam vCenter. Nilai tinggi menunjukkan masalah dengan I/O pada VM.
%TUNGGU = %VMWAIT + %IDLE + %SWPWT.
Jika VM tidak menggunakan VMkernel Swap, maka apabila menganalisis masalah prestasi adalah dinasihatkan untuk melihat %VMWAIT, kerana metrik ini tidak mengambil kira masa VM tidak melakukan apa-apa (%IDLE).
%RDY β berapa lama dalam tempoh pengukuran proses berada dalam keadaan Sedia.
%CSTP β berapa lama dalam tempoh pengukuran proses berada dalam keadaan costop.
%MLMTD β berapa lama dalam tempoh pengukuran vCPU berada dalam keadaan Sedia disebabkan oleh had sumber yang ditetapkan.
%WAIT + %RDY + %CSTP + %RUN = 100% β teras VM sentiasa berada dalam salah satu daripada empat keadaan ini.
CPU pada hypervisor
vCenter juga mempunyai pembilang prestasi CPU untuk hipervisor, tetapi ia tidak menarik - ia hanyalah jumlah pembilang untuk semua VM pada pelayan.
Cara paling mudah untuk melihat status CPU pada pelayan adalah pada tab Ringkasan:
Untuk pelayan, serta untuk mesin maya, terdapat Penggera standard:
Apabila beban CPU pelayan tinggi, VM yang berjalan padanya mula mengalami masalah prestasi.
Dalam ESXTOP, data beban CPU pelayan dibentangkan di bahagian atas skrin. Sebagai tambahan kepada beban CPU standard, yang tidak begitu bermaklumat untuk hipervisor, terdapat tiga lagi metrik:
UTIL TERAS(%) β memuatkan teras pelayan fizikal. Kaunter ini menunjukkan tempoh masa teras melakukan kerja semasa tempoh pengukuran.
PCPU UTIL(%) β jika hyper-threading didayakan, maka terdapat dua thread (PCPU) setiap teras fizikal. Metrik ini menunjukkan tempoh masa yang diambil oleh setiap urutan untuk menyelesaikan kerja.
PCPU DIGUNAKAN(%) β sama seperti PCPU UTIL(%), tetapi mengambil kira penskalaan kekerapan (sama ada mengurangkan kekerapan teras untuk tujuan penjimatan tenaga, atau meningkatkan frekuensi teras disebabkan oleh teknologi Turbo Boost) dan hyper-threading.
PCPU_USED% = PCPU_UTIL% * kekerapan teras berkesan / kekerapan teras nominal.
Dalam tangkapan skrin ini, untuk sesetengah teras, disebabkan Turbo Boost, nilai USED adalah lebih besar daripada 100%, kerana kekerapan teras lebih tinggi daripada yang nominal.
Beberapa perkataan tentang bagaimana hyper-threading diambil kira. Jika proses dilaksanakan 100% daripada masa pada kedua-dua utas teras fizikal pelayan, manakala teras beroperasi pada frekuensi nominal, maka:
- UTIL TERAS untuk teras akan menjadi 100%,
- UTIL PCPU untuk kedua-dua benang akan menjadi 100%,
- PCPU DIGUNAKAN untuk kedua-dua benang akan menjadi 50%.
Jika kedua-dua benang tidak berfungsi 100% sepanjang tempoh pengukuran, maka dalam tempoh tersebut apabila benang berfungsi selari, PCPU YANG DIGUNAKAN untuk teras dibahagikan kepada separuh.
ESXTOP juga mempunyai skrin dengan parameter penggunaan kuasa CPU pelayan. Di sini anda boleh melihat sama ada pelayan menggunakan teknologi penjimatan tenaga: C-states dan P-states. Dipanggil oleh kekunci "p":
Isu Prestasi CPU Biasa
Akhir sekali, saya akan membincangkan punca biasa masalah dengan prestasi CPU VM dan memberikan petua ringkas untuk menyelesaikannya:
Kelajuan jam teras tidak mencukupi. Jika tidak mungkin untuk meningkatkan VM anda kepada teras yang lebih berkuasa, anda boleh cuba menukar tetapan kuasa untuk menjadikan Turbo Boost berfungsi dengan lebih cekap.
Saiz VM yang salah (terlalu banyak/sedikit teras). Jika anda memasang beberapa teras, akan terdapat beban CPU yang tinggi pada VM. Jika ada banyak, tangkap hentian bersama yang tinggi.
Langganan berlebihan CPU yang besar pada pelayan. Jika VM mempunyai Ready yang tinggi, kurangkan lebihan langganan CPU.
Topologi NUMA yang salah pada VM besar. Topologi NUMA yang dilihat oleh VM (vNUMA) mesti sepadan dengan topologi NUMA pelayan (pNUMA). Diagnostik dan penyelesaian yang mungkin untuk masalah ini ditulis, sebagai contoh, dalam buku . Jika anda tidak mahu pergi lebih dalam dan anda tidak mempunyai sekatan pelesenan pada OS yang dipasang pada VM, buat banyak soket maya pada VM, satu teras pada satu masa. Anda tidak akan rugi banyak :)
Itu sahaja untuk saya tentang CPU. Bertanya soalan. Dalam bahagian seterusnya saya akan bercakap tentang RAM.
Pautan berguna
Sumber: www.habr.com