Başlangıç > VMware > 112: TPS yanılgısı

112: TPS yanılgısı

Çok yakın zamanda da duyduğum bir argüman, güncel işlemcilerin de iyice devreye girmesiyle birlikte, TPS ‘in artık efektif olmadığı, dolayısı ile diğer üreticilerin bellek yönetimi anlamında aradaki farkı kapattığı yönünde. Hyper-V’nin “Dynamic Memory” ile ciddi bir ilerleme kaydettiğini ve kendine has avantajları olduğunu kabul ediyorum, ancak konuyu biraz daha irdelemeden karar vermemek lazım.

Öncelikle TPS nedir? TPS (Transparent Page Sharing) en basit anlamda ESX’in memory tekilleştirmesi yapmasıdır. 60 dakikada bir çalışan bir proses aynı içeriğe sahip memory page’lerini bulur, bu page’leri tekilleştirir ve kendisine daha fazla fiziksel kaynak yaratır.  Bu operasyonu yaparken de 4KB’lık memory page’leri (small pages) kullanır. Hal böyle olunca da TPS ciddi oranlarda memory overcommitment sağlar, daha doğrusu eskiden öyleydi.

Peki yeni nesil işlemcilerle birlikte ne değişti? Nehalem işlemciler ile birlikte Hardware-Assisted  Memory Management Unit kullanılmaya başlandı. HwMMU, virtual adresleri fiziksel adreslere çevirmekte kullanılan TLB (Translation Lookaside Buffer) isimli bir CPU cache alanı barındırır. Eğer ilgili virtual adres TLB içerisinde bulunursa yaklaşık 1 CPU cycle süresinde fiziksel adres elde edilir, eğer bulunamazsa fiziksel adres “page table” ‘dan bulunmak zorunda ve bu da 100 CPU cycle’ına kadar bir sürede gerçekleşebilir.

Peki sorun nerede? TLB’nin performans artısı olduğu muhakkak ancak bu cache alanı gayet sınırlı bir alan.  Dolayısı ile, ESX açılırken eğer sahip olduğu CPU’nun HwMMU özelliği olduğunu farkederse, 4KB yerine 2MB’lık memory page’leri (large pages) kullanmaya başlıyor. Bu da 512 kat daha az sayıda bellek page’i kullanması ve dolayısı ile TLB’den daha fazla fayda sağlayabilmesi anlamına geliyor (TLB kullanımının %10-20 civarında performans artışı getirdiği söyleniyor).

Page boyutunun büyümesi ise hem tekilleştirme oranını olumsuz etkiliyor, hem de 2MB’lık page’leri hash’leyip karşılaştırmak için harcanan CPU kaynağı artıyor. Sonuç, eğer ESX üzerinde bir bellek sıkışması bulunmuyorsa, ESX TPS kullanmıyor. Ancak iyi haber, bu hiç kullanmadığı anlamına gelmiyor. Eğer ESX üzerinde bellek sıkışması baş gösterir, bellek durumu high state’den soft state’e geçer (ki bu %6 boş bellek kaldığında gerçekleşir), işte bu noktada 2MB’lık page’ler 4KB’a bölünür ve TPS devreye girip sunucuya ciddi oranda bellek kaynağı yaratır.  Yani her durumda kendisi için en avantajlısı ne ise, onu seçer. (KB)

Bu noktada değinilmesi gereken bir yanılgı daha ortaya çıkıyor. ESX sunucularınızda %80-90 civarlarında bir kullanım oranı, gerçek anlamda havuzun büyütülmesi anlamına gelmeyebilir. Bu noktada, henüz TPS’den gerçek kazanç elde edilmemiştir ve bunun da değerlendirilmesi gerekmektedir.

Yukarıda linkini verdiğim makalede ilgi çekici bir satır da bulunmakta:

However, ESX still generates hashes for the 4KB pages within each large page during page scanning

Bu, 2MB pagelerin kullanıldığı durumda bile, 4KB’lık hash’lerin ihtiyaç durumunda kullanılmak üzere oluşturulduğu anlamına geliyor. Çünkü bellek sıkıntısının oluşmaya başladığı durumda, ESX’in hızlı aksiyon alıp bir an önce TPS’i devreye sokması mantıklı olacaktır, aksi taktirde ballooning, compression ve swapping başlayacak ve TPS’in tam anlamıyla kazanç sağlaması için geç kalınmış olacak.

İşin bir güzel tarafı da, eğer 4KB’lık page’ler kullanılmış olsaydı, ne kadar kazanç sağlayabileceğimizi kolaylıkla görebiliyor olmamız. Böylelikle yukarıda da bahsettiğim değerlendirmeyi daha kolay yapabiliriz. Bu değerleri görebilmek için esxtop’a ihtiyacımız var.

Yukarıdaki görüntüde, COWH kolonu bize istediğimiz bilgiyi sağlamaktadır. COWH (Copy on Write Page Hints) potansiyel olarak paylaşılabilir alanı vermektedir. Ayrıca sarı ile belirtilmiş alanda, tüm ESX üzerinde,  30MB’lık bir alanın paylaşılabilir olduğunu ve bunun sonucunda sadece 14 MB’lık bir kazanç sağlandığı görülüyor (buradaki değer zero page’lerin paylaşılmasından elde edilen kazanç), TPS’in small page kullandığı dönemlerden aşina olduğumuz yaklaşık %30’luk değerlerden bir hayli uzak. Sonuçta, eğer TPS etkin kullanılsaydı, potansiyel olarak COWH kolonunun toplamı kadar kazanç elde edebilirdik.

Bu arada, eğer istersek TPS’i small page kullanacak şekilde konfigüre edebiliriz. Böylelikle VMkernel, CPU’nun HwMMU desteğine bakmaksızın 4KB’lık page’ler kullanıp TPS’i devreye alacaktır. Bunun için ESX üzerinde ilgili advanced parametreyi değiştirmek yeterli olacaktır.

  • Mem.AllocGuestLargePage=0

TPS ile ilgili aklıma gelen son şeyi de belirtmek gerekirse, TPS’in kullanılmadığını söylediğimiz durumda bile, VMkernel zero page’leri (tüm bitleri sıfırdan oluşan bellek blokları) anında tekilleştirerek kendine kaynak sağlar, bu durumda elde edilecek kazanç kullanılan guest OS’lere göre farklılık göstermektedir.

Eğer herhangi bir sebepten dolayı TPS’in hiç kullanılmamasından yana iseniz aşağıdaki advanced parametre ile tamamen de kapatabilirsiniz.

  • Mem.ShareScanGHz=0

Özel bir sebep bulunmadığı sürece bu parametrelerin değiştirilmemesi taraftarıyım. Sonuç…. Benim oyum halen TPS’den yana…

Kategoriler:VMware Etiketler:, ,
  1. Henüz yorum yapılmamış.
  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

w

Connecting to %s

%d blogcu bunu beğendi: