Linux sunucu performansı: eBPF, perf ve Flame Graph

[34istanblue]

Linux Sunucularda Performans Analizi: CPU Kullanımına Bakmak Neden Yeterli Değil?​

Bir Linux sunucusunda yavaşlama yaşandığında yapılan ilk işlem genellikle top veya htop açıp CPU kullanımını kontrol etmektir. CPU kullanımı düşükse sunucunun rahat çalıştığı, yüksekse işlemcinin yetersiz kaldığı düşünülür. Ancak bu yaklaşım, gerçek performans problemlerinin önemli bir bölümünü gözden kaçırabilir.

Sunucu performansını belirleyen şey yalnızca işlemcinin ne kadar çalıştığı değil, uygulamanın ihtiyaç duyduğu kaynaklara ne kadar hızlı erişebildiğidir.

Örneğin CPU kullanımı %25 seviyesinde olan bir sunucuda veri tabanı sorguları gecikebilir, disk işlemleri kuyruğa girebilir veya süreçler bellek baskısı nedeniyle bekleyebilir. Bu durumda işlemciyi yükseltmek, asıl sorunu çözmeden maliyeti artırabilir.

Bu yazıda Linux üzerinde performans darboğazlarını tespit etmek için CPU, load average, bellek, disk I/O ve Pressure Stall Information (PSI) metriklerini birlikte inceleyelim.

1. İlk hata: CPU yüzdesini tek başına yorumlamak​

İlk aşamada genel sistem durumunu aşağıdaki komutlarla inceleyebiliriz:

uptime
nproc
top

uptime, sistemin 1, 5 ve 15 dakikalık load average değerlerini gösterir. nproc, mevcut işlem ortamında kullanılabilir işlemci sayısını verir. top ise süreçlerin kaynak tüketimini ve CPU durumlarını görmemizi sağlar.

Ancak load average, doğrudan CPU kullanım yüzdesi değildir. Linux'ta bu değer, çalışmaya hazır olup CPU bekleyen süreçlerin yanında kesintisiz uyku durumundaki bazı süreçleri de kapsar. Bu nedenle yüksek load average, her zaman işlemcinin tamamen dolu olduğu anlamına gelmez.

Örneğin 8 kullanılabilir CPU bulunan bir sistemde load average değerinin 2 olması, tek başına bir performans sorunu olduğunu göstermez. Bununla birlikte CPU kısıtlamaları, disk beklemeleri ve uygulama gecikmeleri de ayrıca incelenmelidir.

Önemli nokta: Load average, CPU yüzdesi ve uygulamanın yanıt süresi farklı şeyleri ölçer. Sağlıklı teşhis için üçünü birbirinin yerine kullanmamak gerekir.

2. CPU mu, disk mi?​

CPU kullanımı düşük olmasına rağmen sunucu yavaşsa ikinci aşamada bellek ve I/O beklemelerini incelemek gerekir.

vmstat 1 10
iostat -xz 1 10

vmstat, işlem kuyruğu, bellek, swap ve sistemin CPU durumları hakkında genel bilgi verir. İlk vmstat satırı çoğu sistemde son açılıştan beri biriken ortalamaları içerdiğinden, özellikle sonraki örnekler değerlendirilmelidir.

iostat -xz, disklerin I/O davranışını daha ayrıntılı incelemeye yardımcı olur. Özellikle şu alanlar önemlidir:

• await: I/O işlemlerinin ortalama tamamlanma süresi.
• aqu-sz: Ortalama I/O kuyruğu uzunluğu.
• %util: Aygıtın I/O işlemleriyle meşgul olduğu zamanın oranı.
• r/s ve w/s: Saniyedeki okuma ve yazma işlemleri.

Bu metrikleri tek tek değerlendirmek yerine birlikte yorumlamak gerekir. Örneğin yüksek await, artan kuyruk ve uygulama gecikmesinin aynı anda görülmesi disk tarafında bir darboğaz olabileceğine işaret eder.

Bununla birlikte %util değerinin %100 olması her depolama aygıtında tek başına kesin doygunluk kanıtı değildir. Özellikle paralel I/O gerçekleştirebilen SSD ve NVMe aygıtlarında aygıtın meşguliyet oranı, gecikme ve kuyruk değerleriyle birlikte değerlendirilmelidir.

3. Bellek baskısı: RAM dolmadan da performans düşebilir​

Linux'ta kullanılan RAM miktarına bakmak tek başına yeterli değildir. İşletim sistemi dosya önbelleği için de bellek kullanır. Bu nedenle free çıktısındaki used değerini doğrudan bellek yetersizliği olarak yorumlamak doğru değildir.

free -h
vmstat 1 10

free -h çıktısında özellikle available alanı, yeni uygulamalar için ne kadar belleğin kullanılabilir olabileceğini değerlendirmeye yardımcı olur. vmstat çıktısındaki si ve so alanları ise swap giriş ve çıkış hareketlerini gösterir.

Sürekli swap hareketi, artan gecikmeyle birlikte görülüyorsa bellek baskısı ihtimali araştırılmalıdır. Ancak swap kullanılması tek başına sorun olduğu anlamına gelmez; önemli olan bu hareketin sürekliliği ve uygulama performansına etkisidir.

Bellek kaynaklı darboğazlar, büyük süreçlerin bellek tüketimi, bellek sızıntıları, gereksiz önbellek büyümesi veya sistemin yoğun bellek geri kazanımı yapması nedeniyle ortaya çıkabilir.

4. PSI: Kaynak beklemelerini ölçmek​

Linux'ta daha ileri seviye teşhis için Pressure Stall Information (PSI) kullanılabilir. PSI, CPU, bellek ve I/O kaynakları üzerindeki baskı nedeniyle işlerin ne kadar süre beklediğine ilişkin metrikler sunar.

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Çıktıda bulunan avg10, avg60 ve avg300 alanları, son 10, 60 ve 300 saniyeye ilişkin baskı ortalamalarını gösterir. some, en az bir görevin ilgili kaynak nedeniyle beklediği zaman payını ifade eder. Bellek ve I/O tarafında sunuluyorsa full, tüm etkin olmayan görevler dışındaki çalışabilir işlerin aynı anda ilgili kaynak nedeniyle durakladığı zaman payını gösterir.

PSI değerlerinin yükselmesi tek başına arızanın nedenini kanıtlamaz. Bununla birlikte uygulama gecikmesiyle aynı zaman diliminde yükselen bellek veya I/O baskısı, araştırılacak alanı önemli ölçüde daraltabilir.

PSI dosyaları her sistemde bulunmayabilir; kullanılabilirlik Linux çekirdeği yapılandırmasına ve sürümüne bağlıdır.

5. Sorun CPU kaynaklıysa: ​

CPU kullanımının yüksek olduğunu görmek, hangi kodun işlemciyi tükettiğini açıklamaz. Bunun için Linux'un performans analiz araçlarından perf kullanılabilir.

perf stat -p <PID> sleep 10

Burada <PID>, incelenecek sürecin gerçek işlem kimliğiyle değiştirilmelidir. Komut, desteklenen sayaçlar kapsamında seçilen süreç için ölçüm yapar. Kullanılabilir sayaçlar işlemciye, çekirdeğe, izinlere ve sanallaştırma ortamına göre değişebilir.

Daha ayrıntılı örnekleme için:

Bu örnekte süreç 30 saniye boyunca örneklenir ve çağrı zincirleri kaydedilmeye çalışılır. Ardından perf report üzerinden hangi fonksiyonların örneklerde öne çıktığı incelenebilir.

Burada dikkat edilmesi gereken nokta, perf çıktısının doğrudan kodun hatalı olduğunu göstermemesidir. Sık çağrılan bir fonksiyon, iş yükünün doğal bir parçası olabilir. Sonuçlar uygulamanın davranışı, çağrı zincirleri ve tekrar üretilebilir testlerle birlikte değerlendirilmelidir. Üretim ortamında profil çıkarırken ölçüm maliyeti ve izinler de hesaba katılmalıdır.

6. Darboğaz tespiti için pratik karar tablosu​

Gözlem	İlk incelenecek alan
Yüksek load average, düşük CPU kullanımı	I/O beklemeleri, kesintisiz uyku durumundaki süreçler
Yüksek CPU kullanımı ve yükselen yanıt süresi	Süreç bazlı CPU tüketimi, perf, CPU kısıtlamaları
Sürekli swap hareketi ve artan gecikme	RAM baskısı, süreçlerin bellek tüketimi
Yüksek I/O gecikmesi ve uzayan kuyruklar	Disk aygıtı, depolama katmanı ve uygulamanın I/O deseni
Düşük CPU kullanımı ama yavaş veritabanı sorguları	Disk gecikmesi, kilit beklemeleri, sorgu planı ve ağ gecikmesi
Yalnızca yoğun saatlerde ortaya çıkan yavaşlama	Eşzamanlılık, kaynak limitleri ve kapasite sınırları

Sonuç​

Linux sunucu performansını yalnızca CPU yüzdesine bakarak değerlendirmek, sistemin gerçek durumunu anlamak için yeterli değildir. Sağlıklı bir analizde CPU, load average, bellek, disk I/O, kaynak baskısı ve uygulamanın yanıt süresi birlikte ele alınmalıdır.

Benim önerdiğim yaklaşım, önce sistem genelindeki belirtileri toplamak, ardından darboğazın hangi kaynakta yoğunlaştığını belirlemek ve son olarak süreç veya kod seviyesinde ölçüm yapmaktır. Rastgele kernel parametreleri değiştirmek ya da yalnızca donanım yükseltmek yerine, önce ölçümle sorunu doğrulamak daha doğru bir yöntemdir.