Yükseltmeden önce bellek ve disk uyarılarını okuyun.

Bağlamla küçük bir temel değer yakalayın

İşlettiğiniz uygulamayı incelemesine izin verilen bir Linux hesabı kullanın. Buradaki komutlar durumu inceler; dosyaları silmez veya depolamayı yeniden boyutlandırmaz. Bazı dizinler ve günlükler yükseltilmiş erişim gerektirir. Değiştirin /var/lib/field-api, /opt/field-api ve /opt/first-api gerçek uygulama yollarıyla ve sonuçları yorumlamadan önce bu yolların var olduğunu doğrulayın.

Saati, geçerli sürümü ve etkinliği kaydedin: olağan trafik, bir yükleme, bir rapor işi veya bir dağıtım derlemesi. Karşılaştırılabilir etkinlik sırasında başka bir okuma alın. İki ilgisiz ekran görüntüsü sağlıklı bir makineyi tutarsız gösterebilir. Kullanıcılar zaten etkileniyorsa ilk faydalı ipucunu şuradan yakalayın: uygulama hatası kılavuzu aynı anda birkaç değişiklik yapmadan önce.

Kullanılabilir belleği okuyun, ardından iş yükünü inceleyin

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

Şurada free, kullanılabilir bellek takas yapmadan yeni uygulamalar için neyin kullanılabileceğini tahmin eder. Geri kazanılabilir önbelleği hesaba katar, bu nedenle tamamen kullanılmayan "boş" bellekten farklı bir soruyu yanıtlar. Bkz. upstream free kılavuzu. Linux dosya önbellekleme için bellek kullanır; tek başına büyük bir önbellek bir sızıntının kanıtı değildir. çekirdek bellek genel bakışı önbellek ve uygulama belleğinin neden bir arada bulunduğunu açıklar.

Örnek okuma, sunucu ölçümü değil: küçük bir ana makinede yaklaşık 1.9 GiB kullanılabilir bellek, 80 MiB boş ve 850 MiB kullanılabilir. Düşük boş değer tek başına bir yükseltmeyi haklı çıkarmaz. Bir rapor sırasında kullanılabilir bellek tekrar tekrar sıfıra yaklaşırsa, istekler yavaşlarsa ve ilgili ayırma veya bellek yetersizliği mesajları görünürse, bu birleşik kanıt incelenmeyi hak eder.

Bu ps komutu süreç RSS'ini KiB cinsinden, en büyükten başlayarak listeler. RSS yerleşik belleği tanımlar, özel sahipliğin tam bir muhasebesi değildir; paylaşılan sayfalar birden çok süreçte görünebilir. Her RSS değerini toplayıp sonucu tam ana makine kullanımı olarak değerlendirmeyin. upstream ps başvurusu RSS'i ve sıralamayı tanımlar. Süreç adını ve iş yükü bittikten sonra izinin önceki seviyesine dönüp dönmediğini kaydedin.

Kullanımdaki takas önceki etkinliği yansıtabilir; tek başına mevcut baskıyı kanıtlamaz. Ayrıca ana makine kapasitesini hizmet veya kapsayıcı sınırlarından ayırın. Kısıtlanmış bir süreç, ana makinede hâlâ kullanılabilir bellek varken başarısız olabilir. VPS boyutunu artırmadan önce yapılandırılmış sınırı ve başarısızlık zamanını inceleyin. Çekirdeğin proc dosya sistemi başvurusu bu gözlemlerin arkasındaki bellek alanlarını belgeler.

Gerçekten dolan dosya sistemini bulun

df -h / /opt/first-api
df -i / /opt/first-api

İlk komut bu yolları içeren dosya sistemlerindeki alanı bildirir. İkincisi, dosya ve dizinler için gereken dosya sistemi kayıtları olan inode'ları bildirir. Çok sayıda küçük dosya içeren bir iş yükü, bayt kapasitesi kalırken inode'ları tüketebilir. Tek sayınız olarak tüm VPS'nin boyutunu kullanmak yerine bağlama noktasını ve her iki kapasite türünü kontrol edin. Bkz. GNU df kılavuzu.

Ayrı bağlanmış bir birimdeki bir yol, kök dosya sisteminden bağımsız olarak dolabilir. Tersine, listelenen iki yol aynı dosya sistemine ait olabilir, dolayısıyla kullanılabilir alanları toplanamaz. Dosya sistemi rezervasyonları, kotalar ve depolama katmanları da uygulamanın ne yazabileceğini etkileyebilir. Tek bir görüntülenen yüzde, büyümenin sahibini tanımlamaz.

Büyümeyi günlüklere, yüklemelere veya yapıtlara atfedin

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du her dizin altındaki ayrılmış alanı tahmin eder. Burada -x başka bir dosya sistemine geçmeyi önler, -h okunabilir birimler kullanır ve -d1 görüntülenen derinliği sınırlar. Büyük ağaçların taranması yine de zaman ve disk etkinliği alabilir. İzin hataları görünümün eksik olduğu anlamına gelir. Bkz. GNU du kılavuzu. Günlük komutu, etkin ve arşivlenmiş dosyalar dâhil günlük depolamasını bildirir; belgelendiği üzere journalctl.

En büyük dizinleri amaçlarıyla karşılaştırın:

• Günlükler: tekrarlanan bir hata hacmi artırdı mı ve rotasyon yapılandırıldı mı?
• Yüklemeler: saklanan kullanıcı dosyaları beklendiği gibi büyüyor mu ve yarım kalan yüklemeler hesaba katıldı mı?
• Sürüm yapıtları: eski derlemeler geri alma ilkesinin ötesinde birikiyor mu?
• Veritabanı dosyaları: veritabanının kendi araçları büyümeyi ve bakım ihtiyaçlarını açıklıyor mu?

Bir soruşturma adımı olarak tanımadığınız bir veritabanı dizinini silmeyin veya geniş bir kapsayıcı birimi temizliği kullanmayın. Önce sahipliği, saklama gereksinimlerini ve kurtarılabilir bir kopyayı belirleyin. Eğer df ve dizin toplamları önemli ölçüde farklıysa, deneyimli bir operatörle bağlama sınırlarını, erişim hatalarını ve silme sonrası hâlâ açık tutulan dosyaları inceleyin; görünen dosyaları tekrar tekrar silmek kaplanan alanı gözden kaçırabilir.

Okumaları belirli bir sonraki eyleme dönüştürün

Örnek durum: kullanılabilir bellek rahat kalır, ancak bir yükleme dizini gözlemlenen iki günün her birinde yaklaşık 400 MiB büyür. Dosya sisteminde yaklaşık 2 GiB kullanılabilir alan var. Kalan alanı bu kısa vadeli büyümeye bölmek, işletim payı bırakmadan önce aynı oranda yalnızca yaklaşık beş güne işaret eder. Bu bir planlama tahminidir, bir öngörü veya beklenilecek güvenli bir son tarih değildir; yüklemeler ve geçici işler düzensiz gelebilir.

Sonraki eylem, yükleme saklamayı ve beklenen talebi kontrol etmek, haklıysa ek depolama planlamak ve harekete geçmek için yeterince erken bir uyarı ayarlamaktır. Daha fazla RAM bu bulguyu çözmez. Farklı bir durumda, bir dağıtım derlemesi hizmet küçük kalırken kısa süreli bir bellek zirvesi oluşturabilir; derlemeyi VPS'den taşımak, çalışma zamanını kalıcı olarak büyütmekten daha faydalı olabilir.

Haklı bir değişiklikten sonra aynı okumaları ve bir uygulama eylemini tekrarlayın. Alanın gerçekten kullanılabilir olduğunu ve amaçlanan verilerin hâlâ çalıştığını doğrulayın. Silme ve yeniden boyutlandırmayı kırmızı bir sayıya otomatik yanıtlar değil, kurtarma adımları olan planlı işlemler olarak tutun. Kullanın kaynak bütçesi kılavuzu kanıtlanmış bir ihtiyacı yapılandırma seçeneklerine dönüştürmek için ve şunu alıştırın: geri yükleme bir temizliğe veya geçişe güvenmeden önce.