vSphere CPU Performans Yönetimi – vNUMA

vSphere CPU Performans Yönetimi konusu bir kaç seri halinde yazmayı düşündüğüm ve vSphere ortamınızda advance tuning yapabilmeniz için dikkat edilmesi gereken noktaları anlattığım bir seri olacak.
Performans dediğimizde evde kullandığımız masaüstü – dizüstü PC’lerden tutunda modern datacenterlarda kullanılan son teknoloji sunuculara kadar herkesin aklına aşağı yukarı aynı şey gelmekte. Standart şartlarda daha fazla kaynak=daha fazla performans eşitliği kurulsa da değişen ve gelişen teknoloji ile dağıtık sistemlerde bu mantığın işlemediğini ve ekstra önlemlere ihtiyaç olduğunu belirtmekte fayda var.

vSphere perspektifinden durumu incelediğimizde ise dikkat etmemiz gereken noktaları vNUMA (Virtual NUMA) yapısı ile birlikte işliyor olacağım.

vNUMA Nedir?

Virtual NUMA (vNUMA) fiziksel hostta kullanılan NUMA mimarisini, Guest operating system’a açarak NUMA-aware olarak adlandırılan sistemlerin ve uygulamaların alt taraftaki hardware’i en etkili şekilde kullanabilmesini sağlar. Wide olarak adlandırılan (+8 vCPU) VM’ler için default olarak açılan vNUMA’nın kazandıracağı performans çok büyük oranda Guest Operating System ve uygulama bazında yapılacak optimizasyonlara bağlıdır. İyi bir optimizasyon performans kazanımı olarak dönerken yanlış bir yapılandırma (örneğin çok fazla vCPU atanması) performans kaybı olarak geri dönecektir. Alt Optimizasyonlardan bahsetmeden önce vSphere tarafında nelere dikkat edilmelidir?

CPU Seçerken Nelere Dikkat edilmeli?

Öncelikle seçim yaptığınız CPU kesinlikle 64-Bit ve VT-x, VT-d veya AMD işlemciler için muadili teknolojileri destekliyor olmalı. Burada CPU seçimi yapılırken bakılabilecek bir çok nokta varken şunu belirtmek isterim ki başlı başına CPU clock rate (GHZ cinsinden toplam hız) kesinlikle ilk bakılacak nokta değildir. Modern CPU’larda bakılması gereken en önemli nokta caching yapısıdır. Neden caching yapısı önemli derseniz tarihe bir göz atmak mantıklı olacaktır. 1980’lerden itibaren hızla gelişen CPU yapısı bugünlerde RAM’e göre çok daha hızlı çalışmaktadır. Ancak o günlerde yaşanan en büyük sorunlardan birisi RAM’ın çok yavaş olması ve CPU’nunda yavaşlıkta ondan geri kalmamasıydı. Ancak süreç hızlı değişti ve CPU’larda neredeyse her iki yılda bir iki katı hızlar elde edilmeye başlanırken memory erişimindeki gecikmeler sorun olmaktan çıkmıyordu. Aradaki fark açıldıkca CPU’nun daha fazla hızlanması bir anlam ifade etmedi ve aradaki farkı kapatmak için yeni tip memory ihtiyacı doğdu. İşte tam burada L1 ve L2 cache olarak bildiğimiz caching yapısı ortaya çıktı.

Pekiyi ne yapar bu L1 ve L2 cache?

L1 cache CPU’nun en son eriştiği veriyi ve çok büyük ihtimalle çalıştıracak olduğu program parçacığını depolayan, direkt olarak çip’e inşa edilmiş sıfır bekleme süreli, güç oldukça ayakta duran ve başka bir şeye ihtiyaç duymayan memory havuzudur. Burada L1 Cache’in en büyük özelliği tepkime süresinin gerçek anlamda çok düşük olmasıdır. L2 cache ise L1’e göre daha büyük ve erişim süresi göreceli olarak daha yüksek olan memory havuzudur. CPU aradığı veriyi L1’de bulamazsa L2’de bulacağını varsayarak ikincil uğrak noktası kullanır. L2 CPU paketinin içerisinde olmasına karşın core dışında konumlandığından erişim süresinden kaybeder ancak yer avantajından dolayı daha büyük boyutlarda inşa edilmesi olağandır. L2, main memory ile CPU arasında bir köprü gibidir ve amacı main memory erişimine ihtiyaç duyulmadan hızlı şekilde kod parçacıklarının CPU’ya sunulmasıdır.

Bir de dikkat edilmesi gereken L3 Cache vardır ki, L3 Multicore sahibi işlemciler için ortak kullanım alanıdır ve performans olarak L2 ile main memory arasında durmaktadır. Temel görevi ise sıklıkla erişilen işleri bufferlayarak gerektiğinde main memory erişimine ihtiyaç duyulmadan CPU’ya sunmaktır.

Cache yapısını basitçe incelediğimize göre neden bu kadar önemli olduğu konusunda konuşmak isterim. CPU bir işi yapmadan önce kendisine gereken veri için ilk önce L1’i arar eğer L1 ilgili veriyi içermiyorsa L2 – L3 varsa L4 ve son olarak main memory’e gider. Burada Cache ne kadar büyükse CPU’nun cache’e çarpma oranı o kadar büyük olur ve bu durum gereksiz memory erişimlerinin önüne geçerek milyarlarca işlemin çok ufak gecikmelerle yapılmasını doğal olarak performans olarak geri dönmesini sağlar.

Örnek bir senaryo düşünelim ve senaryodaki sembolik değerler aşağı yukarı şu şekilde olacaktır :

L1 Cache Latency : 1 ns
L2 Cache Latency : 10 ns
L3 Cache Latency : 20-30 ns
Main Memory Latency : 80-120 ns

Şimdi bir program çalışacak ve CPU 100 kere peş peşe L1’den veri isteyecek diyelim. Eğer CPU her istediğinde veriyi L1’de bulabilirse %100 ulaşma oranı ile 100 ns bir toplam erişim süresi olacaktır ( burada quanta olmadığını varsayalım).
CPU tekrar 100 kere peş peşe L1’den veri isteyip 95 kere istediği veriyi L1’de bulursa kalan 5 için L2’ye gidecektir. Kalan 5’ide L2’de bulduğunu varsayalım. (95*1)+(5*10)= 145 ns toplam erişim süresi.
CPU tekrar 100 kere peş peşe L1’den veri isteyip 96 buradan, 2 veri L2’den, 1 veri L3’den ve 1 veri Main memory’den almak durumunda kalırsa : 96 + (2*10) + (1*25avg) + (1*100) = 241 ns toplam erişim süresi.

Burada örnek senaryoda dikkat ettiğimizde toplam erişim süreleri : 100 , 145 ve 241 olarak değişmekte. Karşılaştırdığımızda L1’den L2’ye geçen 5 veri için ekstra performans kaybı %45 kadar. L1’den Main memory’e geçen 1 veri için ekstra performans kaybı %141 kadar. Tabi burada CPU’nun aradığı veriyi direkt bulduğunu Main memory’e gidene kadar bütün Cache levellerini dibine kadar aramadığını varsayıyoruz 🙂

Yukarıda sıraladığım basit nedenden dolayı caching dizaynı performansı etkileyen çok büyük bir etkendir. Burada en temel anlatım şekliyle en yalın haliyle olayı özetlemeye çalıştım. Sonuç olarak L1 ve L2’ye dikkat ediyoruz..

CPU seçiminde bir diğer nokta fiziksel core sayısıdır. Dağıtık sistemler ve Sanallaştırma ortamlarında daha fazla fiziksel core daha etkin iş gücü paylaşımı anlamına gelmektedir ki bu da performansımızı etkileyecek önemli bir noktadır. 6 core 2 socket içeren bir CPU bize Hyperthreading ile 24 Logical core sağlasa dahi günün sonunda gerçek anlamda işi yapacak kişi sayısı önemlidir. Seyircilerin gönlünü hoş tutsun diye sağlanan konu mankenleri değil 🙂 2x hızında bir core, 1x hızında 2 core’dan daha iyi iş yapsada bu az core’lu çok yüksek spesifikasyonlara sahip CPU her zaman ortam için en iyi demek değildir.

Örnek bir CPU hayal edin ve 4 core ve 3GHZ clock rate sahibi olsun.
Örnek bir CPU hayal edin ve 6 core ve 2GHZ clock rate sahibi olsun.

Bu iki CPU’ya 12 milyar farklı iş parçacığı göndermiş olalım.

CPU 1 için 4 core ve her core’a 3 milyar farklı iş parçacığı
CPU 2 için 6 core ve her core’a 2 milyar farklı iş parçacığı

Her bir iş parçacığı için 0.1ns quanta (iş değişimi arasında geçen süre) olduğunu varsayalım.

CPU 1 : 0,3 sn gecikme + 1 sn işlem kapasitesi = 1.3 sn
CPU 2 : 0.2 sn gecikme + 1 sn işlem kapasitesi = 1.2 sn

ve Bu işlemi 100 milyon defa tekrar edelim.
CPU 1 : 100.000.000 * 1.3 = 36111.11111111111 Saat
CPU 2 : 100.000.000 * 1.2 = 33333.33333333 Saat

Burada teorik olarak yapılan hesaplamada yaklaşık 4 yıllık bir süre içerisinde dağıtık işlem yapan veya multithread destekli bir software için iki CPU arasında 2800 saatlik işlem farkı ortaya çıkıyor. VMware’ın hypervisoru ve amiral gemisi ESXi CPU scheduling yaparken mümkün olduğunca tek bir core’da kalmak yerine işi dağıtmaya çalışır. Bu yüzdendir ki Sanallaştırma ortamlarında CPU seçimi yapılırken L1, L2 cache kapasiteleri ile birlikte fiziksel core sayısı da göz önünde tutulmalı ve eşlenebilir toplam değerli CPU’lar için core sayısı yüksek olanlar tercih edilmelidir. Daha fazla core daha fazla VM’in aynı anda işlem yapabilmesi ve birinin bir diğerinin iş yükünü beklememesi anlamına gelmektedir ki bunu da esxtop ile overlap kısmından takip edebilirsiniz.

Son olarak şunu belirtmek isterim ki bu kıyaslamaların tamamı aynı CPU aileleri arasında yapılmalıdır ve CPU yazılımınız için özel seçilmelidir.

VM vCPU Atamasında Nelere Dikkat Edilmelidir?

• Uygulama 3GHZ clock rate’e ihtiyac duyuyorsa istediği kadar atayın fazlasını değil.
• Mümkün olan en cüzi miktardan başlayarak ilerlenmeli ve CPU Ready kontrol edilmelidir. Fazla vCPU fazla performans değildir.
• Performans istenen ortamda Dynamic Power management kullanmayıp c1 ve c0 hariç stateler kapatılmalıdır.
• Fiziksel CPU’yu statik yüksek performans modunda tutmak iş geldiği anda CPU’nun hazır olmasını ve boş core’ların ayağa kalkması için gerekli gecikmeyi ortadan kaldırır.
• 1’den fazla fiziksel CPU var ise mümkün olduğunca bir VM için iş yükünün aynı CPU’da konumlanması sağlanmalıdır.
• Hyperthreading aktif ise ve gerçek performans isteniyorsa kritik uygulamalar için CPU Affinity kullanarak iş yüklerinin her zaman fiziksel core’u ilk olarak hedef seçmesi sağlanmalıdır.
• vCPU limit uygulamak ortamda gereksiz Clock meşgul eden yoksa gereksizdir. Bir VM’e 500mhz limit vermek onun her zaman 500mhz kullanabileceği anlamına gelmez. Örnek olarak 1200 clock bir iş için konuşursak bu VM 500’ü alacak sonra re-schedule olacak tekrar bir 500 alacak ve re-schedule olup tekrar 200 alacak. Arada geçen zamanda başkaları iş yapmasa bile bu senaryo tekrar edecek. Yani 3000 clock kapasitemiz var 2500 boşta yatıyor ancak biz sürekli olarak 500, 500 re-schedule yapıyoruz. Pek önerebileceğim bir senaryo değil. Daha detay için şu makalemi incelemenizi tavsiye ederim : ESXi Kaynak Yönetimi ve Kaynak Grupları
• Prod ortamlar için Hot-Add feature’ı kapalı tutun. CPU hot-plug vNUMA topolojisinin oluşmasını engellediğinden fiziksel core sayısını geçen vCPU sayılarında Guest içerisinde utilize olmayan vCPU’lar görürsünüz bol bol.
• Gerektiğinde CPU reservation kullanmaktan çekinilmemelidir. CPU reservation bir VM’in gerek duyduğu takdirde istediği kaynağa erişmesini sağlar. Ancak CPU overcommit ettiyseniz reservation VM’lerin power-on edilememesi gibi durumlara yol açabileceğinden dikkat edilmelidir.
• co-stop ! Dikkat edilmesi gereken en önemli göstergelerden birisidir. Uzun uzun anlatmak istesem bunun için iki sayfa yazmam gerekir o yüzden basitçe CPU core’ların hep birlikte utilize edilmesi gerektiği ve bu olmadığında scheduling’in durduğu ve geciken core’u beklediğini söyleyebilirim bu da karşımıza yüksek co-stop olarak döner ki en büyük sebebi aşırı vCPU ataması ve fiziksel NUMA ile eşleşmeyen vCPU sayılarıdır. Örnek olarak 6 core bir CPU için ortamdaki VM’lere bölenler ve katlar ( 1,2,3,6,12 … tarzında) halinde atamalar yapılması eş zamanlı çalışan VM lerin daha bir orkestra halinde iş yapmasını garanti edecektir. 6 core bir NUMA’da bol miktarda 4 vCPU VM çalıştırmak yüksek co-stop’lara sebep olacaktır. Yine bu değerleri esxtop ile %CSTP kısmından takip edebilirsiniz.
  CSTP için şu yazımı da incelemenizi tavsiye ederim; https://vmfs6.com/esxtop-cpu-metrics/

Sonuç :

Sonuç olarak standart bir datacenter ortamında hiç bir tuning yapmadan standart bir performans elde etmek mümkün olsa da kritik iş yükleri için CPU seçiminden atamasına vNUMA topolojisine kadar bir çok parametreye dikkat edilmelidir. Her ne kadar yazıya vNUMA için başlamış olsamda gelişme ve sonuç orayı detaylı irdelememe izin vermedi 🙂 gelecek yazılarımdan birinde sadece bu konu üzerine odaklanacağımı bildirerek notlarım arasına alıyorum. Yazıda görmüş olduğunuz hatalı nokta var ise yorumlarınızı beklerim.

Teşekkürler.

Görselimiz :