Bu yazımızda vSphere de bulunan random access memory (RAM) performans sayaçlarından bahsedeceğiz.
Görünüşe göre bellekle ilgili her şey işlemciden daha net: Bir VM'nin performans sorunları varsa, bunları fark etmemek zor. Ancak ortaya çıkarlarsa, onlarla başa çıkmak çok daha zordur. Ama önce ilk şeyler.
Biraz teori
Sanal makinelerin RAM'i, VM'lerin üzerinde çalıştığı sunucunun belleğinden alınır. Çok bariz :). Sunucunun RAM'i herkes için yeterli değilse, ESXi, RAM tüketimini optimize etmek için bellek yenileme tekniklerini kullanmaya başlar. Aksi takdirde, VM işletim sistemleri RAM erişim hatalarıyla çöker.
ESXi'nin hangi teknikleri kullanacağına RAM yüküne bağlı olarak karar verir:
Hafıza durumu
sınır
Etkinlik
Yüksek
minFree'nin %400'ü
Üst sınıra ulaştıktan sonra, büyük bellek sayfaları küçük sayfalara bölünür (TPS standart modda çalışır).
Temizle
minFree'nin %100'ü
Büyük bellek sayfaları küçük sayfalara bölünür, TPS çalışmaya zorlanır.
Yumuşak
minFree'nin %64'ü
TPS + Balon
Zor
minFree'nin %32'ü
TPS + Sıkıştır + Değiştir
Düşük
minFree'nin %16'ü
Sıkıştır + Değiştir + Engelle
minFree, hipervizörün çalışması için gereken RAM'dir.
ESXi 4.1 dahil edilmeden önce, minFree varsayılan olarak sabitlendi - sunucunun RAM'inin %6'sı (yüzde, ESXi'deki Mem.MinFreePct seçeneği aracılığıyla değiştirilebilir). Daha sonraki sürümlerde, sunuculardaki bellek boyutlarının artması nedeniyle minFree, sabit bir yüzde olarak değil, ana bilgisayar belleği miktarına göre hesaplanmaya başlandı.
minFree (varsayılan) değeri şu şekilde hesaplanır:
minFree için ayrılan bellek yüzdesi
Bellek aralığı
6%
0-4 GB
4%
4-12 GB
2%
12-28 GB
1%
kalan hafıza
Örneğin, 128 GB RAM'e sahip bir sunucu için MinFree değeri şöyle olacaktır:
MinFree = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
Gerçek değer, sunucuya ve RAM'e bağlı olarak birkaç yüz MB farklılık gösterebilir.
minFree için ayrılan bellek yüzdesi
Bellek aralığı
128 GB için değer
6%
0-4 GB
245,76 MB
4%
4-12 GB
327,68 MB
2%
12-28 GB
327,68 MB
1%
Kalan bellek (100 GB)
1024 MB
Genellikle verimli meşcereler için sadece Yüksek durum normal kabul edilebilir. Test ve geliştirme tezgahları için Şeffaf/Yumuşak durumları kabul edilebilir. Ana bilgisayardaki RAM %64 MinFree'den azsa, üzerinde çalışan VM'lerde kesinlikle performans sorunu vardır.
Her durumda, VM'nin performansını pratikte etkilemeyen TPS ile başlayan ve Swapping ile biten belirli bellek geri kazanma teknikleri uygulanır. Size onlar hakkında daha fazla bilgi vereceğim.
Şeffaf Sayfa Paylaşımı (TPS). TPS, kabaca, bir sunucudaki sanal makine bellek sayfalarının tekilleştirilmesidir.
ESXi, sayfaların karma toplamını sayarak ve karşılaştırarak sanal makine RAM'inin aynı sayfalarını arar ve yinelenen sayfaları sunucunun fiziksel belleğindeki aynı sayfanın bağlantılarıyla değiştirerek kaldırır. Sonuç olarak, fiziksel bellek tüketimi azalır ve çok az veya hiç performans düşüşü olmadan bir miktar bellek fazla aboneliği elde edilebilir.
Bu mekanizma yalnızca 4 KB bellek sayfaları (küçük sayfalar) için çalışır. Hipervizör 2 MB'lık sayfaları (büyük sayfalar) tekilleştirmeye bile çalışmaz: bu boyutta aynı sayfaları bulma şansı pek iyi değildir.
Varsayılan olarak ESXi, belleği büyük sayfalara ayırır. Büyük sayfaları küçük sayfalara bölme, Yüksek durum eşiğine ulaşıldığında başlar ve Temiz duruma ulaşıldığında zorlanır (bkz. hipervizör durum tablosu).
Ana bilgisayar RAM'inin dolmasını beklemeden TPS'nin çalışmaya başlamasını istiyorsanız, Gelişmiş Seçenekler ESXi'de değeri ayarlamanız gerekir. "Mem.AllocGuestLargePage" 0'a (varsayılan 1). Ardından, sanal makineler için büyük bellek sayfalarının tahsisi devre dışı bırakılacaktır.
Aralık 2014'ten bu yana, ESXi'nin tüm sürümlerinde, teorik olarak bir VM'den başka bir VM'nin RAM'ine erişime izin veren bir güvenlik açığı bulunduğundan, VM'ler arasındaki TPS varsayılan olarak devre dışı bırakılmıştır. Ayrıntılar burada. TPS güvenlik açığından yararlanmanın pratik uygulaması hakkında bilgiye rastlamadım.
Gelişmiş seçenekle kontrol edilen TPS politikası "Mem.ShareForceSalting" ESXi'de:
0 - Sanal Makineler Arası TPS. TPS, farklı sanal makinelerin sayfaları için çalışır;
1 – VMX'te aynı “sched.mem.pshare.salt” değerine sahip VM için TPS;
2 (varsayılan) - VM İçi TPS. TPS, VM içindeki sayfalar için çalışır.
Test tezgahlarında büyük sayfaları kapatmak ve Inter-VM TPS'yi açmak kesinlikle mantıklıdır. Çok sayıda aynı tip VM'ye sahip stantlar için de kullanılabilir. Örneğin, VDI'lı stantlarda, fiziksel bellekteki tasarruf yüzde onlara ulaşabilir.
hafıza balonu. Balonlama artık VM işletim sistemi için TPS kadar zararsız ve şeffaf bir teknik değil. Ancak doğru uygulama ile Balonculuk ile yaşayabilir ve hatta çalışabilirsiniz.
Vmware Tools ile birlikte, VM üzerine Balon Sürücüsü (aka vmmemctl) adı verilen özel bir sürücü kurulur. Hipervizörün fiziksel belleği tükenmeye başladığında ve Esnek duruma girdiğinde, ESXi VM'den bu Balon Sürücüsü aracılığıyla kullanılmayan RAM'i geri almasını ister. Sürücü ise işletim sistemi düzeyinde çalışır ve ondan boş bellek ister. Hipervizör, Balon Sürücüsünün fiziksel belleğin hangi sayfalarını işgal ettiğini görür, belleği sanal makineden alır ve ana bilgisayara geri döndürür. İşletim sistemi düzeyinde bellek Balon Sürücüsü tarafından kullanıldığı için işletim sisteminin çalışmasında herhangi bir sorun yoktur. Varsayılan olarak Balon Sürücüsü, VM belleğinin %65'ine kadarını alabilir.
VMware Tools sanal makinede kurulu değilse veya Balonlama devre dışıysa (önermiyorum ama var :), hipervizör hemen daha katı bellek kaldırma tekniklerine geçer. Sonuç: VMware Tools'un VM üzerinde olduğundan emin olun.
Balon Sürücüsünün çalışması, VMware Tools aracılığıyla işletim sisteminden kontrol edilebilir.
bellek sıkıştırma Bu teknik, ESXi Zor durumuna ulaştığında kullanılır. Adından da anlaşılacağı gibi ESXi, 4 KB'lık bir RAM sayfasını 2 KB'ye küçültmeye çalışır ve böylece sunucunun fiziksel belleğinde biraz yer açar. Bu teknik, sayfanın öncelikle sıkıştırılmamış olması gerektiğinden, VM RAM sayfalarının içeriğine erişim süresini önemli ölçüde artırır. Bazen tüm sayfalar sıkıştırılamaz ve işlemin kendisi biraz zaman alır. Bu nedenle, bu teknik pratikte çok etkili değildir.
hafıza takası Kısa bir Bellek Sıkıştırma aşamasından sonra, ESXi neredeyse kaçınılmaz olarak (VM'ler diğer ana makineler için ayrılmamış veya kapatılmamışsa) Değiştirmeye geçecektir. Ve çok az bellek kaldıysa (Düşük durum), hipervizör ayrıca bellek sayfalarını VM'ye ayırmayı durdurur ve bu da VM'nin konuk işletim sisteminde sorunlara neden olabilir.
Değiştirme şu şekilde çalışır. Bir sanal makineyi açtığınızda onun için .vswp uzantılı bir dosya oluşturulur. Boyut olarak VM'nin ayrılmamış RAM'ine eşittir: yapılandırılmış ve ayrılmış bellek arasındaki farktır. Değiştirme çalışırken, ESXi sanal makine bellek sayfalarını bu dosyaya boşaltır ve sunucunun fiziksel belleği yerine onunla çalışmaya başlar. Elbette, bu tür "işlemsel" bellek, .vswp hızlı depolamada olsa bile, gerçek bellekten birkaç kat daha yavaştır.
Balondan farklı olarak kullanılmayan sayfalar VM'den alındığında Swapping ile OS veya VM içindeki uygulamalar tarafından aktif olarak kullanılan sayfalar diske taşınabilir. Sonuç olarak, VM'nin performansı donma noktasına kadar düşer. VM resmi olarak çalışır ve en azından işletim sisteminden uygun şekilde devre dışı bırakılabilir. Sabredersen 😉
VM'ler Takas'a gittiyse bu, mümkünse kaçınılması gereken anormal bir durumdur.
Anahtar VM bellek performans sayaçları
Böylece ana noktaya geldik. VM'deki belleğin durumunu izlemek için aşağıdaki sayaçlar vardır:
Aktif — VM'nin önceki ölçüm döneminde eriştiği RAM (KB) miktarını gösterir.
kullanım - Aktif ile aynı, ancak VM'nin yapılandırılmış RAM'inin yüzdesi olarak. Aşağıdaki formül kullanılarak hesaplanır: etkin ÷ sanal makine yapılandırılmış bellek boyutu.
Sırasıyla Yüksek Kullanım ve Etkin, her zaman VM performans sorunlarının bir göstergesi değildir. VM agresif bir şekilde bellek kullanıyorsa (en azından ona erişim elde ederse), bu, yeterli bellek olmadığı anlamına gelmez. Aksine, işletim sisteminde neler olduğunu görmek için bir fırsattır.
VM'ler için standart bir Bellek Kullanım Alarmı vardır:
paylaşılan - TPS kullanılarak tekilleştirilen VM RAM miktarı (VM içinde veya VM'ler arasında).
Verilen - VM'ye verilen fiziksel ana bilgisayar belleği (KB) miktarı. Paylaşılan içerir.
tüketilen (Verildi - Paylaşılan) - VM'nin ana bilgisayardan kullandığı fiziksel bellek (KB) miktarı. Paylaşılan içermez.
VM belleğinin bir kısmı ana bilgisayarın fiziksel belleğinden değil de takas dosyasından veriliyorsa veya Balon Sürücü aracılığıyla VM'den bellek alınmışsa, bu miktar Verildi ve Tüketildi'de dikkate alınmaz.
Yüksek Verilen ve Tüketilen değerler tamamen normaldir. İşletim sistemi, hiper yöneticiden belleği kademeli olarak alır ve geri vermez. Zamanla, aktif olarak çalışan bir VM'de bu sayaçların değerleri, yapılandırılan bellek miktarına yaklaşır ve orada kalır.
Sıfır — sıfır içeren VM RAM (KB) miktarı. Bu tür bir bellek, hipervizör tarafından boş kabul edilir ve diğer sanal makinelere verilebilir. Konuk işletim sistemi sıfırlanmış belleğe bir şey yazdıktan sonra, Tüketildi durumuna geçer ve geri dönmez.
Ayrılmış Genel Gider — hipervizör tarafından VM işlemi için ayrılan VM RAM miktarı (KB). Bu küçük bir miktardır, ancak ana bilgisayarda mevcut olmalıdır, aksi takdirde VM başlamayacaktır.
Balon — Balon Sürücüsü kullanılarak VM'den ele geçirilen RAM (KB) miktarı.
Sıkıştırılmış - sıkıştırılmış RAM (KB) miktarı.
takas - sunucudaki fiziksel bellek eksikliği nedeniyle diske taşınan RAM (KB) miktarı.
Balon ve diğer hafıza yenileme teknikleri sayaçları sıfırdır.
150 GB RAM'e sahip normal çalışan bir VM için Bellek sayaçları içeren grafik bu şekilde görünür.
Aşağıdaki grafikte, sanal makinenin bariz sorunları vardır. Grafiğin altında, bu VM için RAM ile çalışmak için açıklanan tüm tekniklerin kullanıldığını görebilirsiniz. Bu sanal makinenin balonu Tüketilenden çok daha büyük. Aslında, VM canlı olmaktan çok ölüdür.
ESXTOP
CPU'da olduğu gibi, ana bilgisayardaki durumu ve dinamiklerini 2 saniyeye kadar aralıklarla hızlı bir şekilde değerlendirmek istiyorsak, ESXTOP kullanmalıyız.
Hafıza tarafından ESXTOP ekranı "m" tuşu ile çağrılır ve şöyle görünür (B, D, H, J, K, L, O alanları seçilir):
Aşağıdaki parametreler ilgimizi çekecektir:
Mem fazla işleme ortalaması - ana bilgisayarda 1, 5 ve 15 dakika boyunca bellek aşırı aboneliğinin ortalama değeri. Sıfırın üzerindeyse, bu, neler olduğunu görmek için bir fırsattır, ancak her zaman sorunların bir göstergesi değildir.
Hatta PMEM/MB и VMKMEM/MB - sunucunun fiziksel belleği ve VMkernel'in kullanabileceği bellek hakkında bilgi. Buradaki ilginç olandan, ana bilgisayarın bellekteki durumunu (bizim durumumuzda yüksek) minfree'nin (MB cinsinden) değerini görebilirsiniz.
Çizgide NUMA/MB NUMA düğümlerine (yuvalarına) göre RAM dağıtımını görebilirsiniz. Bu örnekte, dağılım düzensizdir ve bu prensipte pek iyi değildir.
Bellek yenileme teknikleriyle ilgili genel sunucu istatistikleri aşağıdadır:
PSHARE/MB TPS istatistikleri;
TAKAS/MB — Kullanım istatistiklerini değiştirin;
ZIP/MB — bellek sayfası sıkıştırma istatistikleri;
MEMCTL/MB — Balon Sürücüsü kullanım istatistikleri.
Bireysel sanal makineler için aşağıdaki bilgiler ilgimizi çekebilir. Seyircinin kafasını karıştırmamak için sanal makine adlarını sakladım :). ESXTOP metriği vSphere'deki sayaca benzer ise karşılık gelen sayacı veriyorum.
MEMSZ — VM'de yapılandırılan bellek miktarı (MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + dokunulmamış.
HİBE - MB'ye verildi.
TCHD — MB cinsinden aktif.
MCTL mi? - VM'de Balon Sürücüsünün yüklü olup olmadığı.
MCTLSZ — MB'ye balon.
MCTLGT — ESXi'nin Balon Sürücüsü (Memctl Target) aracılığıyla VM'den almak istediği RAM (MB) miktarı.
MCTLMAX - ESXi'nin Balon Sürücü aracılığıyla VM'den alabileceği maksimum RAM (MB) miktarı.
SWCUR — Takas dosyasından VM'ye ayrılan mevcut RAM (MB) miktarı.
S.W.G.T. - ESXi'nin Swap dosyasından (Swap Target) VM'ye vermek istediği RAM (MB) miktarı.
Ayrıca, ESXTOP aracılığıyla, VM'nin NUMA topolojisi hakkında daha ayrıntılı bilgi görebilirsiniz. Bunu yapmak için D, G alanlarını seçin:
KÜÇÜK – VM'nin bulunduğu NUMA düğümleri. Burada, bir NUMA düğümüne sığmayan geniş vm'yi hemen fark edebilirsiniz.
NRMEM - VM'nin uzak NUMA düğümünden kaç megabayt bellek aldığı.
NLMEM - VM'nin yerel NUMA düğümünden kaç megabayt bellek aldığı.
N%L – yerel NUMA düğümündeki sanal makine belleğinin yüzdesi (%80'den azsa performans sorunları oluşabilir).
Hipervizördeki bellek
Hiper yönetici için CPU sayaçları genellikle özel bir ilgi konusu değilse, durum bellekle tersine çevrilir. Bir VM'de Yüksek Bellek Kullanımı, her zaman bir performans sorunu olduğunu göstermez, ancak bir hipervizörde yüksek Bellek Kullanımı, bellek yönetimi tekniklerini tetikler ve VM'de performans sorunlarına neden olur. Sanal Makinenin Takas'a girmesini önlemek için Ana Bilgisayar Bellek Kullanımı alarmları izlenmelidir.
takası iptal et
Bir VM Takas durumundaysa, performansı büyük ölçüde düşer. Ana bilgisayarda boş RAM göründükten sonra Balonlaşma ve sıkıştırma izleri hızla kaybolur, ancak sanal makine Takas'tan sunucu RAM'ine geri dönmek için acele etmez.
ESXi 6.0'dan önce, bir VM'yi Swap'tan çıkarmanın tek güvenilir ve hızlı yolu yeniden başlatmaktı (daha kesin olmak gerekirse, kapsayıcıyı kapatıp açın). ESXi 6.0 ile başlayarak, tam olarak resmi olmasa da, bir VM'yi Swap'tan kaldırmanın çalışan ve güvenilir bir yolu ortaya çıktı. Konferanslardan birinde CPU Scheduler'dan sorumlu VMware mühendislerinden biriyle konuşma fırsatım oldu. Yöntemin oldukça işe yaradığını ve güvenli olduğunu onayladı. Deneyimlerimize göre, onunla da hiçbir sorun yoktu.
VM'yi Swap'tan kaldırmak için gerçek komutlar Duncan Epping. Ayrıntılı bir açıklamayı tekrar etmeyeceğim, sadece kullanımına bir örnek verin. Ekran görüntüsünde de görebileceğiniz gibi, belirtilen komutların yürütülmesinden bir süre sonra VM'de Swap kayboluyor.
ESXi Bellek Yönetimi İpuçları
Son olarak, RAM nedeniyle sanal makine performansıyla ilgili sorunlardan kaçınmanıza yardımcı olacak bazı ipuçlarını burada bulabilirsiniz:
- Üretken kümelerde aşırı bellek aboneliğinden kaçının. Kümede her zaman ~%20-30 boş belleğe sahip olunması arzu edilir, böylece DRS'nin (ve yöneticinin) hareket alanı olur ve geçiş sırasında VM'ler Takas durumuna girmez. Ayrıca, hata toleransı marjını da unutmayın. Bir sunucu arızalandığında ve VM HA kullanılarak yeniden başlatıldığında, bazı makinelerin de Swap'a girmesi hoş olmayan bir durumdur.
- Yüksek düzeyde birleştirilmiş altyapılarda, ana bilgisayar belleğinin yarısından fazlasıyla VM'ler OLUŞTURMAMAYA ÇALIŞIN. Bu yine DRS'nin sanal makineleri küme sunucuları arasında sorunsuz bir şekilde dağıtmasına yardımcı olacaktır. Bu kural elbette evrensel değildir :).
- Ana Bilgisayar Bellek Kullanımı Alarmını İzleyin.
- VM üzerinde VMware Tools kurmayı unutmayın ve Balonlamayı kapatmayınız.
- VDI ve test ortamlarında Inter-VM TPS'yi etkinleştirmeyi ve Büyük Sayfaları devre dışı bırakmayı düşünün.
- Sanal makine performans sorunları yaşıyorsa, uzak bir NUMA düğümünden bellek kullanıp kullanmadığını kontrol edin.
- Sanal makinenizi mümkün olan en kısa sürede Swap'tan çıkarın! Diğer şeylerin yanı sıra, sanal makine takas durumundaysa, bariz nedenlerden dolayı depolama sistemi zarar görür.
RAM hakkında benim için hepsi bu. Detaylara inmek isteyenler için ilgili yazı aşağıdadır. Bir sonraki makale storadzh'a ayrılacak.
Faydalı linkler
Kaynak: habr.com