Sunucu Kaynak İzleme: Darboğazı Doğru Teşhis Etmek

Neyi izlemelisiniz?

Bir web sunucusunun sağlığını büyük ölçüde dört kaynak belirler: işlemci, bellek, disk (hem doluluk hem okuma/yazma hızı) ve ağ. Bunlara ek olarak servislerin çalışıp çalışmadığını ve sitenin dışarıdan erişilebilir olup olmadığını da izlemek gerekir. İçeriden bakan ölçümler size "neden" sorusunun cevabını, dışarıdan bakan kontroller ise "kullanıcı ne görüyor" sorusunun cevabını verir. İkisi birbirinin yerine geçmez.

Aşağıdaki komutlar Linux dağıtımlarının büyük çoğunluğunda bulunur. Bazıları (örneğin htop ve iostat) ayrı paket olarak kurulur: iostat, sysstat paketinin parçasıdır ve hem apt hem dnf depolarında bu adla yer alır.

İşlemci ve yük ortalaması

uptime veya top komutunun gösterdiği üç sayı, son 1, 5 ve 15 dakikanın yük ortalamasıdır (load average). Bu değer, çalışmak için sırada bekleyen ya da kesintisiz disk işlemi bekleyen süreçlerin ortalama sayısını gösterir. Tek başına bir anlam taşımaz; çekirdek sayısıyla birlikte okunmalıdır. Çekirdek sayınızı nproc ile öğrenebilirsiniz.

• Yük, çekirdek sayısının altında ve sabitse sistem rahattır.
• Yük, çekirdek sayısını uzun süre aşıyorsa süreçler sırada bekliyor demektir.
• Yük yüksek ama işlemci kullanımı düşükse sorun büyük ihtimalle disk tarafındadır.

Son maddeyi görmek için top çıktısındaki wa (I/O wait) değerine bakın. Sanal sunucularda st (steal) değeri de önemlidir: bu oran, sanal makinenizin işlemci istediği halde fiziksel sunucudaki başka iş yükleri yüzünden bekletildiği süreyi gösterir. Sürekli yüksek bir steal değeri, kendi ayarlarınızla çözemeyeceğiniz bir durumdur; sağlayıcınızla paylaşmanız gereken bir bulgudur.

Bellek ve swap

free -h çıktısında "free" sütununun küçük olması sizi korkutmasın. Linux boş belleği disk önbelleği için kullanır ve uygulamalar istediğinde geri verir. Asıl bakmanız gereken değer available sütunudur: uygulamaların takasa düşmeden kullanabileceği tahmini bellek miktarı.

Belleğin gerçekten yetmediğini gösteren işaretler şunlardır:

• Swap kullanımının sürekli artması ve vmstat 1 çıktısında si/so sütunlarının sıfırdan farklı kalması.
• Sistem loglarında OOM killer kayıtları. Bunları dmesg veya journalctl -k çıktısında "Out of memory" ifadesini arayarak görebilirsiniz.
• Veritabanı ya da PHP süreçlerinin açıklamasız şekilde yeniden başlaması.

Bellek yetmezliğinin en yaygın sebebi, PHP-FPM'in en fazla süreç sayısının (pm.max_children) sunucunun kaldırabileceğinden yüksek ayarlanmasıdır. Ortalama bir PHP sürecinin ne kadar bellek tükettiğini ölçüp, veritabanına ve işletim sistemine pay bıraktıktan sonra kalan belleği bu değere bölmek iyi bir başlangıç noktasıdır. Web sunucusu ve PHP çalıştırma modelinin belleğe etkisini Apache, Nginx ve LiteSpeed rehberinde ele aldık.

Disk doluluğu ve disk performansı

Dolan bir disk, sitenin aniden hata vermesinin en sık ve en kolay önlenebilir sebebidir. Veritabanı yazamaz, oturum dosyaları oluşmaz, loglar kesilir. df -h bölüm doluluğunu, df -i ise inode doluluğunu gösterir. Çok sayıda küçük dosya üreten önbellek ve oturum klasörleri, disk boş görünürken inode'ları tüketebilir.

Yeri neyin kapladığını bulmak için du -xh --max-depth=1 /var | sort -h gibi bir komutla klasör klasör inebilirsiniz. Genellikle suçlular şunlardır: döndürülmeyen (rotate edilmeyen) log dosyaları, sunucuda unutulan eski yedekler, journald günlükleri ve uygulama önbellekleri. journald'nin kapladığı alanı journalctl --disk-usage ile görebilir, logrotate ayarlarınızı gözden geçirebilirsiniz.

Disk hızı için iostat -x 1 çıktısındaki kullanım yüzdesi (%util) ve bekleme süreleri fikir verir. Kullanım sürekli yüzde yüze yakınsa ve bekleme süreleri yüksekse, sunucu diske yetişemiyordur. Bu durumda önce ağır sorguları ve gereksiz yazma işlemlerini, örneğin aşırı ayrıntılı logları, arayın; ancak ondan sonra daha hızlı diske geçmeyi düşünün.

Loglar: sayıların arkasındaki hikâye

Ölçüler size bir şeylerin ters gittiğini söyler; loglar ise neyin ters gittiğini. Takılan bir servis için systemctl status servis-adi ve journalctl -u servis-adi --since "1 hour ago" ilk bakılacak yerlerdir. Web sunucusunun erişim logu, ani yükün gerçek ziyaretçilerden mi, yoksa tek bir IP'den gelen bir taramadan mı kaynaklandığını gösterir. Erişim logundan en çok istek yapan IP adreslerini çıkarmak, saldırı ile trafik artışını ayırmanın en hızlı yoludur.

Veritabanı tarafında yavaş sorgu logunu (slow query log) kısa bir süre için açmak, hangi sorgunun sunucuyu yorduğunu net biçimde gösterir. İşiniz bittiğinde kapatmayı ya da eşiği yükseltmeyi unutmayın; bu log da disk tüketir.

Sürekli izleme ve uyarılar

Komutları elle çalıştırmak, sorun anında teşhis için yeterlidir. Ama sorunun ne zaman başladığını bilmek için geçmiş veriye ihtiyaç duyarsınız. Bunun için iki katman kurun:

Uyarı eşiklerini abartmayın. Her küçük dalgalanmada gelen bildirim, kısa sürede görmezden gelinir. Disk doluluğunun yüzde 80-85'i aşması, sitenin birkaç ardışık kontrolde yanıt vermemesi ve yedek sinyalinin gelmemesi gibi gerçekten müdahale gerektiren birkaç durumla başlayın. Yedek işlerinin sinyal göndermesi konusunu sunucu yedekleme rehberinde ayrıca işledik.

Örnek teşhis: akşam saatlerinde yavaşlayan site

Bir sitenin her akşam belirli saatlerde yavaşladığını varsayalım. Elle bakmak yerine şu sırayla ilerlemek, tahmine dayalı kararları önler:

1. İzleme grafiklerinde yavaşlığın başladığı saati bulun ve aynı saatte hangi kaynağın tırmandığına bakın.
2. O saatte çalışan zamanlanmış işleri crontab -l ve systemctl list-timers ile listeleyin. Yedekleme ya da önbellek temizleme gibi işler trafikle çakışıyor olabilir.
3. Erişim logunda istek sayısının gerçekten artıp artmadığını kontrol edin. Artış tek bir kaynaktansa bot trafiğidir; geneldeyse gerçek ziyaretçidir.
4. Veritabanı yavaş sorgu logunu bir akşam boyunca açın ve en sık görünen sorguyu not edin.
5. Bulguya göre işi saatini kaydırın, sorguyu iyileştirin ya da önbellek ekleyin. Ancak bunların hiçbiri yetmezse kaynak artırın.

Bu basit sıra, çoğu durumda sorunun kaynağını ilk iki adımda ortaya çıkarır ve gereksiz bir paket yükseltmesinin önüne geçer.

Panel kullanıyorsanız işiniz biraz daha kolaydır: cPanel, Plesk ve DirectAdmin gibi paneller hesap başına kaynak kullanımını ve süreç listesini grafik arayüzde gösterir. Yine de panelin özetlediği verinin arkasındaki komutları bilmek, panelin kendisi yanıt vermediğinde sizi kurtarır. Panellerin izleme ve kaynak sınırlama özelliklerini hosting paneli sayfamızda karşılaştırdık.

Yükseltme mi, ayar mı? Karar tablosu

• CPU sürekli dolu, sorgular ve kod iyileştirilmiş: daha fazla çekirdek gerçekten fayda sağlar.
• Bellek dolu, swap artıyor: önce PHP-FPM ve veritabanı bellek ayarlarını gözden geçirin, sonra bellek ekleyin.
• I/O beklemesi yüksek: ağır sorguları ve logları inceleyin; gerekiyorsa daha hızlı disk sınıfına geçin.
• Steal sürekli yüksek: sağlayıcıya bildirin veya farklı bir plana ya da sağlayıcıya geçmeyi değerlendirin.
• Kaynaklar rahat ama site yavaş: sorun büyük ihtimalle uygulama, önbellek ya da DNS tarafındadır.

Paket yükseltme ya da sağlayıcı değiştirme kararı verirken başkalarının deneyimleri değerlidir; Sanal Sunucu bölümünde ölçüm sonuçlarınızla birlikte soru açabilirsiniz. Güvenlik tarafını henüz kurmadıysanız VPS güvenlik ayarları rehberiyle başlayın, tüm sunucu konularının özeti için sunucu yönetimi sayfasına dönün.

Forumdaki ilgili bölümler

• Sanal SunucuVPS performansı, kaynak sorunları ve paket seçimi.
• Linux Sunucularİzleme araçları, loglar ve servis sorunları.
• MySQLYavaş sorgular ve veritabanı ayarları.

Sık sorulan sorular