Linux Performans Komutları: Darboğaz Tespiti

Bir oyun sunucusu takılıyor, web uygulaması yavaşlıyor ya da VPS aniden cevap vermiyorsa, ilk işiniz "neden" sorusunu rakamlarla yanıtlamaktır. Doğru Linux performans komutları tam da bunun için var: tahmin yürütmeden, darboğazın CPU'da mı, bellekte mi, diskte mi yoksa ağda mı olduğunu birkaç saniyede gösterirler. Bu yazıda top, htop, iostat ve vmstat dörtlüsünü gerçek senaryolarla ele alıyor, ürettikleri sayıları nasıl okuyacağınızı anlatıyorum.

Önce yük ortalamasını oku: top

top neredeyse her dağıtımda hazır gelir, bu yüzden ilk bakacağınız yer odur. Çalıştırdığınızda en üstte yer alan load average satırı son 1, 5 ve 15 dakikadaki çalışmaya hazır görev sayısını verir. Pratik kural şudur: bu değeri çekirdek sayısına bölün. nproc ile çekirdek sayısını öğrenebilirsiniz; 4 çekirdekli bir makinede 4'lük bir yük yaklaşık %100 doluluk demektir.

nproc            # çekirdek sayısı
uptime           # yalnızca yük ortalaması satırı
top              # interaktif izleme

top içindeyken CPU satırındaki alanları okumak darboğazı daraltır: us kullanıcı uygulamalarının CPU'su, sy çekirdek (sistem) CPU'su, wa ise disk/IO beklemesidir. Yüksek wa değeri "CPU boşta ama diski bekliyor" anlamına gelir ve sizi doğrudan disk tarafına yönlendirir. P tuşu süreçleri CPU'ya, M tuşu belleğe göre sıralar; böylece kaynağı en çok tüketen süreci anında görürsünüz.

Daha okunaklı bir bakış: htop

htop, top'un renkli ve fareyle kullanılabilen modern halidir. Çoğu sistemde varsayılan gelmez; apt install htop ya da dnf install htop ile kurabilirsiniz. Üstteki çubuklar her çekirdeği ayrı ayrı gösterir, bu da tek bir çekirdeğin tıkandığı (tipik olarak tek iş parçacıklı süreçlerde) durumları ortaya çıkarır.

• F6 ile sıralama sütununu değiştirir, en pahalı süreci öne alırsınız.
• F4 filtreyle yalnızca ilgilendiğiniz süreci (örneğin mysqld ya da oyun sunucusu binary'si) gösterirsiniz.
• F5 ağaç görünümü, hangi ana sürecin hangi alt süreçleri doğurduğunu netleştirir.

Bellek çubuğunda yeşil kullanılan RAM, sarı ise tampon/önbellektir. Linux'un boş RAM'i önbelleğe ayırması normaldir; "RAM doldu" paniğine kapılmadan önce gerçek darboğazı swap kullanımına bakarak doğrulayın. Swap sürekli artıyorsa bellek gerçekten yetersizdir.

Disk darboğazı için: iostat

Yüksek wa gördüyseniz sıra iostat'ta. Bu araç sysstat paketinde gelir (apt install sysstat). Anlamlı veriyi anlık değil, aralıklı örneklemeyle alırsınız:

iostat -x 2      # her 2 saniyede genişletilmiş istatistik

Çıktıdaki kritik sütunlar şunlardır: %util diskin meşgul olduğu zaman yüzdesidir; sürekli %90'ın üzerindeyse disk doymuş demektir. await bir I/O isteğinin ortalama tamamlanma süresidir (ms); SSD'de tek haneli, dönen diskte onlarca ms beklenir, bunun çok üzerindeki değerler sorun işaretidir. r/s ve w/s saniyedeki okuma/yazma işlemi sayısını verir. İlk satır makinenin açılışından beri ortalama olduğu için onu yok sayın; ikinci ve sonraki satırlara bakın.

Bir veritabanı sunucusunda yüksek await ve %util görüyorsanız, ya sorgularınız diski gereksiz yere zorluyor ya da RAM yetersiz olduğu için sistem sürekli diske gidiyordur. Çözüm çoğu zaman daha hızlı disk almak değil, sorguları indekslemek ya da belleği artırmaktır.

Bütünsel resim için: vmstat

vmstat CPU, bellek, swap ve I/O'yu tek bir satırda özetlediği için "ilk teşhis" aracı olarak idealdir. Yine aralıklı çalıştırın:

vmstat 2         # her 2 saniyede özet

Okumanız gereken alanlar: r sütunu çalışmaya hazır ama CPU bekleyen süreç sayısıdır; çekirdek sayınızdan sürekli büyükse CPU darboğazınız var demektir. b kesintisiz uykuda (genellikle I/O bekleyen) süreçleri sayar. si/so saniyede diske takasa giren/çıkan bellektir; bu değerlerin sıfırdan farklı ve sürekli olması bellek baskısının kesin kanıtıdır. wa yine I/O beklemesidir. Son olarak cs (context switch) ve in (interrupt) çok yüksekse, aşırı bağlam değişimi yaratan bir yük (örneğin binlerce kısa ömürlü süreç) söz konusu olabilir.

Pratik bir teşhis akışı

Bu araçları tek tek değil, bir akış olarak kullanmak en verimli yoldur:

• Adım 1: top ya da htop ile yük ortalamasına ve hangi sürecin öne çıktığına bak.
• Adım 2: CPU mu doldu, yoksa wa mı yüksek karar ver. CPU ise süreci profille; wa ise diske geç.
• Adım 3: iostat -x 2 ile diskin doyup doymadığını (%util, await) doğrula.
• Adım 4: vmstat 2 ile swap (si/so) kullanımına bakıp bellek baskısı olup olmadığını netleştir.
• Adım 5: Ağ şüphesi varsa ss -s ve ss -tnp ile bağlantı sayısını ve hangi sürecin dinlediğini kontrol et.

Bu beş adım, "sunucu yavaş" gibi belirsiz bir şikâyeti birkaç dakika içinde "MySQL diski dolduruyor" ya da "tek çekirdek tıkanmış" gibi somut bir bulguya çevirir. Sürekli izleme için ise bu komutları temel alan Netdata veya Prometheus gibi araçlara geçebilirsiniz; ama önce manuel komutları okumayı bilmek, panellerdeki grafikleri yorumlamanızı da kolaylaştırır.

Sık Sorulan Sorular

top mu htop mu kullanmalıyım?

İkisi de aynı temel veriyi gösterir. top her yerde hazır geldiği için acil durumlarda güvenilirdir; htop ise daha okunaklı, fareyle gezilebilir ve süreç öldürme/filtreleme gibi işleri kolaylaştırır. Günlük kullanım için htop kurmanızı, ama top okumayı da bilmenizi öneririm.

Yük ortalaması kaç olursa endişelenmeliyim?

Tek bir eşik yoktur; değeri çekirdek sayısına bölün. 4 çekirdekli sistemde 4 civarı tam dolu, 8 ise iki kat fazla yük demektir. Ama yükün CPU'dan mı yoksa I/O beklemesinden mi geldiğini ayırt etmek için mutlaka wa değerine de bakın.

iostat'ın ilk satırı neden farklı görünüyor?

İlk satır, makine açıldığından beri biriken ortalamadır ve anlık durumu yansıtmaz. Gerçek davranışı görmek için iostat -x 2 gibi aralıklı çalıştırın ve ikinci satırdan itibaren okuyun.

Sunucunuz darboğazlarla mı boğuşuyor? Oyun sunucusu, VPS ya da veritabanı performansını birlikte teşhis edip kalıcı çözüme bağlayabiliriz. Benimle iletişime geçin ve sunucunuzu hızlandıralım.