Merhaba! Size sanal makinelerin içindeki çalma mekanizmalarını ve araştırması sırasında bulmayı başardığımız ve bir bulut platformunun teknik yöneticisi olarak dalmak zorunda kaldığım bazı açık olmayan eserler hakkında basit terimlerle anlatmak istiyorum. . Platform KVM'de çalışır.
CPU çalma süresi, sanal makinenin yürütülmesi için işlemci kaynaklarını almadığı süredir. Bu süre yalnızca sanallaştırma ortamlarındaki konuk işletim sistemlerinde sayılır. Hayatta olduğu gibi en çok tahsis edilen bu kaynakların nereye gittiğine ilişkin nedenler oldukça belirsizdir. Ancak bunu çözmeye karar verdik ve hatta bir dizi deney yaptık. Artık çalmakla ilgili her şeyi bildiğimizden değil ama şimdi size ilginç bir şey anlatacağız.
1. Çalmak nedir
Dolayısıyla çalma, sanal makine içindeki işlemler için işlemci süresinin eksikliğini gösteren bir ölçümdür. Tarif edildiği gibi Gizlilik, hipervizörün, sanal makine işlemini yürütmek için sıraya koymuş olmasına rağmen ana bilgisayar işletim sistemi üzerinde diğer işlemleri yürüttüğü süredir. Yani çalma, işlemin yürütülmeye hazır olduğu süre ile işleme işlemci süresinin tahsis edildiği zaman arasındaki fark olarak hesaplanır.
Sanal makine çekirdeği, çalma ölçüsünü hipervizörden alır. Aynı zamanda, hipervizör tam olarak başka hangi süreçleri çalıştırdığını belirtmiyor, sadece "Ben meşgulken sana zaman veremem" diyor. KVM'de çalma hesaplaması desteği eklendi . Burada iki önemli nokta var:
- Sanal makine, hipervizörden çalmayı öğrenir. Yani kayıplar açısından sanal makinedeki işlemler için bu, çeşitli bozulmalara maruz kalabilecek dolaylı bir ölçümdür.
- Hipervizör, sanal makineyle başka ne yaptığı hakkında bilgi paylaşmaz - asıl mesele, ona zaman ayırmamasıdır. Bu nedenle sanal makinenin kendisi, rakip süreçlerin doğası gereği değerlendirilebilecek çalma göstergesindeki bozulmaları tespit edemez.
2. Çalmayı neler etkiler?
2.1. Çalma hesaplaması
Esasen çalma, normal CPU kullanım süresiyle yaklaşık olarak aynı şekilde hesaplanır. Geri dönüşümün nasıl değerlendirildiği hakkında fazla bilgi yoktur. Muhtemelen çoğu insan bu sorunun açık olduğunu düşündüğü için. Ancak burada da tuzaklar var. Bu sürece alışmak için okuyabilirsiniz : Kullanımı hesaplarken birçok nüans ve bu hesaplamanın aşağıdaki nedenlerden dolayı hatalı olacağı durumlar hakkında bilgi edineceksiniz:
- İşlemci aşırı ısınarak döngülerin atlamasına neden olur.
- İşlemci saat hızını değiştiren turbo güçlendirmeyi etkinleştirin/devre dışı bırakın.
- SpeedStep gibi işlemci gücü tasarrufu sağlayan teknolojiler kullanıldığında zaman diliminin uzunluğunda meydana gelen değişiklik.
- Ortalamanın hesaplanmasındaki sorun: Bir dakikalık kullanımın %80 olarak tahmin edilmesi, %100'lük kısa vadeli bir patlamayı gizleyebilir.
- Döndürme kilidi işlemcinin geri alınmasına neden olur, ancak kullanıcı işlemi yürütülmesinde herhangi bir ilerleme görmez. Sonuç olarak, işlem fiziksel olarak işlemci süresini tüketmese de, işlemin hesaplanan işlemci kullanımı yüzde yüz olacaktır.
Çalmak için benzer bir hesaplamayı anlatan bir yazıya rastlamadım (biliyorsanız yorumlarda paylaşın). Ancak kaynak koduna bakılırsa hesaplama mekanizması geri dönüşümle aynıdır. Basitçe, çekirdeğe, doğrudan KVM işlemi (sanal makine işlemi) için, KVM işleminin CPU zamanını bekleyen süresini sayan başka bir sayaç eklenir. Sayaç, işlemci hakkındaki bilgileri spesifikasyonlarından alır ve tüm işaretlerin sanal makine işlemi tarafından kullanılıp kullanılmadığını kontrol eder. Hepsi bu kadarsa, işlemcinin yalnızca sanal makine işlemiyle meşgul olduğunu varsayıyoruz. Aksi takdirde işlemcinin başka bir şey yaptığını bildiririz, çalma ortaya çıktı.
Çalma sayımı işlemi, normal geri dönüşüm sayımıyla aynı sorunlara tabidir. Bu tür sorunların sıklıkla ortaya çıktığını söylememekle birlikte, cesaret kırıcı görünüyorlar.
2.2. KVM'de sanallaştırma türleri
Genel olarak konuşursak, tümü KVM tarafından desteklenen üç tür sanallaştırma vardır. Çalma olayının mekanizması sanallaştırmanın türüne bağlı olabilir.
çeviri. Bu durumda, sanal makine işletim sisteminin fiziksel hipervizör cihazlarla çalışması şu şekilde gerçekleşir:
- Konuk işletim sistemi, konuk cihazına bir komut gönderir.
- Konuk aygıt sürücüsü komutu alır, aygıt BIOS'u için bir istek oluşturur ve bunu hipervizöre gönderir.
- Hiper yönetici süreci, fiziksel cihaz için komutu komuta dönüştürerek onu diğer şeylerin yanı sıra daha güvenli hale getirir.
- Fiziksel aygıt sürücüsü, değiştirilen komutu kabul eder ve onu fiziksel aygıtın kendisine gönderir.
- Komutları yürütmenin sonuçları aynı yola geri döner.
Çevirinin avantajı, herhangi bir cihazı taklit etmenize izin vermesi ve işletim sistemi çekirdeğinin özel olarak hazırlanmasını gerektirmemesidir. Ancak bunun bedelini her şeyden önce hızla ödemeniz gerekiyor.
Donanım sanallaştırma. Bu durumda donanım düzeyindeki cihaz, işletim sisteminden gelen komutları anlar. Bu en hızlı ve en iyi yoldur. Ancak ne yazık ki tüm fiziksel cihazlar, hipervizörler ve konuk işletim sistemleri tarafından desteklenmiyor. Şu anda donanım sanallaştırmasını destekleyen ana cihazlar işlemcilerdir.
Parasanallaştırma. KVM'de cihaz sanallaştırma için en yaygın seçenek ve genellikle konuk işletim sistemleri için en yaygın sanallaştırma modu. Özelliği, bazı hipervizör alt sistemleriyle (örneğin, ağ veya disk yığınıyla) çalışmanın veya bellek sayfalarının tahsisinin, düşük seviyeli komutları çevirmeden hipervizör API'si kullanılarak gerçekleşmesidir. Bu sanallaştırma yönteminin dezavantajı, konuk işletim sistemi çekirdeğinin, bu API'yi kullanarak hipervizörle iletişim kurabilmesi için değiştirilmesi gerekmesidir. Ancak bu genellikle konuk işletim sistemine özel sürücüler yüklenerek çözülür. KVM'de bu API'ye denir .
Paravirtualizasyon ile yayına kıyasla, komutların doğrudan sanal makineden ana bilgisayardaki hipervizör sürecine gönderilmesiyle fiziksel cihaza giden yol önemli ölçüde azalır. Bu, sanal makine içindeki tüm talimatların yürütülmesini hızlandırmanıza olanak tanır. KVM'de bu, yalnızca ağ veya disk bağdaştırıcısı gibi belirli aygıtlarda çalışan virtio API tarafından yapılır. Virtio sürücülerinin sanal makinelerin içine kurulmasının nedeni budur.
Bu hızlandırmanın dezavantajı, sanal makinenin içinde çalışan tüm işlemlerin sanal makinenin içinde kalmamasıdır. Bu, çalma durumunda ortaya çıkmayla sonuçlanabilecek bazı özel efektler yaratır. Bu konuyla ilgili detaylı bir çalışmaya başlamanızı tavsiye ederim. .
2.3. "Adil" planlama
Bir hipervizör üzerindeki sanal makine, aslında Linux çekirdeğindeki planlama (işlemler arasında kaynak dağıtımı) yasalarına uyan sıradan bir süreçtir, o yüzden gelin ona daha yakından bakalım.
Linux, çekirdek 2.6.23'ten bu yana varsayılan zamanlayıcı haline gelen CFS, Tamamen Adil Zamanlayıcı'yı kullanıyor. Bu algoritmayı anlamak için Linux Çekirdek Mimarisini veya kaynak kodunu okuyabilirsiniz. CFS'nin özü, işlemci süresini, yürütme sürelerine bağlı olarak işlemler arasında dağıtmaktır. Bir işlem ne kadar fazla CPU zamanı gerektirirse, o kadar az CPU zamanı alır. Bu, tüm süreçlerin "adil" bir şekilde yürütülmesini sağlar; böylece bir süreç sürekli olarak tüm işlemcileri meşgul etmez ve diğer süreçler de yürütülebilir.
Bazen bu paradigma ilginç eserlere yol açar. Uzun süredir Linux kullanıcıları muhtemelen derleyici gibi yoğun kaynak kullanan uygulamaları çalıştırırken masaüstündeki normal bir metin düzenleyicinin donduğunu hatırlayacaktır. Bunun nedeni, masaüstü uygulamalarındaki kaynak yoğun olmayan görevlerin, derleyici gibi kaynak yoğun görevlerle rekabet etmesiydi. CFS bunun adil olmadığını düşünüyor, bu nedenle metin düzenleyiciyi periyodik olarak durduruyor ve işlemcinin derleyicinin görevlerini yerine getirmesine izin veriyor. Bu bir mekanizma kullanılarak düzeltildi ancak işlemci süresinin görevler arasında dağıtımına ilişkin diğer birçok özellik kaldı. Aslında bu, CFS'de her şeyin ne kadar kötü olduğuna dair bir hikaye değil, işlemci zamanının "adil" dağıtımının en önemsiz görev olmadığı gerçeğine dikkat çekme girişimidir.
Zamanlayıcıdaki bir diğer önemli nokta da ön alımdır. Bu, işlemcideki gülme sürecini ortadan kaldırmak ve diğerlerinin çalışmasına izin vermek için gereklidir. Çıkarma işlemine bağlam değiştirme denir. Bu durumda, görevin tüm bağlamı korunur: yığının, kayıtların vb. durumu, ardından süreç beklemeye gönderilir ve onun yerini başka biri alır. Bu, işletim sistemi için pahalı bir işlemdir ve nadiren kullanılır, ancak doğası gereği yanlış olan hiçbir şey yoktur. Sık bağlam değiştirme, işletim sisteminde bir sorun olduğunu gösterebilir, ancak genellikle süreklidir ve belirli bir şeye işaret etmez.
Bir gerçeği açıklamak için bu kadar uzun bir hikayeye ihtiyaç var: Dürüst bir Linux zamanlayıcıda bir süreç ne kadar çok işlemci kaynağı tüketmeye çalışırsa, diğer süreçlerin de çalışabilmesi için o kadar hızlı durdurulacaktır. Bunun doğru olup olmadığı, farklı yükler altında farklı şekilde çözülebilecek karmaşık bir sorudur. Windows'ta yakın zamana kadar zamanlayıcı, arka plan işlemlerinin donmasına neden olabilecek masaüstü uygulamalarının öncelikli işlenmesine odaklanıyordu. Sun Solaris'in beş farklı zamanlayıcı sınıfı vardı. Sanallaştırmayı başlattığımızda altıncısını ekledik, çünkü önceki beşi Solaris Zones sanallaştırmasıyla yeterince çalışmadı. Bu konuyla ilgili detaylı bir çalışmaya aşağıdaki gibi kitaplarla başlamanızı tavsiye ederim. veya .
2.4. Hırsızlık nasıl izlenir?
Diğer işlemci ölçümleri gibi sanal makine içindeki hırsızlığı izlemek de basittir: herhangi bir işlemci ölçüm aracını kullanabilirsiniz. Önemli olan sanal makinenin Linux'ta olmasıdır. Bazı nedenlerden dolayı Windows bu bilgiyi kullanıcılarına sağlamamaktadır. 🙁
Üst komutun çıktısı: en sağdaki sütunda işlemci yükünün ayrıntıları - çalmak
Bu bilgiyi hipervizörden almaya çalışırken zorluk ortaya çıkar. Örneğin, yürütme kuyruğunda bekleyen işlem sayısının ortalama değeri olan Yük Ortalaması (LA) parametresini kullanarak ana makinedeki çalmayı tahmin etmeyi deneyebilirsiniz. Bu parametreyi hesaplama yöntemi basit değildir, ancak genel olarak, işlemci iş parçacığı sayısına göre normalize edilen LA 1'den fazlaysa, bu, Linux sunucusunun bir şeyle aşırı yüklendiğini gösterir.
Bütün bu süreçler neyi bekliyor? Açık cevap işlemcidir. Ancak cevap tamamen doğru değil çünkü bazen işlemci ücretsizdir ancak LA ölçeğin dışına çıkar. Hatırlamak . Aynı şey bir diskte ve diğer giriş/çıkış aygıtlarında da olabilir. Ancak aslında işlemler, bir G/Ç cihazıyla ilişkili fiziksel veya muteks gibi mantıksal herhangi bir kilidin sonunu bekleyebilir. Bu aynı zamanda donanım düzeyinde kilitlemeyi (diskten gelen aynı yanıt) veya mantık (bir grup varlık, mutex uyarlamalı ve döndürme, semaforlar, durum değişkenleri, rw kilitleri, ipc kilitleri içeren sözde kilitleme ilkelleri) düzeyinde kilitlemeyi de içerir. ...).
LA'nın bir diğer özelliği de işletim sistemi ortalaması olarak değerlendirilmesidir. Örneğin, bir dosya için 100 süreç rekabet ediyor ve bu durumda LA=50 oluyor. Bu kadar büyük bir değer, işletim sisteminin kötü olduğunu gösteriyor gibi görünüyor. Ancak diğer çarpık yazılmış kodlar için, yalnızca kötü olmasına ve işletim sistemindeki diğer işlemlerin zarar görmemesine rağmen bu normal bir durum olabilir.
Bu ortalama alma nedeniyle (ve en az bir dakika içinde), LA göstergesine göre herhangi bir şeyin belirlenmesi, belirli durumlarda çok belirsiz sonuçlar doğuran, en ödüllendirici görev değildir. Bunu anlamaya çalışırsanız, Vikipedi'deki ve diğer mevcut kaynaklardaki makalelerin, süreçle ilgili derin bir açıklama olmaksızın yalnızca en basit durumları anlattığını göreceksiniz. İlgilenen herkese tekrar gönderiyorum. - aşağıdaki bağlantıları takip edin. Kim İngilizce konuşamayacak kadar tembeldir? .
3. Özel efektler
Şimdi karşılaştığımız ana hırsızlık vakalarına bakalım. Yukarıdakilerin hepsini nasıl takip ettiklerini ve bunların hipervizördeki göstergelerle nasıl ilişkili olduğunu size anlatacağım.
Geri dönüşüm. En basit ve en yaygın olanı: hipervizörün yeniden kullanılması. Aslında, çok sayıda çalışan sanal makine var, içlerinde yüksek işlemci tüketimi var, çok fazla rekabet var, LA kullanımı 1'den fazla (işlemci iş parçacıkları tarafından normalleştirilmiş). Tüm sanal makinelerin içindeki her şey yavaşlar. Hipervizörden aktarılan hırsızlık da artıyor, yükü yeniden dağıtmak veya birini kapatmak gerekiyor. Genel olarak her şey mantıklı ve anlaşılır.
Paravirtualizasyon ve Tek Örnekler. Hipervizörde yalnızca bir sanal makine vardır; bunun küçük bir kısmını tüketir ancak örneğin diskte büyük bir G/Ç yükü üretir. Ve bir yerden% 10'a kadar (birkaç deneyde gösterildiği gibi) küçük bir çalma ortaya çıkıyor.
Durum ilginç. Çalma, tam olarak paravirtualleştirilmiş sürücüler düzeyindeki engelleme nedeniyle burada ortaya çıkıyor. Sanal makinenin içinde bir kesme oluşturulur, sürücü tarafından işlenir ve hipervizöre gönderilir. Hipervizördeki kesinti işleme nedeniyle, sanal makine için gönderilen bir istek gibi görünür, yürütmeye hazırdır ve işlemciyi beklemektedir, ancak kendisine işlemci zamanı verilmemektedir. Sanal kız bu seferin çalındığını düşünüyor.
Bu, arabellek gönderildiği anda gerçekleşir, hipervizörün çekirdek alanına gider ve biz onu beklemeye başlarız. Yine de sanal makine açısından hemen geri dönmesi gerekiyor. Dolayısıyla çalma hesaplama algoritmasına göre bu süre çalınmış sayılıyor. Büyük olasılıkla, bu durumda başka mekanizmalar da olabilir (örneğin, diğer bazı sistem çağrılarını işlemek), ancak bunlar çok farklı olmamalıdır.
Zamanlayıcı ve yüksek yüklü sanal makineler. Bir sanal makine diğerlerinden daha fazla çalınmaya maruz kaldığında bunun nedeni zamanlayıcıdır. Bir süreç işlemciyi ne kadar çok yüklerse, diğerlerinin de çalışabilmesi için zamanlayıcı onu o kadar çabuk devre dışı bırakır. Sanal makine az tüketiyorsa, çalmayı pek görmeyecektir: süreci dürüstçe oturdu ve bekledi, ona daha fazla zaman vermemiz gerekiyor. Bir sanal makine tüm çekirdeklerinde maksimum yükü üretiyorsa, genellikle işlemciden atılır ve ona çok fazla zaman vermemeye çalışırlar.
Sanal makine içindeki süreçlerin veri işlemeyle baş edemedikleri için daha fazla işlemci almaya çalışması daha da kötüdür. Daha sonra hipervizördeki işletim sistemi, dürüst optimizasyon nedeniyle giderek daha az işlemci süresi sağlayacaktır. Bu süreç çığ gibi gerçekleşir ve göklere sıçrar, ancak diğer sanal makineler bunu pek fark etmez. Ve ne kadar çok çekirdek olursa, etkilenen makine o kadar kötü olur. Kısacası, en çok zarar gören, çok çekirdekli ve yüksek yüklü sanal makinelerdir.
LA düşük ama çalma var. LA yaklaşık 0,7 ise (yani hipervizör az yüklenmiş gibi görünüyorsa), ancak bireysel sanal makinelerde çalma gözlemleniyorsa:
- Yukarıda açıklanan paravirtualizasyon seçeneği. Sanal makine, hipervizörün iyi durumda olmasına rağmen çalmayı gösteren ölçümleri alabilir. Deneylerimizin sonuçlarına göre bu çalma seçeneği %10'u geçmemektedir ve sanal makine içindeki uygulamaların performansına önemli bir etkisi olmamalıdır.
- LA parametresi yanlış hesaplanmış. Daha doğrusu, her belirli anda doğru hesaplanır, ancak bir dakikanın üzerinde ortalama alındığında hafife alındığı ortaya çıkar. Örneğin, hipervizörün üçte birindeki bir sanal makine, tüm işlemcilerini tam olarak yarım dakika boyunca tüketiyorsa, hipervizörde dakika başına LA 0,15 olacaktır; Aynı anda çalışan bu tür dört sanal makine 0,6 verecektir. Ve her birinde yarım dakika boyunca LA göstergesine göre% 25'lik vahşi bir çalmanın olduğu gerçeği artık çıkarılamaz.
- Yine birisinin çok fazla yemek yediğine karar veren ve o kişinin beklemesine izin veren programlayıcı yüzünden. Bu arada bağlamı değiştireceğim, kesintileri halledeceğim ve diğer önemli sistem işleriyle ilgileneceğim. Bunun sonucunda bazı sanal makinelerde herhangi bir sorun görülmezken bazılarında ciddi performans düşüşü yaşanıyor.
4. Diğer çarpıklıklar
Sanal bir makinede işlemci süresinin adil geri dönüşünü bozmanın milyonlarca nedeni daha var. Örneğin, hiper iş parçacığı ve NUMA hesaplamalara zorluklar katıyor. Süreci yürütmek için çekirdek seçimini tamamen karıştırıyorlar çünkü zamanlayıcı, bağlamı değiştirirken hesaplamayı daha da zorlaştıran katsayılar - ağırlıklar kullanıyor.
Kullanım hesaplanırken, sunucudaki frekansı ve hatta zaman dilimini yapay olarak artırabilen veya azaltabilen turbo boost veya tam tersi enerji tasarrufu modu gibi teknolojilerden kaynaklanan bozulmalar vardır. Turbo güçlendirmenin etkinleştirilmesi, diğerinin performansındaki artış nedeniyle bir işlemci iş parçacığının performansını azaltır. Şu anda, mevcut işlemci frekansıyla ilgili bilgiler sanal makineye aktarılmıyor ve birisinin zamanını çaldığına inanıyor (örneğin, 2 GHz istedi ancak yarısını aldı).
Genel olarak bozulmanın birçok nedeni olabilir. Belirli bir sistemde başka bir şey bulabilirsiniz. Yukarıda linkini verdiğim kitaplarla başlamak ve perf, sysdig, systemtap gibi programları kullanarak hipervizörden istatistik almak daha doğru olacaktır. .
5. bulgular
- Paravirtualizasyon nedeniyle bir miktar çalma meydana gelebilir ve bu normal kabul edilebilir. İnternette bu değerin %5-10 olabileceğini yazıyorlar. Sanal makinenin içindeki uygulamalara ve fiziksel cihazlara yüklediği yüke bağlıdır. Burada uygulamaların sanal makinelerde nasıl hissettiğine dikkat etmek önemlidir.
- Hipervizördeki yük ile sanal makine içindeki çalma oranı her zaman açık bir şekilde birbiriyle ilişkili değildir; her iki çalma tahmini de farklı yükler altındaki belirli durumlarda hatalı olabilir.
- Zamanlayıcının çok şey isteyen süreçlere karşı kötü bir tutumu var. Daha fazlasını isteyene daha azını vermeye çalışır. Büyük sanal makineler şeytandır.
- Paravirtualizasyon olmadan bile küçük bir çalma norm olabilir (sanal makine içindeki yük, komşuların yükünün özellikleri, iş parçacıkları arasındaki yük dağılımı ve diğer faktörler dikkate alınarak).
- Belirli bir sistemde çalmayı çözmek istiyorsanız çeşitli seçenekleri araştırmanız, ölçümler toplamanız, bunları dikkatlice analiz etmeniz ve yükü nasıl eşit şekilde dağıtacağınızı düşünmeniz gerekir. Deneysel olarak onaylanması veya çekirdek hata ayıklayıcısında incelenmesi gereken herhangi bir durumdan sapmalar mümkündür.
Kaynak: habr.com