Bir SaaS VPS'ini iş yükü bütçesine göre boyutlandırın

Ana makineyi seçmeden önce işi adlandırın

İstek yolunu çizin: ters proxy, API süreci, veritabanı ve dış hizmetler. Asenkron yolu ekleyin: kuyruk, çalışan ve dışa aktarma hedefi. Hangi bileşenlerin ana makineyi paylaştığını, eşzamanlılığı kimin kontrol ettiğini ve hangi verilerin yeniden oluşturmadan sağ çıkması gerektiğini kaydedin. Uygulama metriklerine ve temsili verilere sahip üretim dışı bir iş yüküne ihtiyacınız vardır; bu kılavuz sağlanmış bir PrivacyNodes örneği varsaymaz.

Örnek bir raporlama API'si için, bir HTTP isteği hesap ayarlarını okur ve bir dışa aktarma işlemini kuyruğa alır. Çalışan satırları tarar ve bir dosya yazar. Hızlı bir kuyruğa alma yanıtı, dışa aktarmanın yoğun trafik sırasında tamamlanabileceğini kanıtlamaz. Test planına zamanlanmış temizliği ve dağıtım örtüşmesini dahil edin.

Bellek çalışma sayfasına örtüşmeyi ekleyin

Bunlar MiB cinsinden varsayımsal planlama girdileridir, PrivacyNodes hakkında ölçümler veya vaatler değildir. Bunları gözlemlenen uygulama gereksinimleriyle değiştirin. RSS, yerleşik paylaşılan eşlemeleri içerir; her sürecin RSS'ini toplamak belleği iki kez sayabilir. Ana makinenin kullanılabilir belleği, tüm dosya sistemi önbelleğini kalıcı olarak kullanılamaz saymaktan daha yararlıdır.

Teknik referans: Linux süreç bellek muhasebesi.

Bu, rahat kapasite varsaymak için nominal bir 4 GB zarfına çok yakındır. Ana makinenin bildirdiği gerçek belleği ve zirvelerin örtüşüp örtüşmediğini kontrol edin. Eşzamanlılığı azaltın, bir bileşeni taşıyın veya bellek ekleyin; tabloyu uydurmak için rezervi kaldırmayın.

PostgreSQL work_mem işlem başına bir ödenektir, toplam veritabanı sınırı değildir. Eşzamanlı oturumlar ve işlemler etkisini çoğaltabilir. Docker konteynerlerinin varsayılan olarak CPU veya bellek kısıtlaması yoktur; bir imaj kaynak politikası değildir.

Teknik referans: PostgreSQL kaynak tüketimi · Docker kaynak kısıtlamaları.

CPU'yu kuyruk yaşıyla birlikte ölçün

Sıradan bir isteği, en yavaş yararlı raporu, başarısız bir bağımlılığı ve bir dışa aktarmayı birlikte deneyin. Aynı aralıkta gecikme yüzdeliklerini, hataları, ana makine CPU'sunu, çalışan eşzamanlılığını ve en eski iş yaşını kaydedin. Kuyruk büyümesiyle birlikte CPU baskısı, uzun veritabanı beklemesiyle birlikte düşük CPU'dan farklı bir eylem önerir.

Örneği uçuşta bir dışa aktarmayla başlatın. Çalışan dış depolamayı bekliyorsa, ekstra CPU az şey değiştirebilir. API gecikmesi artarken sürekli bir çekirdeği doyuruyorsa, daha küçük bir dışa aktarma grubunu veya ayrı bir çalışan bütçesini test edin. Kapasite satın almadan önce bir faktörü değiştirin ve aynı senaryoyu tekrarlayın.

Bir sonraki bakım işlemini bütçeleyin

Veritabanı dosyalarını ve dizinlerini, yüklemeleri, günlükleri, geçici dışa aktarmaları, sürüm yapılarını ve bakım için boş alanı listeleyin. Haftalık büyümeyi ve rezervinizin ne zaman tükeneceğini kaydedin. Bir 20 GB veri kümesi artı bir 20 GB geçici kopya, sıradan uygulama trafiği sakin olsa bile 20 GB'den fazlasını gerektirir.

Günlük rotasyonu ve dışa aktarma süresi sonunu atayın. Kurtarma kopyalarını ana makinenin arıza sınırının dışında tutun. Ek VPS depolaması çalışma tahsisini genişletir; aynı diskteki bir kopya bağımsız bir yedek değildir. Hem normal çalışmayı hem de bir yedekleme veya dışa aktarmayla birlikte çalışan bir sürümü test edin.

Yeniden gözden geçirilebilecek bir karar yazın

Çıktınız bir çalışma sayfası, bir iş yükü tanımı ve bir gözden geçirme tetikleyicisidir: temsili test sırasında en eski iş yaşının büyümesi, bakım alanının küçülmesi veya mevcut süreçlerle bir arada bulunamayan bir sürüm. Evrensel bir CPU yüzdesi eşiği uydurmak yerine gözlemleri kaydedin.

Karşılaştır App 2 ve Scale 4 bu kısıtlamalara karşı. Sonuç hâlâ sizi şaşırtıyorsa, yığın boyunca bir yavaş isteği izleyin. Bu alıştırma iş yükünüzü tahmin eder; hiçbir tedarikçi kıyaslaması, trafik kapasitesi veya kullanılabilirlik oluşturmaz.