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
- 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.
- 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.
- 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.
| Ölçüt | CPU | Bellek |
|---|---|---|
| Kaynak türü | Zamanla paylaşılır | Aynı 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üzelir | Takasa düşen sayfalar kalıcı yavaşlık yaratabilir |
| Risk profili | Kademeli bozulma | Eş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.
Konuk içinde %100 CPU kullanımı overcommitment sorunu mu?#
Genellikle değil. Bu iki ölçüm farklı soruları yanıtlar ve birbirinin yerine kullanılamaz.
Konuk işletim sisteminin gösterdiği %100, "bana verilen vCPU'ları tam kullanıyorum" demektir. Bu tek başına bir sorun değil; hatta boyutlandırmanın doğru olduğunun işareti olabilir.
Overcommitment sorunu ise host tarafında görünür: sanal makinenin çalışmaya hazır olduğu hâlde işlemci sırası beklediği süre. Konuk bu beklemeyi göremez — kendi içinden bakınca zaman geçmemiş gibidir.
Oran hesabında hyper-threading sayılır mı?#
Bu, aynı ortam için iki farklı sonuç üreten bir tanım sorusudur ve bir kural yoktur — kararı siz verip tutarlı uygularsınız.
32 fiziksel çekirdekli, 64 mantıksal işlemcili bir host'ta 128 vCPU tanımlıysa:
- Fiziksel çekirdeğe göre oran 1:4
- Mantıksal işlemciye göre oran 1:2
İki sayı da doğrudur, farklı şeyi ölçerler. Sorun, bir ortamda birinci tanımla bir başkasında ikinci tanımla çalışıp iki ortamı karşılaştırmaktır.
Daha sağlam yaklaşım, mantıksal işlemcinin fiziksel çekirdek kadar kapasite sunmadığını bildiğiniz için fiziksel çekirdeği temel almaktır. Bu, oranı olduğundan iyi göstermez.
Hangi iş yükleri overcommitment'a uygun değildir?#
Overcommitment, iş yüklerinin aynı anda tepe kullanıma çıkmaması varsayımına dayanır. Bu varsayımın geçerli olmadığı durumlarda uygulanmaz:
- Gecikmeye duyarlı sistemler. Ses/görüntü işleme, gerçek zamanlı kontrol ve sıkı yanıt süresi taahhüdü olan servisler. Burada ortalama performans değil, en kötü durum önemlidir.
- Sürekli tepe çalışan iş yükleri. Toplu hesaplama, derleme sunucuları, yoğun analiz işleri. Vadi yoksa paylaşılacak boşluk da yoktur.
- Çekirdek başına lisanslanan ürünler. Kapasiteyi zaten ödediğiniz için sıkıştırmanın getirisi yoktur.
- Çok büyük tek makineler. Host'un çekirdek sayısına yaklaşan bir makine, zamanlanabilmek için çok sayıda çekirdeğin aynı anda boşalmasını bekler; bu bekleme çekişmeyi hızla büyütür.
Overcommitment yapılmazsa ne kaybedilir?#
Hiç overcommitment yapmamak güvenli görünür ama bedeli vardır: donanımın önemli bir bölümü sürekli boş durur.
Çoğu ortamda sanal makineler zamanın büyük kısmında kendilerine verilen kapasitenin küçük bir yüzdesini kullanır. Tepe değerlere göre birebir kapasite ayırmak, o tepe anları dışında ödenmiş ve kullanılmayan donanım anlamına gelir.
Bu yüzden doğru soru "overcommitment yapılmalı mı" değil, "hangi iş yükünde ne kadar" sorusudur. Yanıt ölçümle verilir; sabit bir oranla değil.
Ö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.
