Nyolong: sing nyolong wektu prosesor saka mesin virtual

Hello! Aku pengin ngandhani kanthi gampang babagan mekanika nyolong ing mesin virtual lan babagan sawetara artefak sing ora jelas sing bisa ditemokake sajrone riset, sing kudu dakcekel minangka direktur teknis platform awan. Solusi Cloud Mail.ru. Platform kasebut nganggo KVM.

Wektu nyolong CPU yaiku wektu nalika mesin virtual ora nampa sumber daya prosesor kanggo eksekusi. Wektu iki mung diitung ing sistem operasi tamu ing lingkungan virtualisasi. Alasan kanggo ngendi sumber daya sing paling diparengake iki, kaya ing urip, ora jelas. Nanging kita mutusake kanggo ngerteni, lan malah nindakake sawetara eksperimen. Ora saiki kita ngerti kabeh babagan nyolong, nanging saiki kita bakal ngandhani sampeyan sing menarik.

1. Apa iku nyolong

Dadi, nyolong minangka metrik sing nuduhake kekurangan wektu prosesor kanggo proses ing mesin virtual. Kaya sing diterangake ing tembelan kernel KVMSiluman yaiku wektu nalika hypervisor nglakokake proses liyane ing OS host sanajan wis antri proses mesin virtual kanggo eksekusi. Sing, nyolong diwilang minangka prabédan antarane wektu nalika proses siap kanggo nglakokaké lan wektu nalika proses diparengake wektu prosesor.

Kernel mesin virtual nampa metrik nyolong saka hypervisor. Ing wektu sing padha, hypervisor ora nemtokake persis apa proses liyane sing ditindakake, mung ujar "nalika aku sibuk, aku ora bisa menehi sampeyan wektu." Ing KVM, dhukungan kanggo pitungan nyolong wis ditambahake tambalan. Ana rong titik utama ing kene:

• Mesin virtual sinau babagan nyolong saka hypervisor. Yaiku, saka sudut pandang kerugian, kanggo pangolahan ing mesin virtual dhewe iki minangka pangukuran ora langsung sing bisa tundhuk karo macem-macem distorsi.
• Hypervisor ora nuduhake informasi karo mesin virtual babagan apa sing ditindakake - sing utama yaiku ora nyawisake wektu. Amarga iki, mesin virtual dhewe ora bisa ndeteksi distorsi ing indikator nyolong, sing bisa ditaksir miturut sifat proses saingan.

2. Apa mengaruhi nyolong

2.1. Nyolong petungan

Ateges, nyolong diitung kira-kira padha karo wektu panggunaan CPU normal. Ora ana akeh informasi babagan carane daur ulang dianggep. Mbokmenawa amarga akeh wong nganggep pitakonan iki jelas. Nanging ana uga pitfalls kene. Kanggo familiarize dhewe karo proses iki, sampeyan bisa maca artikel dening Brendan Gregg: sampeyan bakal sinau babagan akeh nuansa nalika ngetung panggunaan lan babagan kahanan nalika pitungan iki salah amarga alasan ing ngisor iki:

• Prosesor dadi overheat, nyebabake siklus skip.
• Aktifake / mateni turbo ngedongkrak, kang ngganti kacepetan jam prosesor.
• Owah-owahan ing dawa irisan wektu sing kedadeyan nalika nggunakake teknologi hemat daya prosesor kayata SpeedStep.
• Masalah karo ngitung rata-rata: ngira-ngira panggunaan siji menit ing 80% bisa ndhelikake bledosan jangka pendek 100%.
• A kunci muter nyebabake prosesor bakal mbalekake, nanging proses pangguna ora weruh kemajuan ing eksekusi. Akibaté, pemanfaatan prosesor sing diwilang dening proses kasebut bakal dadi satus persen, sanajan proses kasebut ora bakal ngonsumsi wektu prosesor kanthi fisik.

Aku durung nemokake artikel sing njlèntrèhaké pitungan sing padha kanggo nyolong (yen sampeyan ngerti, nuduhake ing komentar). Nanging, miturut kode sumber, mekanisme pitungan padha karo daur ulang. Cukup, counter liyane ditambahake ing kernel, langsung kanggo proses KVM (proses mesin virtual), sing ngitung durasi proses KVM ngenteni wektu CPU. Counter njupuk informasi babagan prosesor saka spesifikasi lan mriksa apa kabeh ticks digunakake dening proses mesin virtual. Yen kabeh iku, banjur kita nganggep yen prosesor mung dikuwasani karo proses mesin virtual. Yen ora, kita ngandhani yen prosesor nindakake perkara liya, nyolong katon.

Proses pancacahan nyolong tundhuk masalah sing padha karo pancacahan daur ulang biasa. Ora kanggo ngomong sing masalah kuwi asring katon, nanging katon pundung.

2.2. Jinis virtualisasi ing KVM

Secara umum, ana telung jinis virtualisasi, kabeh didhukung dening KVM. Mekanisme nyolong kedadeyan bisa uga gumantung saka jinis virtualisasi.

Siaran. Ing kasus iki, operasi sistem operasi mesin virtual kanthi piranti hypervisor fisik kedadeyan kaya mangkene:

1. Sistem operasi tamu ngirim printah menyang piranti tamu.
2. Driver piranti tamu nampa printah, ngasilake panjalukan kanggo BIOS piranti lan dikirim menyang hypervisor.
3. Proses hypervisor nerjemahake printah kanggo printah kanggo piranti fisik, nggawe, antarane liyane, luwih aman.
4. Pembalap piranti fisik nampa perintah sing diowahi lan dikirim menyang piranti fisik kasebut.
5. Asil eksekusi printah bali ing dalan sing padha.

Kauntungan saka terjemahan yaiku ngidini sampeyan niru piranti apa wae lan ora mbutuhake persiapan khusus saka kernel sistem operasi. Nanging sampeyan kudu mbayar iki, pisanan kabeh, ing kacepetan.

Virtualisasi hardware. Ing kasus iki, piranti ing tingkat hardware mangertos printah saka sistem operasi. Iki minangka cara sing paling cepet lan paling apik. Nanging, sayangé, ora didhukung dening kabeh piranti fisik, hypervisor lan sistem operasi tamu. Saiki, piranti utama sing ndhukung virtualisasi hardware yaiku prosesor.

Paravirtualisasi. Pilihan sing paling umum kanggo virtualisasi piranti ing KVM lan umume mode virtualisasi sing paling umum kanggo sistem operasi tamu. Keanehane yaiku nggarap sawetara subsistem hypervisor (contone, karo jaringan utawa tumpukan disk) utawa alokasi kaca memori nggunakake API hypervisor, tanpa nerjemahake perintah tingkat rendah. Kerugian metode virtualisasi iki yaiku kernel sistem operasi tamu kudu diowahi supaya bisa komunikasi karo hypervisor nggunakake API iki. Nanging iki biasane ditanggulangi kanthi nginstal driver khusus ing sistem operasi tamu. Ing KVM API iki diarani virtio API.

Kanthi paravirtualisasi, dibandhingake karo siaran, jalur menyang piranti fisik dikurangi kanthi ngirim printah langsung saka mesin virtual menyang proses hypervisor ing host. Iki ngidini sampeyan nyepetake eksekusi kabeh instruksi ing mesin virtual. Ing KVM, iki ditindakake dening API virtio, sing mung bisa digunakake kanggo piranti tartamtu, kayata adaptor jaringan utawa disk. Iki sebabe driver virtio dipasang ing mesin virtual.

Kakurangan akselerasi iki yaiku ora kabeh proses sing ana ing mesin virtual tetep ana ing njero. Iki nggawe sawetara efek khusus sing bisa nyebabake spawning ing nyolong. Aku nyaranake miwiti sinau rinci masalah iki karo API kanggo virtual I / O: virtio.

2.3. Jadwal "Adil".

Mesin virtual ing hypervisor, nyatane, proses biasa sing netepi hukum jadwal (distribusi sumber daya antarane proses) ing kernel Linux, mula ayo dideleng kanthi luwih rinci.

Linux nggunakake sing disebut CFS, Completely Fair Scheduler, sing wis dadi panjadwal standar wiwit kernel 2.6.23. Kanggo mangerteni algoritma iki, sampeyan bisa maca Arsitektur Kernel Linux utawa kode sumber. Inti saka CFS yaiku nyebarake wektu prosesor ing antarane proses gumantung saka durasi eksekusi. Sing liyane wektu CPU mbutuhake proses, wektu CPU kurang ditampa. Iki mesthekake yen kabeh proses dieksekusi "cukup" - supaya siji proses ora terus-terusan ngenggoni kabeh prosesor, lan proses liyane uga bisa ditindakake.

Kadhangkala paradigma iki nyebabake artefak sing menarik. Pangguna Linux sing wis suwe bisa uga ngelingi pembekuan editor teks biasa ing desktop nalika mbukak aplikasi intensif sumber daya kayata compiler. Iki kedadeyan amarga tugas sing ora intensif sumber daya ing aplikasi desktop saingan karo tugas intensif sumber daya, kayata compiler. CFS nganggep iki ora adil, mula kanthi periodik mungkasi editor teks lan ngidini prosesor nangani tugas kompiler. Iki didandani kanthi nggunakake mekanisme sched_autogroup, nanging akeh fitur liyane saka distribusi wektu prosesor antarane tugas tetep. Bener, iki dudu crita babagan kabeh sing ala ing CFS, nanging upaya kanggo narik kawigaten manawa distribusi wektu prosesor "adil" dudu tugas sing paling sepele.

Titik penting liyane ing panjadwal yaiku preemption. Iki perlu kanggo kick metu proses snickering saka prosesor lan supaya wong liya bisa. Proses ejeksi diarani context switching. Ing kasus iki, kabeh konteks tugas dilestarekake: kahanan tumpukan, ndhaptar, lan liya-liyane, sawise proses kasebut dikirim kanggo ngenteni, lan liyane njupuk Panggonan. Iki minangka operasi sing larang kanggo OS lan jarang digunakake, nanging ora ana sing salah. Ngalih konteks sing kerep bisa nuduhake masalah ing OS, nanging biasane terus-terusan lan ora nuduhake apa-apa.

Crita sing dawa banget dibutuhake kanggo nerangake siji kasunyatan: luwih akeh sumber daya prosesor sing nyoba digunakake ing panjadwal Linux sing jujur, luwih cepet bakal mandheg supaya proses liyane uga bisa digunakake. Apa iki bener utawa ora, iku pitakonan rumit sing bisa ditanggulangi kanthi beda ing macem-macem beban. Ing Windows, nganti saiki, panjadwal fokus ing pangolahan prioritas aplikasi desktop, sing bisa nyebabake proses latar mburi beku. Sun Solaris duwe limang kelas panjadwal sing beda. Nalika kita ngluncurake virtualisasi, kita nambah sing nomer enem, Penjadwal sing adil, amarga limang sadurunge ora bisa digunakake kanthi cekap karo virtualisasi Zona Solaris. Aku nyaranake miwiti sinau rinci babagan masalah iki karo buku kaya Solaris Internals: Solaris 10 lan Arsitektur Kernel OpenSolaris utawa Ngerti Linux Kernel.

2.4. Carane ngawasi nyolong?

Ngawasi nyolong ing mesin virtual, kaya metrik prosesor liyane, gampang: sampeyan bisa nggunakake alat metrik prosesor. Sing utama yaiku mesin virtual ing Linux. Kanggo sawetara alasan Windows ora menehi informasi iki kanggo pangguna. 🙁

Output saka printah ndhuwur: rincian beban prosesor, ing kolom paling tengen - nyolong

Kesulitan muncul nalika nyoba njupuk informasi kasebut saka hypervisor. Sampeyan bisa nyoba kanggo prédhiksi nyolong ing mesin inang, contone, nggunakake Rata-rata Load (LA) parameter - Nilai rata-rata nomer pangolahan nunggu ing antrian execution. Cara ngetung parameter iki ora prasaja, nanging umume, yen LA dinormalisasi kanthi jumlah benang prosesor luwih saka 1, iki nuduhake yen server Linux overloaded karo soko.

Apa kabeh proses iki nunggu? Jawaban sing jelas yaiku prosesor. Nanging jawaban ora sakabehe bener, amarga kadhangkala prosesor free , nanging LA dadi mati ukuran. Eling carane NFS tiba mati lan carane LA mundak akeh. Sing padha bisa kedadeyan karo disk lan piranti input / output liyane. Nanging nyatane, proses bisa ngenteni pungkasane kunci apa wae, fisik, sing ana gandhengane karo piranti I / O, utawa logis, kayata mutex. Iki uga kalebu ngunci ing tingkat hardware (respon sing padha saka disk), utawa logika (sing diarani primitif ngunci, sing kalebu sekelompok entitas, mutex adaptif lan spin, semaphore, variabel kondisi, kunci rw, kunci ipc. ...).

Fitur liyane saka LA yaiku dianggep minangka rata-rata sistem operasi. Contone, 100 proses saingan kanggo siji file, banjur LA = 50. Nilai gedhe kasebut bakal nuduhake manawa sistem operasi kasebut ala. Nanging kanggo kode liyane sing ditulis kanthi bengkong, iki bisa uga dadi negara normal, sanajan kasunyatane mung ala, lan proses liyane ing sistem operasi ora nandhang sangsara.

Amarga rata-rata iki (lan ora kurang saka siji menit), nemtokake apa wae kanthi indikator LA ora minangka tugas sing paling bermanfaat, kanthi asil sing ora mesthi ing kasus tartamtu. Yen sampeyan nyoba ngerteni, sampeyan bakal nemokake manawa artikel ing Wikipedia lan sumber daya liyane sing kasedhiya mung nggambarake kasus sing paling gampang, tanpa panjelasan sing jero babagan proses kasebut. Aku ngirim kabeh sing kasengsem, maneh, kene kanggo Brendan Gregg  - tindakake pranala ing ngisor iki. Sapa sing males nganggo basa Inggris - terjemahan artikel populer babagan LA.

3. Efek khusus

Saiki ayo ndelok kasus-kasus utama nyolong sing ditemoni. Aku bakal pitutur marang kowe carane padha tindakake saka kabeh ing ndhuwur lan carane hubungane karo pratondho ing hypervisor ing.

Daur ulang. Sing paling gampang lan paling umum: hypervisor wis digunakake maneh. Pancen, ana akeh mesin virtual sing mlaku, konsumsi prosesor dhuwur ing njero, akeh kompetisi, panggunaan LA luwih saka 1 (normalisasi benang prosesor). Kabèh nang kabeh mesin virtual slows mudhun. Nyolong sing ditularake saka hypervisor uga saya akeh, perlu kanggo nyebarake beban utawa mateni wong liya. Umumé, kabeh iku logis lan bisa dingerteni.

Paravirtualisasi vs. Instance Tunggal. Mung ana siji mesin virtual ing hypervisor; nggunakake bagean cilik, nanging ngasilake beban I / O sing gedhe, contone ing disk. Lan saka ngendi wae katon nyolong cilik, nganti 10% (minangka ditampilake dening sawetara eksperimen).

Kasus kasebut menarik. Nyolong katon ing kene amarga pamblokiran ing tingkat driver paravirtualized. Interupsi digawe ing mesin virtual, diproses dening driver lan dikirim menyang hypervisor. Amarga nangani interupsi ing hypervisor, kanggo mesin virtual katon kaya panjalukan dikirim, siap kanggo eksekusi lan nunggu prosesor, nanging ora diwenehi wektu prosesor. Prawan maya mikir yen wektu iki wis dicolong.

Mengkono ing wayahe buffer dikirim, dadi menyang ruang kernel hypervisor, lan kita miwiti ngenteni. Sanajan, saka sudut pandang mesin virtual, dheweke kudu langsung bali. Mulane, miturut algoritma pitungan nyolong, wektu iki dianggep dicolong. Paling kamungkinan, ing kahanan iki bisa uga ana mekanisme liyane (contone, Processing sawetara sys telpon liyane), nanging padha ora kudu akeh beda.

Penjadwal lawan mesin virtual sing dimuat banget. Nalika siji mesin virtual nandhang sangsara saka nyolong luwih saka liyane, iki amarga panjadwal. Luwih akeh proses mbukak prosesor, luwih cepet panjadwal bakal nyepak supaya wong liya uga bisa kerja. Yen mesin virtual nganggo sethitik, iku meh ora bakal weruh nyolong: proses sajujure lungguh lan nenggo, kita kudu menehi wektu liyane. Yen mesin virtual mrodhuksi mbukak maksimum ing kabeh intine, asring kicked metu saka prosesor lan padha nyoba ora menehi akèh wektu.

Luwih elek nalika pangolahan ing mesin virtual nyoba entuk prosesor luwih akeh amarga ora bisa ngatasi pangolahan data. Banjur sistem operasi ing hypervisor, amarga optimasi jujur, bakal nyedhiyani kurang lan kurang wektu prosesor. Proses iki dumadi kaya longsoran, lan nyolong mlumpat menyang langit, sanajan mesin virtual liyane meh ora sok dong mirsani. Lan luwih inti, luwih elek mesin sing kena pengaruh. Ing cendhak, mesin virtual sing dimuat kanthi akeh intine paling nandhang sangsara.

Low LA, nanging ana nyolong. Yen LA kira-kira 0,7 (yaiku, hypervisor katon kurang), nanging nyolong diamati ing mesin virtual individu:

• Pilihan karo paravirtualization wis diterangake ing ndhuwur. Mesin virtual bisa nampa metrik sing nuduhake nyolong, sanajan hypervisor apik. Miturut asil eksperimen kita, opsi nyolong iki ora ngluwihi 10% lan ora kudu duwe pengaruh sing signifikan marang kinerja aplikasi ing mesin virtual.
• Parameter LA dianggep salah. Luwih tepate, ing saben wayahe tartamtu diwilang kanthi bener, nanging yen rata-rata luwih saka siji menit, pranyata ora dianggep. Contone, yen siji mesin virtual saben katelu saka hypervisor nganggo kabeh prosesor kanggo persis setengah menit, banjur LA saben menit ing hypervisor bakal 0,15; papat mesin virtual kuwi digunakake bebarengan bakal menehi 0,6. Lan kasunyatan manawa kanggo setengah menit saben wong ana nyolong liar ing 25% miturut indikator LA ora bisa ditarik maneh.
• Maneh, amarga panjadwal sing mutusake yen ana wong sing mangan akeh lan ngenteni wong kasebut. Ing sawetoro wektu, aku bakal ngalih konteks, nangani interrupts lan ngurus sistem penting liyane. Akibaté, sawetara mesin virtual ora weruh masalah, dene liyane ngalami degradasi kinerja sing serius.

4. Distorsi liyane

Ana yuta liyane alasan kanggo distorting bali adil wektu prosesor ing mesin virtual. Contone, hyperthreading lan NUMA ngenalake kesulitan ing petungan. Padha rampung mbingungake pilihan kernel kanggo nglakokake proses kasebut, amarga panjadwal nggunakake koefisien - bobot, sing nggawe pitungan luwih angel nalika ngoper konteks.

Ana distorsi amarga teknologi kayata ngedongkrak turbo utawa, kosok balene, mode hemat energi, sing, nalika ngitung pemanfaatan, bisa kanthi artifisial nambah utawa nyuda frekuensi utawa malah irisan wektu ing server. Ngaktifake turbo boost nyuda kinerja siji thread prosesor amarga nambah kinerja liyane. Ing wayahe, informasi babagan frekuensi prosesor saiki ora ditularaké menyang mesin virtual, lan pracaya sing wong wis nyolong wektu (contone, iku njaluk 2 GHz, nanging nampa setengah saka).

Umumé, ana akeh alasan kanggo distorsi. Sampeyan bisa nemokake liyane ing sistem tartamtu. Iku luwih apik kanggo miwiti karo buku sing aku menehi pranala ing ndhuwur, lan njupuk statistik saka hypervisor nggunakake keperluan kayata perf, sysdig, systemtap, kang. puluhan.

5. Kesimpulan

1. Sawetara jumlah nyolong bisa kedadeyan amarga paravirtualisasi, lan bisa dianggep normal. Dheweke nulis ing Internet yen nilai iki bisa dadi 5-10%. Gumantung ing aplikasi ing mesin virtual lan beban sing dilebokake ing piranti fisik. Kene iku penting kanggo mbayar manungsa waé kanggo carane aplikasi aran nang mesin virtual.
2. Rasio beban ing hypervisor lan nyolong ing mesin virtual ora mesthi ana hubungane kanthi jelas; loro perkiraan nyolong bisa dadi salah ing kahanan tartamtu ing macem-macem beban.
3. Penjadwal duwe sikap ala marang proses sing takon akeh. Dheweke nyoba menehi kurang kanggo wong sing njaluk luwih. Mesin virtual gedhe iku ala.
4. Nyolong sethithik bisa dadi norma sanajan tanpa paravirtualisasi (njupuk beban ing mesin virtual, karakteristik beban tanggi, distribusi beban ing benang lan faktor liyane).
5. Yen sampeyan pengin ngerteni nyolong ing sistem tartamtu, sampeyan kudu njelajah macem-macem opsi, ngumpulake metrik, nganalisa kanthi teliti lan mikir babagan cara nyebarake beban kanthi merata. Penyimpangan saka kasus apa wae bisa, sing kudu dikonfirmasi kanthi eksperimen utawa katon ing debugger kernel.

Source: www.habr.com