Kısa cevap

CPU overcommitment, bir host üzerindeki sanal makinelere toplamda fiziksel mantıksal işlemci sayısından daha fazla vCPU tanımlamaktır. Bunun işe yaramasının nedeni basittir: sanal makinelerin çoğu, tanımlı işlemcilerini aynı anda ve sürekli kullanmaz.

Neden mümkün?#

Tipik bir sunucu iş yükü sürekli %100 işlemci kullanmaz. Bir dosya sunucusu, bir yönetim aracı veya bir uygulama sunucusu çoğu zaman boştadır; işlemciyi yalnızca kısa aralıklarla ister.

Hypervisor bu boşlukları değerlendirir. Bir vCPU çalışmadığında fiziksel işlemci başka bir vCPU'ya verilir. Sonuç olarak, 32 mantıksal işlemcili bir host'ta toplam 100 vCPU tanımlı olabilir ve sistem rahat çalışabilir.

Peki sınır nerede?#

Buradaki asıl soru "kaça kadar çıkabilirim?" değil, "hangi noktada bekleme başlıyor?" olmalıdır. Çünkü sınır bir orana değil, iş yükünün davranışına bağlıdır.

Neyi ölçmeli?#

Overcommitment'ın sağlıklı olup olmadığı üç göstergeyle izlenir:

İzlenecek göstergeler

  1. Ready time (%RDY). vCPU'nun çalışmaya hazır olduğu hâlde fiziksel işlemci beklediği süre. Artıyorsa host doygunluğa yaklaşıyordur.
  2. Co-stop (%CSTP). Çok vCPU'lu makinelerde, vCPU'lar arasındaki ilerleme farkı nedeniyle beklenen süre. Geniş sanal makinelerin fazla olduğu host'larda yükselir.
  3. Uygulamanın kendi yanıt süresi. Sonuçta önemli olan budur; hypervisor metrikleri yalnızca nedeni açıklar.

Bu üçü birlikte değerlendirilmelidir. Yüksek işlemci kullanımı tek başına sorun değildir — kaynak zaten kullanılmak içindir. Sorun, bekleme başladığında ortaya çıkar.

CPU ile bellek overcommitment'ı aynı şey değil#

Bu iki kavram sık sık birlikte anılır ama davranışları temelden farklıdır.

İki overcommitment türünün davranışı
ÖlçütCPUBellek
Kaynak türüZamanla paylaşılırAynı anda kaplanır
Aşırıya kaçıldığındaİşler yavaşlar (bekleme artar)Geri kazanım devreye girer, sonunda takas (swap) başlar
Geri dönüşYük düşünce hemen düzelirTakasa düşen sayfalar kalıcı yavaşlık yaratabilir
Risk profiliKademeli bozulmaEşik aşılınca sert bozulma

Tablo yatay olarak kaydırılabilir.

İşlemci zamanla paylaşılabilir; bellek paylaşılamaz. Bir sanal makine 16 GB belleği gerçekten kullanıyorsa, o bellek o an başka bir makinede olamaz. Bu yüzden bellekte aşırıya kaçmak, işlemcide aşırıya kaçmaktan daha risklidir.

Pratik yaklaşım#

  • Başlangıç için ölçülü bir oranla başlayın, sonra ölçüme göre ayarlayın.
  • Aynı host'ta çok sayıda geniş (çok vCPU'lu) sanal makine toplamaktan kaçının.
  • Kritik iş yüklerini, bekleme süresine duyarlı oldukları için ayrı değerlendirin.
  • Bellek tarafında geri kazanımın devreye girmediği bir tampon bırakın.
  • Yedeklilik planında host arızası sonrası kalan host'ların yükü taşıyabileceğinden emin olun.

Önemli noktalar

  • Overcommitment, kaynakların aynı anda tam kullanılmadığı varsayımına dayanır.
  • Sabit vCPU/pCPU oranları yol gösterici olabilir ama karar verici değildir.
  • Ready time ve co-stop, doygunluğun erken göstergeleridir.
  • Bellekte aşırıya kaçmak, işlemcide aşırıya kaçmaktan daha risklidir.