Gerçekten çalıştırdığınız uygulamayı boyutlandırın.

Ölçümden önce

Kontrol ettiğiniz bir Linux test makinesi, uygulamanız ve temsili verilerle kullanın. Aşağıdaki komutlar kaynakları inceler; çekirdeği ayarlamaz veya dosyaları silmez. procps ve GNU coreutils'e ve seçilen uygulama dizinini inceleme iznine ihtiyacınız vardır. Şunu değiştirin: /srv/my-app gerçek yoluyla. Uygulama henüz hiçbir yerde çalışmıyorsa, ilk tahmini oluşturmak için geliştirme veya hazırlama ortamını kullanın, ardından bu tahmini hedeflenen sistemde yeniden gözden geçirin.

VPS'yi neyin paylaştığını yazın: işletim sistemi, proxy, API, veritabanı, çalışanlar ve izleme. Varlık derlemelerinin orada çalışıp çalışmadığını, yedeklerin yerel olarak sıkıştırılıp sıkıştırılmadığını ve planlanmış bir görevin bir dağıtımla çakışıp çakışamayacağını kaydedin. Sessiz bir uygulama süreci, pahalı bir sürüm süreciyle bir arada bulunabilir.

Kullanılabilir belleği okuyun ve süreçleri belirleyin

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m mebibayt bildirir. Şuna odaklanın: available, takas yapmadan yeni işi destekleyebilecek bellek tahmini; free tek başına yararlı geri kazanılabilir belleği dışlar. Bu nedenle önbellek, tek başına daha fazla RAM satın almak için bir neden değildir. Şu kaynağa bakın: free alan tanımları.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Yukarıdaki RSS değerleri kabaca 384, 180 ve 32 MiB'ye karşılık gelir. Bellek kullanımını bulmaya yardımcı olurlar, ancak her RSS değerini toplamak tam bir makine toplamı değildir: paylaşılan sayfalar birden fazla kez sayılabilir ve bazı çekirdek maliyetleri süreç rakamının dışındadır. Bir rapor toplarken komut argümanlarını veya ortamlarını yazdırmaktan kaçının, çünkü gizli bilgiler içerebilirler. Şu kaynak: ps kılavuzu alanlarını ve anlık görüntü davranışını açıklar.

Gözlemleri bir çalışma sayfasına dönüştürün

Aşağıdaki ödenekler, yerel bir veritabanı ve bir çalışan içeren küçük bir API'yi örnekler. Bunlar uydurma planlama değerleridir; belirli bir çerçeve için kıyaslama veya minimum gereksinim değildir. Ölçümlerinizi koyun ve hangi ödeneklerin aynı anda zirve yapabileceğini not edin.

Bu çalışma sayfası zaten 1,024 MiB bütçesini aşıyor. 2,048 MiB'lik bir test ortamı, bu ödeneklere karşı 676 MiB bırakırdı, ancak yararlı sonuç, uygulama yanıt verirken gerçek temsili işin sığıp sığmadığıdır. Dağıtım ödeneği baskınsa, kalıcı sunucuyu büyütmek yerine artefaktları başka yerde derlemek daha iyi bir değişiklik olabilir. Varsayımları toplamın yanında koruyun.

Faydalı iş sırasında CPU ve takas alanını izleyin

vmstat 1 10

Bunu temsili bir istek toplu işlemi, bir görev ve bir sürüm sırasında çalıştırın. Yakın bir aralığı yorumlarken ilk satırı yok sayın: önyüklemeden bu yana etkinliği özetler. Sonraki satırlar örnekleme aralıklarını açıklar. Şurada kalıcı çalıştırılabilir iş: r, şurada düşük boşta kalma süresi: id ve yavaş istekler birlikte CPU baskısını araştırmayı haklı çıkarır. Tekrarlanan si/so etkinliği takas yapıldığını gösterir; tek başına ayrılan takas alanı mevcut baskıyı kanıtlamaz. wa ve st otomatik bir CPU yükseltmesi yerine bağlam gerektirir. Bu alanlar şurada tanımlanmıştır: vmstat.

Uygulamadaki yanıt süresini de kaydedin. Yavaş bir harici API veya veritabanı sorgusu, CPU büyük ölçüde boşta kalırken isteklerin beklemesine neden olabilir. Hangi değişikliğin yardımcı olduğunu bilmek için bir değişiklikten sonra aynı iş yükünü tekrarlayın. Yük testleri yalnızca kontrol ettiğiniz sistemleri hedeflemeli, diğer kullanıcıları rahatsız etmeyen bir hız ve durma koşuluyla yapılmalıdır.

Disk büyümesini ve transferi ayrı ayrı bütçeleyin

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df yolu içeren dosya sistemini, diğer dizinlerle paylaşılan alan dahil olmak üzere açıklar; df -i desteklendiği yerde inode kullanımını kontrol eder. Çok sayıda küçük dosya, bayt kapasitesinden önce inode'ları tüketebilir. du seçilen ağacı erişim izinlerine tabi olarak tahmin eder. Bunlar farklı sorulardır, bu nedenle toplamlarının eşleşmesi gerekmez. Şu kaynaklara bakın: df ve du.

Mevcut veritabanını, yüklemeleri, günlükleri, uygulama artefaktlarını ve yerel yedekleme hazırlama alanını listeleyin. Önceki sürümün yanı sıra bir sürüm için gereken alanı ekleyin, ardından bir sonraki inceleme aralığındaki büyümeyi tahmin edin. Örneğin, her gün 100 MiB yeni yükleme, kopyalar veya yedeklerden önce 30 gün içinde yaklaşık 3,000 MiB ekler. Sonucu bir katalogla karşılaştırırken ondalık GB ve ikili GiB'yi tutarlı şekilde etiketleyin.

Transfer için, 50,000 kez gönderilen örnek bir 20 kB yanıtı yaklaşık 1 GB yanıt yüküdür. Yüklemeleri, statik dosyaları, protokol ek yükünü ve yedekleme trafiğini ekleyin. Bu aritmetik hacmi tahmin eder, aktarım hızını veya eşzamanlı kullanıcıları değil. Hizmetin trafiği nasıl saydığını ve fazlalığı nasıl ele aldığını doğrulayın.

Sonraki eylemi seçin ve kontrol edin

• Normal zirvelerde düşük kullanılabilir bellek: ana tüketicileri inceleyin ve daha büyük bir bellek bütçesini test edin.
• Sürekli CPU baskısıyla yavaş istekler: yoğun yolu profillendirin, ardından aynı iş yükünü kullanarak CPU değişikliklerini karşılaştırın.
• Artan disk kullanımı: herhangi bir şeyi silmeden önce sorumlu dizini ve saklama ilkesini belirleyin.
• Kaynaklar rahat görünüyor ancak uygulama yavaş: bağımlılıkları, sorguları ve istek yolunu araştırın.

Çalışma sayfasını iş yükü açıklaması, örnekleme zamanı, birimler ve sonraki inceleme tarihiyle birlikte kaydedin. Önemli bir sürüm, veri büyümesi veya eklenen bir çalışandan sonra yeniden kontrol edin. Bu gözlemlere göre bir yapılandırma seçin; hiçbir plan adı istek kapasitesini garanti etmez. Şununla devam edin: bellek ve disk uyarılarını okuma veya ilk API kaynak senaryosu.