Bu Konu Neden Önemli?
CPU overcommit, toplam vCPU sayısının fiziksel işlemci thread sayısından fazla olmasıdır; kabul edilebilir oran iş yükü davranışına ve peak kullanıma bağlıdır.
Karar Verirken Kontrol Edilecek Noktalar
vCPU sayısını yalnız VM adedine göre vermeyin.
CPU ready/wait benzeri gecikme sinyallerini izleyin.
Peak yükleri ortalama değerlerden ayırın.
Latency-sensitive iş yüklerini ayrı değerlendirin.
Mimari ve çalışma modeli
CPU overcommit atanmış vCPU sayısı ile fiziksel yürütme kaynaklarının paylaşılmasıdır. Fiziksel çekirdek ve SMT thread aynı kapasite birimi değildir. Uygun oran iş yükünün aynı anda CPU talep etmesine bağlıdır; sabit bir evrensel oran kullanılmaz. Gereksiz büyük VM, zamanlama ve NUMA yerleşimini zorlaştırabilir.
- 1Fiziksel çekirdek/thread
- 2vCPU talebi
- 3Hypervisor zamanlaması
- 4Bekleme ve uygulama yanıtı
Tasarım parametreleri
- Fiziksel kaynak hesabı
- Çekirdek, SMT thread ve vCPU sayılarını ayrı tutun; oranı aktif eşzamanlı yükle değerlendirin.
- Zamanlama beklemesi
- Ready/wait ve tek çekirdek doygunluğunu toplam CPU yüzdesiyle birlikte ölçün.
- Yoğun saat iş yükü
- CPU, bellek, disk ve ağ ölçümlerini aynı zaman aralığında toplayın. Bir kaynak yüzdesi tek başına sizing kararı verdirmez.
- N-1 kapasitesi
- Bir bileşen kaybedildiğinde kalan kapasiteyi hesaplayın. Normal durumda boş pay görünmesi arızada yeterli kapasite bulunduğunu kanıtlamaz.
- Uyumluluk zinciri
- CPU, firmware, sürücü, hypervisor ve konuk uygulamaların destek koşullarını birlikte inceleyin.
- İşletim rezervi
- Backup, migration, bakım ve büyüme aynı kaynaklarla yarışır. Rezervi yalnız ortalama yük üzerinden belirlemeyin.
Hesap ve uygulama örneği
32 fiziksel çekirdeğe atanmış 128 vCPU sayısal olarak 4:1 görünür; fakat bu performans garantisi değildir. Yoğun saat uygulama gecikmesi ve hypervisor zamanlama beklemelerini inceleyin. Bir VM’nin vCPU sayısını artırmadan önce tek-thread sınırı ve I/O beklemesini ayırın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| vCPU eklendi, performans düştü | Zamanlama ve NUMA yerleşimi daha pahalı hale gelmiş olabilir. | Aynı transaction yükünde küçük/büyük VM atamasını ve beklemeleri karşılaştırın. |
| Düşük CPU kullanımına rağmen uygulama yavaş | Depolama, kilit, tek çekirdek veya zamanlama beklemesi toplam CPU değerinde görünmeyebilir. | Uygulama gecikmesini çekirdek, disk ve hypervisor beklemeleriyle eşleştirin. |
| Arıza sonrası host aşırı yükleniyor | Kapasite planı normal dağılım için yapılmış, N-1 durumu dışarıda kalmış olabilir. | Kontrollü arıza testinde kalan RAM, CPU ve depolama gecikmesini ölçün. |
| Değişiklikten sonra performans kötüleşti | Sürücü, firmware, NUMA yerleşimi veya kaynak ataması değişmiş olabilir. | Aynı iş yükünde önce/sonra karşılaştırma yapın; bir değişkeni bir seferde değiştirin. |
Kabul ve doğrulama kontrolleri
- Oran kadar yoğun saatteki eşzamanlı talebi ve zamanlama beklemesini ölçün.
- Yoğun saat yükünü ve bakım işlerini birlikte temsil eden test çalıştırın.
- Bir host veya bağlantı kaybında hizmet ve veri yazmasını doğrulayın.
- Konuk işletim sistemi ve uygulama desteğini resmî matriste kontrol edin.
- Yeniden başlatma sonrasında aygıt, servis ve depolama sağlığını doğrulayın.
- Kapasite hesabının ham ve kullanılabilir değerlerini ayrı saklayın.
İlgili kavramlar
Kaynak rekabeti
Kaynak rekabeti, birden fazla iş yükünün aynı CPU, bellek, disk veya bağlantıyı paylaşırken birbirini bekletmesidir. Boş görünen toplam kapasite, tek bir sıcak çekirdek veya tek kuyruk üzerindeki darboğazı gizleyebilir. Aynı anda çalışan backup, antivirüs taraması, indeks bakımı ve kullanıcı trafiğini zaman çizelgesinde karşılaştırın. Kaynak eklemeden önce darboğazın yerini doğrulayın. Testte bir işi tek başına ve diğerleriyle birlikte çalıştırarak paylaşılan kaynağın etkisini ayırın; ortalama kullanım kadar yoğun saatlerdeki gecikmeyi de raporlayın.
NUMA yerelliği
NUMA sistemlerde işlemci, kendisine yakın bellekle uzak düğüm belleğine farklı maliyetle erişebilir. Bir sanal makinenin vCPU ve bellek boyutu, fiziksel düğüm kapasitesi ve hypervisor yerleştirmesiyle birlikte değerlendirilir. Daha fazla vCPU vermek her zaman hız kazandırmaz; yerellik kaybı ve zamanlama beklemesi performansı düşürebilir. Fiziksel topolojiyi, VM içindeki görünen topolojiyi ve gerçek iş yükünün bellek davranışını birlikte kaydedin. Değişikliği aynı yük altında önce/sonra karşılaştırın; yalnız CPU yüzdesi yerine uygulama gecikmesini ve uzak bellek etkisini inceleyin.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Kuyruk ve eşzamanlılık
Kuyruk, bir kaynağın işleyebildiğinden daha hızlı gelen işleri tutar. Eşzamanlılığı artırmak belirli bir noktaya kadar kapasite kullanımını yükseltir; sonra bekleme süresini büyütür. Durağan durumda Little yasası L = λ × W ilişkisidir: ortalama sistemdeki iş sayısı, tamamlanan iş hızı ile ortalama toplam sürenin çarpımıdır. Birimler tutarlı olmalıdır. 2.000 işlem/s ve 5 ms toplam süre yaklaşık 10 eşzamanlı iş demektir. Bu ilişki tasarım tahminidir; kuyruk sınırları, ani yük ve çok değişken servis süreleri ayrıca ölçülmelidir.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun