VPS CPU ve RAM Yüksekliği: Linux Teşhis Rehberi

Önce etkilenen işlemi ve zaman aralığını kaydedin

Sorun bütün sitede mi, yalnız yönetim panelinde mi, belirli bir iş kuyruğunda mı görülüyor? Başlangıç saatini, son dağıtımı, yedek veya raporlama görevlerini not edin. Bir işlemin beklenen sürede tamamlanıp tamamlanmadığı, kaynak göstergesinin tek başına yüksek olmasından daha önemlidir.

HTTP hata oranı, kuyruk yaşı ve yanıt süresini aynı aralıkta değerlendirin. Dış API yavaşlığı içeride çok sayıda bekleyen isteğe ve bellek artışına dönüşebilir. Buna yalnız yerel CPU eklemek bağımlılığı hızlandırmaz. İzleme geçmişi varsa yoğun dönemle benzer sakin bir dönemi karşılaştırın.

Load average değerini CPU yüzdesi gibi okumayın

getconf _NPROCESSORS_ONLN
uptime
LC_ALL=C vmstat 1 5
free -h

uptime çıktısındaki load average, 1, 5 ve 15 dakikalık çalışabilir veya kesilemeyen bekleme durumundaki işlerin ortalamasıdır. Linux’ta I/O bekleyen işler de bu değere katkı verebilir. Değer CPU sayısına göre normalize edilmez; vCPU sayısıyla karşılaştırırken hangi işlerin beklediğini de inceleyin.

vmstat içindeki r çalışabilir işleri, b I/O nedeniyle bloklanan işleri gösterir. CPU alanlarındaki us kullanıcı kodunu, sy çekirdek işini, id boş zamanı, wa I/O beklemesini ve st sanal makinenin kaybettiği işlemci zamanını belirtir. İlk raporun CPU/I/O oranları açılıştan itibaren ortalamadır; sonraki satırlar örnekleme aralığını gösterir.

Yüksek wa tek başına depolama aygıtının kesin kapasite sınırını göstermez. Yüksek st de tek gözlemle belirli bir komşu müşteriyi veya altyapı arızasını kanıtlamaz. Süreklilik, uygulama etkisi ve diğer sayaçlarla birlikte değerlendirin; gerekiyorsa zaman damgalı bulgularla sağlayıcıya başvurun.

İşi yapan süreci ve kaynak baskısını bulun

ps -eo pid,comm,stat,pcpu,pmem,rss --sort=-pcpu | head -n 12
cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

ps çıktısı ilk adayları gösterir; yüzde CPU değeri süreç ömrü üzerinden hesaplanan bir ortalamadır. Anlık örneklemeyle eşdeğer kabul etmeyin. RSS yerleşik bellektir; süreçlerin paylaştığı sayfalar nedeniyle bütün RSS değerlerini toplayarak toplam tüketimi doğru hesaplayamazsınız. Süreç adını uygulamanız ve göreviyle eşleştirin.

PSI dosyaları çekirdek desteğine bağlıdır. some, en az bazı işlerin ilgili kaynak yüzünden beklediği zaman payını gösterir. avg10, avg60 ve avg300 farklı zaman pencerelerini ifade eder. Bellek ve I/O için full, bütün etkin işlerin aynı anda beklediği dönemleri ayırmaya yardımcı olur. PSI bir paket önerisi değil, beklemenin etkisini gösteren ek kanıttır.

Free yerine available ve bellek hareketine bakın

Linux kullanılmayan belleğin bir kısmını dosya önbelleğine ayırır. Bu yüzden free düşükken sistem yeni uygulamalar için kullanılabilir belleğe sahip olabilir. free komutundaki available, swap yapmadan yeni işlere ayrılabilecek bellek için bir tahmindir; önbelleğin tamamının hemen geri kazanılabileceğini varsaymaz.

Swap üzerinde veri bulunması tek başına etkin bellek sıkışması değildir. vmstat içindeki si ve so değerlerinin sonraki örneklerde sürüp sürmediğine, available eğilimine ve uygulama gecikmesine bakın. Swap kullanımını sıfırlamak amacıyla ayar değiştirmek teşhis değildir; mevcut yükün dayanabileceği bellek alanını azaltabilir.

OOM sonlandırmasını kayıttan doğrulayın

journalctl -k --since '30 minutes ago' --no-pager -n 120
journalctl -u systemd-oomd --since '30 minutes ago' --no-pager -n 60

Sürecin kaybolduğu saatle bellek kayıtlarını eşleştirin. Çekirdeğin OOM kararı ile systemd-oomd gibi kullanıcı alanında çalışan bir yöneticinin kararı farklı kayıtlarda bulunabilir. Günlüklere erişim yetkisi veya ilgili servis yoksa boş çıktı, olay yaşanmadığını kanıtlamaz.

Bir container’ın 137 koduyla çıkması SIGKILL ile sonlandırılmasına işaret edebilir; tek başına OOM kanıtı değildir. Manuel sonlandırma veya başka bir yönetici de aynı sonucu doğurabilir. cgroup v2 memory.events içindeki oom_kill birikimli sayaçtır. Artışını, servis yeniden oluşturulmasını ve olay zamanını birlikte inceleyin.

VPS boş görünse bile servis sınırını kontrol edin

diagnostic_unit='example.service'
systemctl show "$diagnostic_unit" \
  -p ControlGroup -p MemoryCurrent -p MemoryMax -p CPUQuotaPerSecUSec

example.service yerine kendi servisinizi yazın. Cgroup veya container bellek sınırı, VPS’de görünen toplam RAM’den daha düşük olabilir. memory.max sınırına ulaşan bir grup, sistemde kullanılabilir bellek varken de OOM yaşayabilir. Üst cgroup veya slice sınırlarını da hesaba katın; tek bir özellik satırı bütün hiyerarşiyi açıklamayabilir.

Benzer şekilde çevrimiçi CPU sayısı, bir servis için izin verilen işlem süresini tek başına göstermez. CPU kotası ve throttling sayaçlarını uygulama gecikmesiyle karşılaştırın. ServerQ VPS’de tahsis edilen vCPU, fiziksel işlemcinin tamamının size ayrıldığı anlamına gelmez. Konuk içindeki yanlış servis sınırını paket yükselterek düzeltmeyi beklemeyin.

Darboğaza göre optimizasyon veya kaynak artışı seçin

Tek değişkeni değiştirip aynı iş yükünde sonucu karşılaştırın. Worker sayısını artırmak daha fazla paralellik sağlarken bellek tüketimini büyütebilir. Yedek saatini değiştirmek, kuyruk sınırı koymak veya gereksiz sorguyu kaldırmak bazen daha etkili olur. Gerçek ve sürekli büyümede ise ölçülmüş ihtiyaca göre kaynak artırmak makul olabilir.

Düzeltmenin etkisini kullanıcı sonucuyla doğrulayın

Önceki ve sonraki hata oranını, gecikmeyi, kuyruk yaşını ve kaynak baskısını aynı koşullarda kaydedin. Sadece CPU göstergesi düştü diye başarılı ilan etmeyin; uygulama artık daha az iş yapıyor olabilir. Yükseltme düşünüyorsanız gerekli RAM, vCPU, disk ve işletim payını ayrı ayrı yazın.

Destek veya ekip kaydına olay saatini, ilgili süreç ve servis adını, kısa örnekleme sonuçlarını ve son değişikliği ekleyin. Günlüklerdeki sırları veya müşteri verilerini paylaşmayın. Bu kayıt sonraki tekrarda aynı tahminleri baştan yapmak yerine değişimin gerçekten işe yarayıp yaramadığını gösterir.