Maok: anu maok waktu processor ti mesin virtual

Halo! Abdi hoyong nyarioskeun ka anjeun dina istilah anu saderhana ngeunaan mékanika maok di jero mesin virtual sareng ngeunaan sababaraha artefak anu teu jelas anu urang junun mendakan nalika panalungtikanana, anu kuring kedah teuleum salaku diréktur téknis tina platform awan. Mail.ru Cloud Solutions. Platformna dijalankeun dina KVM.

CPU maok waktu nyaéta waktu salila mesin virtual teu narima sumberdaya processor pikeun palaksanaan na. Waktu ieu ukur diitung dina sistem operasi tamu di lingkungan virtualisasi. Alesan pikeun mana sumber daya anu paling dialokasikeun ieu, sapertos dina kahirupan, samar-samar. Tapi urang mutuskeun pikeun angka kaluar, komo dilumangsungkeun sababaraha percobaan. Éta sanés yén urang ayeuna terang sadayana ngeunaan maling, tapi kami bakal nyarioskeun ka anjeun anu pikaresepeun ayeuna.

1. Naon maling

Janten, maok mangrupikeun métrik anu nunjukkeun kakurangan waktos prosésor pikeun prosés di jero mesin virtual. Sakumaha anu dijelaskeun dina patch kernel KVMSiluman mangrupikeun waktos nalika hypervisor ngalaksanakeun prosés sanés dina OS host sanaos parantos ngantri prosés mesin virtual pikeun dieksekusi. Hartina, maok diitung salaku bédana antara waktu nalika prosés geus siap ngaéksekusi jeung waktu nalika prosés dialokasikeun waktu processor.

Kernel mesin virtual nampi métrik maok tina hypervisor. Dina waktos anu sami, hypervisor henteu netepkeun persis naon prosés anu sanésna dijalankeun, éta ngan ukur nyarios "bari kuring sibuk, kuring henteu tiasa masihan anjeun waktos." Dina KVM, rojongan pikeun maok itungan geus ditambahkeun kana tambalan. Aya dua titik konci di dieu:

• Mesin virtual diajar ngeunaan maok tina hypervisor. Hartina, tina sudut pandang karugian, pikeun prosés dina mesin virtual éta mangrupikeun pangukuran henteu langsung anu tiasa tunduk kana rupa-rupa distorsi.
• Hypervisor henteu ngabagi inpormasi sareng mesin virtual ngeunaan naon anu dilakukeun - hal utama nyaéta yén éta henteu nyéépkeun waktosna. Kusabab ieu, mesin virtual sorangan henteu tiasa ngadeteksi distorsi dina indikator maok, anu tiasa ditaksir ku sifat prosés anu bersaing.

2. Naon mangaruhan maling

2.1. Maok itungan

Intina, maok diitung kira-kira sarua jeung waktu utilization CPU normal. Henteu seueur inpormasi ngeunaan kumaha daur ulang dianggap. Panginten kusabab kalolobaan jalma nganggap patarosan ieu atra. Tapi aya ogé pitfalls di dieu. Pikeun familiarize diri sareng prosés ieu, anjeun tiasa maca artikel ku Brendan Gregg: anjeun bakal diajar ngeunaan seueur nuansa nalika ngitung pamakean sareng ngeunaan kaayaan nalika itungan ieu bakal salah kusabab alesan ieu:

• Prosesor overheats, ngabalukarkeun siklus skip.
• Aktipkeun / nganonaktipkeun turbo dorongan, nu ngarobah frékuénsi jam processor.
• Parobihan dina panjang potongan waktos anu lumangsung nalika nganggo téknologi hemat daya prosesor sapertos SpeedStep.
• Masalah sareng ngitung rata-rata: estimasi utilization hiji menit dina 80% bisa nyumputkeun burst jangka pondok tina 100%.
• A konci spin ngabalukarkeun processor reclaimed, tapi prosés pamaké teu ningali kamajuan naon baé dina palaksanaan na. Hasilna, utilization processor diitung ku prosés bakal saratus persen, sanajan prosés moal fisik meakeun waktu processor.

Kuring henteu acan mendakan tulisan anu ngajelaskeun itungan anu sami pikeun maok (upami anjeun terang, bagikeun dina koméntar). Tapi, ditilik ku kode sumber, mékanisme itungan sami sareng daur ulang. Kantun, counter sejen ditambahkeun dina kernel, langsung pikeun prosés KVM (prosés mesin virtual), nu diitung lilana prosés KVM ngantosan waktos CPU. Loket nyandak inpormasi ngeunaan prosésor tina spésifikasina sareng mariksa naha sadaya keletikna dianggo ku prosés mesin virtual. Upami éta sadayana, teras urang nganggap yén prosésor ngan ukur dijajah ku prosés mesin virtual. Upami teu kitu, urang ngawartosan yén processor ieu ngalakukeun hal sejenna, maok mucunghul.

Prosés cacah maok tunduk kana masalah anu sarua sakumaha cacah daur ulang biasa. Henteu kedah nyarios yén masalah sapertos kitu sering muncul, tapi aranjeunna ngahambat.

2.2. Jinis virtualisasi dina KVM

Sacara umum, aya tilu jinis virtualisasi, sadayana dirojong ku KVM. Mékanisme maok lumangsungna bisa gumantung kana jenis virtualization.

Broadcast. Dina hal ieu, operasi sistem operasi mesin virtual sareng alat hypervisor fisik lumangsung sapertos kieu:

1. Sistem operasi tamu ngirimkeun paréntah ka alat tamu na.
2. Supir alat tamu nampi paréntah, ngahasilkeun pamundut pikeun mios alat sareng ngirimkeunana ka hypervisor.
3. Prosés hypervisor narjamahkeun paréntah pikeun paréntah pikeun alat fisik, sahingga, antara séjén, leuwih aman.
4. Supir alat fisik nampi paréntah anu dirobih sareng ngirimkeunana ka alat fisik éta sorangan.
5. Hasil palaksanaan paréntah balik deui sapanjang jalur anu sami.

Kauntungannana tarjamahan nyaéta ngamungkinkeun anjeun niru alat naon waé sareng henteu ngabutuhkeun persiapan khusus tina kernel sistem operasi. Tapi anjeun kudu mayar ieu, mimiti sagala, dina speed.

Virtualisasi hardware. Dina hal ieu, alat dina tingkat hardware ngartos paréntah tina sistem operasi. Ieu cara panggancangna jeung pangalusna. Tapi, hanjakalna, éta henteu dirojong ku sadaya alat fisik, hypervisors sareng sistem operasi tamu. Ayeuna, alat utama anu ngadukung virtualisasi hardware nyaéta prosesor.

Paravirtualisasi. Pilihan anu paling umum pikeun virtualisasi alat dina KVM sareng umumna mode virtualisasi anu paling umum pikeun sistem operasi tamu. Keunikanana nyaéta yén gawé bareng sababaraha subsistem hypervisor (contona, sareng jaringan atanapi tumpukan disk) atanapi alokasi halaman mémori lumangsung nganggo API hypervisor, tanpa narjamahkeun paréntah tingkat rendah. Karugian tina metode virtualisasi ieu nyaéta kernel sistem operasi tamu kedah dirobih supados tiasa komunikasi sareng hypervisor nganggo API ieu. Tapi ieu biasana direngsekeun ku masang drivers husus dina sistem operasi tamu. Dina KVM API ieu disebut virtio API.

Kalayan paravirtualization, dibandingkeun sareng siaran, jalur ka alat fisik dikirangan sacara signifikan ku ngirim paréntah langsung tina mesin virtual kana prosés hypervisor dina host. Ieu ngamungkinkeun anjeun nyepetkeun palaksanaan sadaya paréntah di jero mesin virtual. Dina KVM, ieu dilakukeun ku API virtio, anu ngan ukur dianggo pikeun alat anu tangtu, sapertos jaringan atanapi adaptor disk. Ieu sababna supir virtio dipasang di jero mesin virtual.

Karugian tina akselerasi ieu nyaéta henteu sadayana prosés anu dijalankeun di jero mesin virtual tetep aya di jerona. Ieu nyiptakeun sababaraha épék husus anu bisa ngahasilkeun spawning on maok. Abdi nyarankeun ngamimitian ulikan lengkep ngeunaan masalah ieu kalawan Hiji API pikeun virtual I / O: virtio.

2.3. "Adil" jadwal

Mesin virtual dina hypervisor, saleresna, mangrupikeun prosés biasa anu patuh kana hukum jadwal (distribusi sumberdaya antara prosés) dina kernel Linux, janten hayu urang tingali.

Linux Ubuntu ngagunakeun disebut CFS, Lengkep Fair Scheduler, nu geus jadi scheduler standar saprak kernel 2.6.23. Pikeun ngartos algoritma ieu, anjeun tiasa maca Arsitéktur Kernel Linux atanapi kode sumber. Hakekat CFS nyaéta ngadistribusikaeun waktu prosésor antara prosés gumantung kana lilana palaksanaan maranéhanana. Beuki CPU waktos hiji prosés merlukeun, kirang waktos CPU eta narima. Ieu ensures yén sakabéh prosés anu dieksekusi "cukup" - ambéh hiji prosés teu terus nempatan sakabéh prosesor, sarta prosés séjén ogé bisa ngaéksekusi.

Kadang paradigma ieu ngakibatkeun artefak metot. Pangguna Linux anu lami-lami sigana émut kana katirisan pangropéa téksu biasa dina desktop nalika ngajalankeun aplikasi anu intensif sumber daya sapertos kompiler. Ieu kajadian sabab tugas non-sumberdaya-intensif dina aplikasi desktop bersaing jeung tugas sumberdaya-intensif, kayaning compiler. CFS nyangka ieu teu adil, ku kituna périodik eureun pangropéa téksu sarta ngidinan processor nanganan tugas compiler urang. Ieu dilereskeun ngagunakeun mékanisme a sched_autogroup, Tapi loba fitur sejenna sebaran waktu processor antara tugas tetep. Sabenerna, ieu sanes carita ngeunaan kumaha goréng sagalana aya dina CFS, tapi usaha ngagambar perhatian kanyataan yén distribusi "adil" waktu processor sanes tugas paling trivial.

titik penting séjénna dina scheduler nyaeta preemption. Ieu diperlukeun pikeun kick kaluar prosés snickering ti processor sarta ngantep batur dianggo. Prosés ejection disebut context switching. Dina hal ieu, sakabéh kontéks tugas dilestarikan: kaayaan tumpukan, registers, jeung sajabana, nu satutasna prosés ieu dikirim ka antosan, sarta hiji deui lumangsung. Ieu mangrupikeun operasi anu mahal pikeun OS sareng jarang dianggo, tapi teu aya anu lepat sareng éta. Ngalihkeun kontéks sering tiasa nunjukkeun masalah dina OS, tapi biasana kontinyu sareng henteu nunjukkeun nanaon khusus.

Sapertos carita anu panjang diperyogikeun pikeun ngajelaskeun hiji kanyataan: langkung seueur sumber daya prosésor anu dicoba pikeun dikonsumsi dina scheduler Linux anu jujur, langkung gancang éta bakal dieureunkeun supados prosés sanésna ogé tiasa jalan. Naha ieu leres atanapi henteu mangrupikeun patarosan anu rumit anu tiasa direngsekeun sacara béda dina beban anu béda. Dina Windows, dugi ka ayeuna, scheduler fokus kana ngolah prioritas aplikasi desktop, anu tiasa nyababkeun prosés latar tukang beku. Sun Solaris ngagaduhan lima kelas jadwal anu béda. Nalika kami ngaluncurkeun virtualisasi, kami nambihan anu kagenep, Jadwal bagikeun adil, sabab lima saméméhna teu dianggo adequately kalawan virtualization Zona Solaris. Abdi nyarankeun ngamimitian ulikan lengkep ngeunaan masalah ieu sareng buku sapertos Solaris Internals: Solaris 10 sareng Arsitéktur Kernel OpenSolaris atawa Ngartos Linux Kernel.

2.4. Kumaha ngawas maling?

Ngawaskeun maok di jero mesin virtual, sapertos métrik prosésor anu sanés, saderhana: anjeun tiasa nganggo alat métrik prosésor. Hal utama nyaéta yén mesin virtual aya dina Linux. Kanggo sababaraha alesan Windows henteu masihan inpormasi ieu ka panggunana. 🙁

Kaluaran paréntah luhur: rinci ngeunaan beban processor, dina kolom paling katuhu - maok

Kasusah timbul nalika nyobian pikeun ménta inpo ieu ti hypervisor nu. Anjeun tiasa nyobian ngaduga maok dina mesin host, contona, ngagunakeun beban Rata-rata (LA) parameter - nilai rata-rata jumlah prosés ngantosan dina antrian palaksanaan. Metoda keur ngitung parameter ieu teu basajan, tapi sacara umum, lamun LA dinormalisasi ku Jumlah threads processor leuwih ti 1, ieu nunjukkeun yén server Linux Ubuntu overloaded kalawan hal.

Naon anu ngantosan sadayana prosés ieu? Jawaban atra nyaéta prosésor. Tapi jawaban teu sagemblengna bener, sabab kadang processor bébas, tapi LA mana kaluar skala. Inget kumaha NFS ragrag na kumaha LA tumuwuh. Hal anu sami tiasa kajantenan sareng disk sareng alat input / output anu sanés. Tapi kanyataanna, prosés tiasa ngantosan tungtung konci naon, boh fisik, pakait sareng alat I / O, atanapi logis, sapertos mutex. Ieu ogé kalebet ngonci dina tingkat hardware (réspon anu sami tina disk), atanapi logika (nu disebut primitif ngonci, anu kalebet sakumpulan éntitas, mutex adaptif sareng spin, semaphore, variabel kaayaan, konci rw, konci ipc. ...).

Fitur séjén LA nyaéta yén éta dianggap rata-rata sistem operasi. Salaku conto, 100 prosés bersaing pikeun hiji file, teras LA = 50. Sapertos nilai ageung sigana nunjukkeun yén sistem operasi goréng. Tapi pikeun kode ditulis crookedly sejen, ieu bisa jadi kaayaan normal, sanajan kanyataan yén ngan éta goréng, sarta prosés séjén dina sistem operasi teu sangsara.

Kusabab rata-rata ieu (sareng henteu kirang ti menit), nangtukeun naon waé ku indikator LA sanés tugas anu paling nguntungkeun, kalayan hasil anu teu pasti dina kasus khusus. Upami anjeun nyobian ngémutan éta, anjeun bakal mendakan yén tulisan dina Wikipédia sareng sumber-sumber sanésna ngan ukur ngajelaskeun kasus anu paling sederhana, tanpa katerangan anu jero ngeunaan prosésna. Abdi ngintunkeun sadayana anu minat, deui, di dieu pikeun Brendan Gregg  - tuturkeun tumbu di handap ieu. Saha nu puguh basa Inggris - tarjamahan artikel populér ngeunaan LA.

3. épék husus

Ayeuna hayu urang nempo kasus utama maling nu urang encountered. Kuring gé ngabejaan ka maneh kumaha maranéhna nuturkeun tina sagala di luhur sarta kumaha aranjeunna pakaitna jeung indikator on hypervisor nu.

Daur ulang. Pangbasajanna sareng paling umum: hypervisor parantos dianggo deui. Mémang, aya loba ngajalankeun mesin virtual, konsumsi processor tinggi jero aranjeunna, loba kompetisi, utilization LA leuwih ti 1 (dinormalisasi ku threads processor). Sagalana di jero sadaya mesin virtual ngalambatkeun. Maok dikirimkeun ti hypervisor ogé tumuwuh, perlu redistribute beban atawa mareuman batur. Sacara umum, sagalana logis tur kaharti.

Paravirtualization vs Instansi Tunggal. Aya ngan hiji mesin virtual on hypervisor nu; eta meakeun sabagian leutik eta, tapi ngahasilkeun I / O beban badag, contona dina disk. Sareng ti mana waé aya maling leutik, dugi ka 10% (sapertos anu dipidangkeun ku sababaraha percobaan).

Kasusna matak pikabitaeun. Maling muncul di dieu persis kusabab ngahalangan dina tingkat drivers paravirtualized. Interupsi didamel di jero mesin virtual, diolah ku supir sareng dikirim ka hypervisor. Alatan penanganan interupsi on hypervisor nu, pikeun mesin virtual Sigana mah a pamundut dikirim, éta siap pikeun palaksanaan sarta ngantosan processor, tapi teu dibikeun waktos processor. Gadis maya nyangka yén waktos ieu parantos dipaling.

Ieu lumangsung dina momen panyangga dikirim, eta mana kana spasi kernel of hypervisor, sarta kami ngawitan ngantosan eta. Sanajan, ti sudut pandang tina mesin virtual, manéhna kudu balik langsung. Ku alatan éta, nurutkeun algoritma itungan maok, waktos ieu dianggap dipaling. Paling dipikaresep, dina kaayaan ieu meureun aya mékanisme séjén (contona, ngolah sababaraha sauran sys séjén), tapi maranéhna teu kudu jauh béda.

Penjadwal versus mesin virtual anu sarat pisan. Lamun hiji mesin virtual nalangsara ti maok leuwih ti batur, ieu alatan scheduler nu. Beuki hiji prosés ngamuat prosésor, nu sooner scheduler bakal kick eta kaluar ku kituna batur ogé bisa jalan. Lamun mesin virtual meakeun saeutik, boro bakal ningali maok: prosés na jujur ​​diuk na waited, urang kudu masihan deui waktos. Lamun mesin virtual ngahasilkeun beban maksimum dina sakabéh cores na, mindeng ditajong kaluar tina processor na aranjeunna nyobian teu masihan eta loba waktu.

Malah leuwih parah lamun prosés di jero mesin virtual nyoba meunang leuwih processor sabab teu bisa Cope jeung ngolah data. Lajeng sistem operasi on hypervisor nu, alatan optimasi jujur, bakal nyadiakeun kirang na kirang waktos processor. Prosés ieu lumangsung kawas longsoran, sarta maok jumps ka langit, sanajan mesin virtual lianna bisa boro perhatikeun eta. Jeung leuwih cores, nu parah mesin kapangaruhan. Pondokna, mesin virtual anu sarat pisan sareng seueur inti anu paling sangsara.

Low LA, tapi aya maok. Upami LA kirang langkung 0,7 (nyaéta, hypervisor sigana teu kabeban), tapi maling dititénan dina mesin virtual individu:

• Pilihan sareng paravirtualization parantos dijelaskeun di luhur. Mesin virtual tiasa nampi métrik anu nunjukkeun maok, sanaos hypervisor henteu kunanaon. Numutkeun hasil percobaan kami, pilihan maok ieu teu ngaleuwihan 10% jeung teu kudu boga dampak signifikan dina kinerja aplikasi dina mesin virtual.
• Parameter LA diitung salah. Leuwih tepat, dina unggal momen husus diitung leres, tapi lamun averaged leuwih hiji menit tétéla underestimated. Contona, upami hiji mesin virtual per katilu hypervisor nu meakeun sakabéh prosesor na persis satengah menit, lajeng LA per menit on hypervisor bakal 0,15; opat mesin virtual sapertos dianggo sakaligus bakal masihan 0,6. Sareng kanyataan yén pikeun satengah menit dina masing-masing aya maling liar dina 25% numutkeun indikator LA henteu tiasa ditarik deui.
• Deui, kusabab scheduler anu mutuskeun yén batur ieu dahar teuing sarta ngantep éta batur antosan. Samentawis waktos, kuring bakal ngagentos kontéks, nanganan interrupts sareng ngurus hal-hal sistem anu penting. Hasilna, sababaraha mesin virtual teu ningali masalah naon, sedengkeun nu sejenna ngalaman degradasi kinerja serius.

4. distorsi séjén

Aya sajuta deui alesan pikeun distorting balik adil waktu processor dina mesin virtual. Contona, hyperthreading jeung NUMA ngawanohkeun kasusah kana itungan. Aranjeunna lengkep galau pilihan kernel pikeun executing prosés, sabab scheduler ngagunakeun koefisien - beurat, nu ngajadikeun itungan malah leuwih hese lamun ngaganti konteks.

Aya distorsi kusabab téknologi sapertos dorongan turbo atanapi, sabalikna, mode hemat energi, anu, nalika ngitung pamakean, sacara artifisial tiasa ningkatkeun atanapi ngirangan frékuénsi atanapi bahkan nyiksikan waktos dina server. Aktipkeun turbo boost ngurangan kinerja hiji prosésor thread alatan kanaékan kinerja sejen. Dina momen ieu, informasi ngeunaan frékuénsi processor ayeuna teu dikirimkeun ka mesin virtual, sarta eta percaya yén batur geus maok waktu na (contona, eta dipénta 2 GHz, tapi narima satengah éta).

Sacara umum, aya seueur alesan pikeun distorsi. Anjeun tiasa mendakan anu sanés dina sistem anu khusus. Éta langkung saé pikeun mimitian ku buku anu kuring masihan tautan di luhur, sareng nyandak statistik tina hypervisor nganggo utilitas sapertos perf, sysdig, systemtap, anu mana. puluhan.

5. Kacindekan

1. Sababaraha jumlah maling bisa lumangsung alatan paravirtualization, sarta eta bisa dianggap normal. Aranjeunna nyerat dina Internét yén nilai ieu tiasa 5-10%. Gumantung kana aplikasi di jero mesin virtual sareng beban anu dipasang dina alat fisikna. Di dieu hal anu penting pikeun nengetan kumaha aplikasi karasaeun di jero mesin virtual.
2. Babandingan beban dina hypervisor jeung maok di jero mesin virtual teu salawasna jelas saling patali; duanana estimasi maok tiasa erroneous dina situasi husus dina beban béda.
3. scheduler ngabogaan sikep goréng kana prosés nu nanya pisan. Anjeunna nyobian masihan kirang ka jalma anu menta leuwih. mesin virtual badag anu jahat.
4. A maok saeutik bisa jadi norma sanajan tanpa paravirtualization (nyandak kana akun beban jero mesin virtual, karakteristik beban tatanggana, distribusi beban sakuliah threads jeung faktor séjén).
5. Upami anjeun hoyong terang maok dina sistem anu khusus, anjeun kedah ngajalajah sababaraha pilihan, ngumpulkeun métrik, nganalisa sacara saksama sareng pikirkeun kumaha ngadistribusikaeun beban sacara merata. Panyimpangan tina kasus naon waé tiasa waé, anu kedah dikonfirmasi sacara ékspériméntal atanapi ditingali dina debugger kernel.

sumber: www.habr.com