Linux Sistem Performans İzleme: Araç Ekosistemi ve Tanı Senaryoları

Linux Sistem Performans İzleme: Araç Ekosistemi ve Tanı Senaryoları

Sabah 9'da müşteri arıyor: "Site yavaş." SSH ile sunucuya bağlanıyorsunuz; top açılıyor, CPU %85 kullanımı görüyorsunuz, ama hangi process'in suçlu olduğu net değil. RAM 12 GB ama free komutu sadece 200 MB gösteriyor. load average 7.5, oysa 4 vCPU'lu bir VDS'te bu yüksek. Disk doluluk %94 — fakat hangi klasör? Ağ trafiği 800 Mbps — kim çekiyor? Bu sahnenin her cümlesi için farklı bir araç vardır ve onları aynı anda kullanmayı bilen sistem yöneticisi 5 dakikada teşhis koyar; bilmeyen yarım gün debug yapar.

Bu rehber, sıradan bir "top komutu nasıl kullanılır" yazısı değil. Bir KOBİ sistem yöneticisinin günlük tanı iş akışını anlatıyor: hangi araç hangi sahnede çalışır, USE Method (Brendan Gregg) ve RED Method (Tom Wilkie) kavramları nasıl uygulanır, sysstat ile geçmiş analiz nasıl yapılır, Netdata gibi modern monitoring nasıl kurulur, ve son olarak Buyukweb VDS bağlamında bu araçların pratik kombinasyonu nasıl çalışır.

Buyukweb perspektifi: Bursa Tier 3 veri merkezimizdeki VDS E5-V4 paketlerimizde (₺250-600/ay) root erişim tam olduğu için htop, btop, iotop, iftop, nethogs, glances, atop, sysstat, Netdata gibi tüm performans araçları kurulabilir. cPanel paylaşımlı paketlerimizde (₺350-2.000/yıl) terminal erişimi var ancak sysctl ve kernel-level araçlar kısıtlıdır; "CPU and Concurrent Connection Usage" paneli ve WHM Server Status yeterlidir. 0850 302 60 70 destek hattımızdan performans tanılama desteği için bizimle iletişime geçebilirsiniz.

Performans Darboğazları: Dört Temel Eksen

Bir Linux sunucusunda performans sorunu ancak dört kaynaktan birinden kaynaklanır: CPU, Memory (RAM), Disk I/O, Network. Bu rehberde her eksen için spesifik araçları işliyoruz; sysctl/PHP-FPM/MariaDB tuning gibi derinlemesine optimizasyon konularını ise sunucu optimizasyon rehberimizde bulabilirsiniz.

Eksen	Tipik Belirti	İlk Bakılacak Araç	Detay Araç
CPU	%100 sürekli, fan/sıcaklık uyarısı	top, htop	mpstat, turbostat, perf top
Memory	OOM Killer log, swap yoğun	free -h, htop	vmstat 1, smem, slabtop, pmap -X
Disk I/O	Yüksek load avg + düşük CPU	iotop, iostat	pidstat -d, sar -d, blktrace
Network	Bandwidth alarmı, paket kaybı	iftop, nethogs	nload, iptraf-ng, ss -s, tcpdump

Burada her kategoriyi ayrıntılı işliyoruz; spesifik darboğaz türlerine göre derinlemesine tuning için: Linux Süreç Yönetimi (ps/top/htop/kill/systemctl), Sunucu Performans Optimizasyonu (sysctl/PHP-FPM/MariaDB), VDS Monitoring Karşılaştırması (Netdata/Zabbix/Prometheus), Ağ İzleme ve Bandwidth Yönetimi.

Genel TUI Dashboard Araçları: top'tan btop'a Evrim

CPU, RAM ve process listesini tek ekranda gösteren "dashboard" araçlar, sistem yöneticisinin ilk reaksiyondur. Bu kategoride dört kuşak araç vardır:

top — Klasik

top, neredeyse her UNIX/Linux dağıtımında varsayılan kuruludur. Renksiz, klavye kısayolları sınırlı, ama her zaman çalışır.

top                    # interaktif aç
top -b -n 1            # batch mode, tek snapshot (script için)
top -u www-data        # belirli kullanıcının process'leri
top -p 1234,5678       # belirli PID'leri izle
top -H -p ${PID}       # thread'leri göster

İnteraktif klavye kısayolları:

• P — %CPU'ya göre sırala
• M — %MEM'e göre sırala
• T — TIME'a göre sırala (toplam CPU kullanımı)
• 1 — CPU başına detay göster (multi-core'da kritik)
• c — komut yolu/argüman tam göster
• H — thread görünümü aç/kapa
• k — PID'e kill sinyali gönder (interaktif soracak)
• r — PID'e renice (öncelik değiştir)

top'un sınırı: tek ekran, klasik renksiz görünüm, üzerinde uzun süre çalışmak yorucu.

htop — Modern Standart

htop, top'un renkli, mouse-destekli, daha okunabilir modern halidir. Çoğu sistem yöneticisinin günlük tercihi.

# Ubuntu/Debian
apt install -y htop

# AlmaLinux/RHEL
dnf install -y htop

# Çalıştır
htop

htop avantajları:

• Renkli CPU/RAM bar (her core ayrı)
• Mouse ile tıkla-seç
• F5 ile process tree görünümü
• F6 ile sıralama sütunu seç
• F9 ile kill (sinyal seçimli)
• F10 ile çıkış
• / ile process araması
• t ile tree mod aç/kapa
• H ile thread görünümü

Kaynak tüketimi: htop saniyede ~%1 CPU tüketir, kabul edilebilir. Ancak htop 24/7 açık tutulursa yıllık ölçekte fark eder; uzun süreli izleme için terminal'i kapatıp atop veya Netdata'ya geçin.

btop / btop++ — Yeni Nesil TUI

btop (resmi adı btop++, C++ ile yeniden yazılmış), 2021'den beri yaygınlaşan modern bir TUI dashboard. Renkli graphlar, mouse destek, ağ ve disk panelleri tek ekranda.

# Ubuntu 22.04+
apt install -y btop

# AlmaLinux 9 (EPEL)
dnf install -y epel-release
dnf install -y btop

# Çalıştır
btop

btop görsel olarak htop'a göre çok daha "sexy"; CPU/RAM/Network/Disk hepsi tek ekranda animasyonlu grafikle gözükür. Düşük yan etkili, modern terminal (kitty, alacritty, Windows Terminal) ile mükemmel görünür.

atop — History + Replay (Forensic)

atop (Advanced top) en güçlü ve en az bilinen aletlerden biridir. Sürekli arka planda çalışır, 10 dakikalık örneklemeler ile tüm sistem aktivitesini binary log dosyasına yazar. Sonra "geçmişte ne oldu" diye replay edebilirsiniz.

# Kurulum
apt install -y atop          # Ubuntu/Debian
dnf install -y atop          # AlmaLinux/RHEL

# Daemon olarak başlat (sürekli log)
systemctl enable --now atop

# Anlık görüntü
atop

# Log dosyasından replay (örn. dün 14:00)
atop -r /var/log/atop/atop_$(date -d yesterday +%Y%m%d)
# Sonra 'b' tuşu ile saat 14:00'a sıçra, 't' ile ileri/'T' geri

atop avantajı: sabah 3'te crash olan sunucuyu sabah 9'da incelediğinizde, kritik saat aralığını dakika dakika geçmişe gidebilirsiniz. CPU/RAM/disk/network/per-process verisinin hepsi bir log'da.

Disk maliyeti: atop binary log günde ~5-20 MB tutar; aktif sunucuda daha fazla. /var/log/atop/ boyutunu izleyin, retention ayarını /etc/default/atop veya /etc/sysconfig/atop üzerinde değiştirin (varsayılan 28 gün).

glances — Python ile Çok Modlu Dashboard

glances (Python tabanlı), tek bir komutla CPU, RAM, disk, network, sensors, docker container, process listesi — her şeyi tek ekranda gösterir. Webserver mode (glances -w) ile tarayıcıdan da bakılabilir.

# Kurulum
pip install glances           # PyPI üzerinden
# veya
apt install -y glances        # Ubuntu/Debian
dnf install -y glances        # AlmaLinux/RHEL

# Çalıştır (terminal mode)
glances

# Web mode — tarayıcı 0.0.0.0:61208
glances -w

# Server-client mode (uzak sunucudan)
glances -s -B 0.0.0.0       # sunucuda server
glances -c remote-host.com  # client makinede bağlan

glances özellikle birden fazla sunucuyu merkezi takip için pratiktir. Ancak Netdata gibi daha güçlü self-host monitoring araçlarına göre veri tarihçesi tutmaz; canlı snapshot odaklıdır.

dstat — Tek Komutta Her Şey

dstat (Python tabanlı), vmstat + iostat + netstat + diğer sysstat araçlarının yerine geçen "tek komutla her şey" aracıdır. Sütun bazlı satır akışı şeklinde gösterir, log'a basmak için ideal.

apt install -y dstat
dnf install -y pcp-system-tools     # Modern AlmaLinux/RHEL (pcp-dstat)

# Genel CPU/disk/net/system
dstat -cdngy 2 60        # 2 sn aralık, 60 örnek

# Sadece CPU + top process
dstat -tc --top-cpu

# Disk I/O + top I/O process
dstat -td --top-io

dstat çıkışı kolayca CSV'ye yönlendirilip script ile işlenebilir; basit alerting/raporlama için pratik.

CPU Detay Araçları

Genel dashboard CPU %85 gösterdi; "hangi core, hangi tip yük (user/sys/wait), neden yüksek frekansta değil" sorularına detay araçlar cevap verir.

mpstat (sysstat paketi)

mpstat her CPU çekirdeğinin per-core breakdown'unu verir: user, system, iowait, idle, irq vb.

apt install -y sysstat
dnf install -y sysstat

mpstat                      # tüm CPU'lar toplu
mpstat -P ALL               # her core ayrı satır
mpstat 1 5                  # 1 sn aralık, 5 örnek
mpstat -P 0,1 2 10          # sadece core 0 ve 1, 2 sn aralık 10 örnek

Tipik sorun teşhisi: mpstat -P ALL çıkışında tek core %100, diğerleri %5 ise — uygulama tek thread çalışıyor (klasik PHP, Node.js single-process). Yatay ölçeklendirme veya multi-process yapı gerekir.

turbostat

turbostat (Intel'in aracı), CPU frekans, turbo state, C-state (idle power state), enerji tüketim gibi düşük-seviye verileri gösterir.

# Kernel-tools paketinde gelir
apt install -y linux-tools-common linux-tools-generic
dnf install -y kernel-tools

# Çalıştır (root gerekir)
turbostat --interval 5

VDS müşterilerinde turbostat genelde host'un izinlerine bağlıdır; bare-metal sunucuda her zaman çalışır. CPU frekansının throttle olup olmadığını anlamak için kritik araç.

perf top

perf Linux'un native profiler'ı; CPU'da en çok zaman geçiren fonksiyonları (kernel + user-space) gösterir.

apt install -y linux-tools-common linux-tools-generic
dnf install -y perf

perf top                      # canlı en çok zaman alan fonksiyonlar
perf top -p ${PID}            # belirli process
perf record -F 99 -a -g -- sleep 30
perf report

perf üretim ortamında flame graph üretmek için temel araç (Brendan Gregg'in FlameGraph projesi). 99 Hz örnekleme + 30 saniye süre = düşük yük, anlamlı sonuç.

Memory Detay Araçları

RAM "boş mu, dolu mu" sorusunun cevabı Linux'ta sandığınızdan karmaşıktır. free -h çıkışında "available" sütununa bakın — yorum yapan satır odur.

free -h

free -h
              total    used    free  shared  buff/cache   available
Mem:           7.7Gi   1.2Gi   180Mi    120Mi      6.3Gi        6.1Gi
Swap:          2.0Gi      0B   2.0Gi

• used — uygulamaların gerçekten kullandığı + reclaimable olmayan
• free — şu anda hiç kullanılmayan (genelde küçüktür, korkmayın)
• buff/cache — kernel'in disk cache'i için kullandığı (uygulamaların ihtiyacı olunca anında bırakır)
• available — gerçek "kullanılabilir" — bu satıra bakın

"RAM full" diye panikleyenler için altın kural: free -h çıkışında "available" satırı toplam RAM'in %20'sinden büyükse sorun yoktur. buff/cache yüksek olması iyi haberdir — Linux RAM'i boş bırakmaz, disk önbellekleme yapar.

vmstat — Sürekli Akış

vmstat 1                    # 1 sn aralık sürekli akış
vmstat 2 10                 # 2 sn aralık, 10 satır

Önemli sütunlar:

• r — run queue (CPU bekleyen process sayısı). vCPU sayınızdan büyükse CPU darboğazı.
• b — uninterruptible sleep (genelde disk wait)
• swpd — swap kullanımı
• si/so — swap in/out (saniyede). Sıfır olmayan değer = swap'a iniyor = ciddi RAM baskısı
• bi/bo — block in/out (disk I/O)
• us/sy/id/wa — user/system/idle/iowait CPU %

wa (iowait) %20'nin üstündeyse — disk darboğaz var, CPU disk bekliyor.

slabtop — Kernel Memory

Kernel'in kendi struct'ları için ayırdığı memory'i (slab allocator) gösterir.

slabtop                     # interaktif
slabtop -o                  # bir defa, çıkış (script için)
slabtop -s c                # cache size'a göre sırala

Çok dosya işlenen sunucularda dentry ve inode_cache slab'ları RAM'in büyük kısmını alabilir; kernel zaten reclaimable olduğu için endişe etmeyin ama disk I/O baskısının kaynağını anlamak için faydalı.

pmap -X PID — Process Memory Detay

pmap -X ${PID}              # detaylı memory map
pmap -XX ${PID}             # daha fazla sütun (NUMA, vb.)

Belirli bir process'in hangi kütüphane/dosya için ne kadar bellek tüketdiğini görmek için. PHP-FPM worker, Node.js veya Java process'inin gerçek memory layout'unu okumak için.

smem — Proportional Set Size

smem, process'lerin shared library kullanımını dikkate alarak gerçek "tek başına ne kadar tüketiyor" (PSS — Proportional Set Size) hesabı yapar.

apt install -y smem
dnf install -y smem

smem -tk                    # toplam, KB
smem -k -s rss              # RSS'e göre sırala
smem -k -u                  # kullanıcı bazında özet
smem -k -P "php-fpm"        # filtrele

PHP-FPM gibi çoklu worker'lı uygulamalarda ps aux yanıltıcı olabilir (her worker'ın RSS'i shared lib'leri de sayar). smem PSS ile net bellek tüketimi sunar.

Disk I/O Araçları

Disk darboğazı en sinsi performans sorunudur; CPU boş görünür ama load avg yüksek, "wa" sütunu %30+. Process bazlı I/O'yu görmek için spesifik araçlar gerekir.

iotop — Süreç Bazlı I/O

apt install -y iotop
dnf install -y iotop

# Tüm I/O aktif process'ler
iotop

# Sadece I/O yapıyor olanlar
iotop -o

# Toplu istatistik mod
iotop -ao

# Batch mode (script için)
iotop -b -n 5 -d 2

iotop çıkışında DISK READ ve DISK WRITE sütunları anlık I/O hızıdır. Hangi process diski dövüyor? Tipik suçlular: MariaDB compaction, log rotation, backup job, malicious cryptominer.

iostat — Cihaz Bazlı

iostat                      # toplu özet
iostat -x 2 5               # detaylı, 2 sn aralık 5 örnek
iostat -xz 1                # 0 olmayan cihazlar, 1 sn aralık

Önemli sütunlar (extended mode -x):

• %util — disk meşguliyet yüzdesi. %80+ = darboğaz
• r/s, w/s — saniyede okuma/yazma operasyonu (IOPS)
• rKB/s, wKB/s — bandwidth (KB/s)
• await — request başına ortalama bekleme süresi (ms). SSD'de >10ms, HDD'de >50ms — sorun.
• avgqu-sz (yeni sürümde aqu-sz) — request kuyruğu uzunluğu

pidstat -d

pidstat (sysstat paketi), process bazlı disk istatistiği:

pidstat -d 2 10             # 2 sn aralık, 10 örnek
pidstat -d -p ALL 5         # tüm process'ler, 5 sn

iotop'a benzer ama batch friendly, scriptlemek için uygun.

sar -d (Geçmiş Analiz)

sar (System Activity Reporter, sysstat'ın parçası), 10 dakikada bir otomatik snapshot alır ve /var/log/sysstat/ altına yazar. Geçmişte ne olduğunu görmek için altın araç.

# Sysstat'ı aktifleştir
apt install -y sysstat
systemctl enable --now sysstat sysstat-collect.timer sysstat-summary.timer
# /etc/default/sysstat içinde ENABLED="true"

# Bugünün CPU geçmişi
sar -u

# Bugünün disk geçmişi
sar -d

# Belirli saat aralığı
sar -u -s 14:00:00 -e 16:00:00

# Dünün verisi
sar -u -f /var/log/sysstat/sa$(date -d yesterday +%d)

sar ile dün gece 03:42'de CPU %95 idi gibi forensic tespit yapılır.

hdparm -tT (Disk Hız Testi)

hdparm -tT /dev/sda         # buffered + cache read benchmark

Disk'in fiziksel hız limitinin sınırına yakın çalışıp çalışmadığını anlamak için. Sonuç: "150 MB/sec buffered" gibi. SSD beklediğinizden çok düşükse — RAID degraded, bad sector, ya da host'ta kontention olabilir.

Hızlı senaryo benchmark için: fio (Flexible I/O Tester) endüstri standardıdır; apt install fio sonrası 4K random read/write, sequential read/write profilleri çalıştırılabilir. VDS satın alırken bu testi yapmak network/storage SLA'sı için referans olur.

Network Araçları

Bandwidth alarmı geldi, hangi process veya hangi bağlantı çekiyor? Birden fazla araç birbirini tamamlar.

iftop — Bağlantı Bazlı Bandwidth

apt install -y iftop
dnf install -y iftop

iftop                       # default interface
iftop -i eth0               # belirli interface
iftop -n                    # DNS lookup yapma (daha hızlı)
iftop -P                    # port numarası göster

iftop, "hangi IP ile hangi yönde ne kadar trafik" sorusuna cevap verir. Bağlantı bazlı odak — process odaklı değil.

nethogs — Süreç Bazlı Bandwidth

apt install -y nethogs
dnf install -y nethogs

nethogs                     # default interface
nethogs eth0                # belirli interface
nethogs -d 2                # 2 sn refresh

nethogs, process başına gerçek zamanlı bandwidth gösterir — "kim çekiyor" sorusu için tam ihtiyaç duyduğunuz araç.

nload — Basit Bandwidth Görselleyici

apt install -y nload
dnf install -y nload

nload                       # default interface
nload eth0
nload -t 5000 -i 1024 -o 1024   # 5 sn ortalama, 1 Mbps in/out limit

nload minimal, sadece bandwidth grafiği. Bağlantı bazlı detay yok ama hızlı bir "şu an traffik durumu" için ideal.

iptraf-ng — TUI Network Monitor

apt install -y iptraf-ng
dnf install -y iptraf-ng

iptraf-ng

iptraf-ng daha eski tarz ama hala güçlü. Menüden seçim: TCP/UDP istatistik, paket boyut dağılımı, LAN station monitor, interface stats. Forensic araştırma için ek seçenek.

ss — Modern netstat

netstat artık deprecated; modern alternatifi ss (socket statistics):

ss -s                       # toplu socket istatistiği
ss -tuap                    # TCP+UDP, all, with process
ss -tunap                   # numeric (DNS lookup yok)
ss -lntp                    # listen mode, numeric, TCP, process
ss state established        # state filtreleme
ss '( dport = :443 )'       # 443 portuna bağlantılar

Sık kullanılacak: ss -lntp — hangi servis hangi portu dinliyor sorusu için. Veya ss -tn state established | wc -l — açık TCP bağlantı sayısı.

tcpdump — Paket Yakalama

# Kurulum genelde default
tcpdump -i eth0 port 80                      # port 80 trafiği
tcpdump -i eth0 host 1.2.3.4                # belirli IP
tcpdump -i eth0 -nn -s 0 -w /tmp/cap.pcap   # pcap'e yaz
tcpdump -nn -i eth0 'tcp[tcpflags] & (tcp-syn) != 0'   # SYN paketleri

SYN flood, ya da düzgün TLS handshake olmuyor gibi sorunlarda tcpdump + Wireshark açma kombinasyonu standarttır. Üretim'de -w pcap dosyaya yazıp sonra masaüstünde analiz etmek tercih edilir.

Disk Kullanımı (Doluluk)

"Disk %100 dolu" tipi alarm geldi, hangi dizin ya da hangi dosya suçlu? Boyut analizine yönelik araçlar:

df -hT

df -hT                      # human-readable, type
df -hT --total
df -i                       # inode kullanımı

df mount point bazlı; "hangi disk dolu" sorusu için ilk bakılan. inode dolu olabilir (çok küçük dosya — örn. session cache, log fragment) — df -i ile kontrol edin.

du -sh

du -sh /var/*               # /var altındaki her klasör boyutu
du -sh / 2>/dev/null         # tüm root'un toplam
du -sh /var/log/* | sort -rh | head -20     # en büyük 20 klasör

du recursive olarak boyut toplar. Yavaş ama tam liste. sort -rh ile büyükten küçüğe sıralama.

ncdu — Interactive

apt install -y ncdu
dnf install -y ncdu

ncdu /                      # root'ta interaktif gezinme
ncdu -x /                   # mount sınırını aşma

ncdu, du'nun TUI navigasyonlu versiyonu — klavye ile klasör klasör gezerek en büyük tüketiciyi 30 saniyede bulursunuz. En sevdiğimiz araçtan biri.

Process Tree Görünüm

pstree

pstree                      # tüm process tree
pstree -p                   # PID göster
pstree -p ${PID}            # belirli PID'in alt tree
pstree -u                   # kullanıcı bazında

systemd altında her process kimin alt süreci? Apache main → MPM worker → mod_php gibi hiyerarşi görmek için. Process yönetiminin derinlikleri için Linux süreç yönetimi rehberimize bakın.

ps auxf

ps auxf                     # forest mod, hiyerarşi
ps auxf --sort=-%mem | head -20  # en çok RAM tüketen 20

ps auxf aynı bilgiyi forest formatında ascii çizgilerle verir; pstree'den çok daha fazla bilgi (CPU/RAM dahil).

Log Analiz Araçları

Performans sorunu logta iz bırakır — özellikle OOM Killer, segfault, disk full, network reset gibi olaylar.

journalctl — systemd Log

journalctl -xe                          # son loglar + açıklama
journalctl -u php-fpm                   # belirli servis
journalctl -k                           # kernel
journalctl -p err                       # sadece error+
journalctl --since "1 hour ago"
journalctl --since "2026-05-11 14:00" --until "2026-05-11 16:00"
journalctl -f                           # tail -f gibi canlı
journalctl -k | grep -i "killed process"   # OOM Killer

systemd kullanan modern dağıtımlarda journalctl standarttır. Performans soruşturmasında ilk durağınızdan biri.

lnav — TUI Log Analyzer

apt install -y lnav
dnf install -y lnav

lnav /var/log/nginx/access.log
lnav /var/log/syslog /var/log/mail.log

lnav (Log Navigator), birden fazla log dosyasını zaman ekseninde merge ederek TUI'da gösterir. Renkli formatting, regex arama, SQL sorgu (!). Çoklu servisi olan sunucularda dakikalar kazandırır.

GoAccess — Web Log Analizi

apt install -y goaccess
dnf install -y goaccess

goaccess /var/log/nginx/access.log                  # TUI
goaccess /var/log/nginx/access.log -o report.html   # HTML rapor

GoAccess nginx/apache access log'unu okuyup gerçek zamanlı TUI veya HTML rapor üretir: top URL, top IP, response code, bandwidth dağılımı. WordPress veya cPanel sitelerinin trafik analizinde vazgeçilmez.

Senaryo Bazlı Tanı: Günlük Vakalar

Şimdi araç envanterinden senaryo bazlı tanı iş akışına geçiyoruz. Her vaka için: belirti → ilk komut → derin analiz → çözüm yolu.

Senaryo 1: "Sunucu Yavaş, Neden Bilmiyorum"

İlk adım — genel resim:

top                          # CPU, RAM, load avg, top process
# veya
htop                         # daha okunabilir

Bakın:

• CPU %85+ ve tek process %50+ → CPU darboğazı (Senaryo 5'e geçin)
• load avg yüksek + CPU boş → disk I/O (Senaryo 2'ye geçin)
• RAM available <%20 + swap kullanılıyor → bellek baskısı (Senaryo 3'e geçin)
• CPU/RAM normal ama yavaş → ağ veya uygulama-içi blocking (Senaryo 6'ya geçin)

Senaryo 2: "Yüksek Load Average ama CPU Boş"

uptime
# load average: 8.50, 7.20, 6.10        # 4 vCPU'lu sunucuda yüksek
top
# %CPU(s):  5.2 us,  2.0 sy,  0.0 ni, 12.0 id, 80.5 wa    # %80 iowait

wa (iowait) %20+ — disk darboğazı. Suçlu process'i bulun:

iotop -o                     # sadece I/O yapan process'ler

Çıkış örneği:

TID  PRIO  USER     DISK READ  DISK WRITE  COMMAND
3421 be/4  mysql    150.00 K/s  450.00 M/s  mysqld --datadir=/var/lib/mysql

MariaDB ağır yazma yapıyor. Bağlantı:

mysql -e "SHOW PROCESSLIST"      # uzun süreli query var mı
mysql -e "SHOW ENGINE INNODB STATUS\G"     # InnoDB darboğazı

Çözüm yolu: InnoDB buffer pool size artır, slow query optimize et — detay için sunucu optimizasyon rehberi.

Senaryo 3: "RAM Neden Bu Kadar Dolu?"

free -h
# Mem:  7.7Gi used 7.2Gi free 100Mi available 200Mi
# Swap: 2.0Gi used 1.8Gi

Available 200 MB + swap yoğun = bellek baskısı. Suçluyu bulun:

# RSS'e göre top 10
ps auxf --sort=-rss | head -10

# Veya smem ile PSS bazında
smem -k -s rss -r | head -10

# Kernel slab
slabtop -o | head -20

Tipik suçlular: PHP-FPM worker sayısı çok yüksek, MySQL/MariaDB innodb_buffer_pool_size agresif, Java/Node heap büyüdü, ya da memory leak.

OOM Killer çalıştı mı kontrol:

journalctl -k | grep -i "killed process"
# veya
dmesg | grep -i "killed process"

Çıkış varsa — RAM yetersiz, kernel zorla bir process'i kapattı. VDS RAM yükseltme veya uygulama kaynak limitleme gerekir.

Senaryo 4: "Disk %100 Dolu, Ama Nereden?"

df -hT
# /dev/sda1  ext4  100G  98G  500M  100% /

du veya tercihen ncdu ile en büyük tüketici:

# Hızlı: root'tan başla
du -sh /* 2>/dev/null | sort -rh | head -10

# Veya interactive
ncdu /

Tipik suçlular: /var/log/ rotation kapalı (PHP-FPM error.log, Apache access.log gigabaytlık), /var/lib/mysql/ ibdata1 büyümüş, /tmp temizlenmemiş upload, JetBackup snapshot eski. Inode dolu ise:

df -i
# inodes 100% used

Genelde milyonlarca küçük dosya (session cache, mail queue). find /path -type f | wc -l ile sayın.

Senaryo 5: "Hangi Process CPU Tüketiyor"

top                          # CPU'ya göre sıralı (P tuşu)
htop                         # F6 → %CPU

PID notice edin, per-thread detay:

top -H -p ${PID}             # thread bazlı

Profile (hangi fonksiyon hot):

perf top -p ${PID}           # canlı hot function
perf record -F 99 -p ${PID} -g -- sleep 30
perf report

PHP/Python/Node.js uygulamada strace kullanmayın üretim'de — process'i durdurur. Yerine perf veya py-spy (Python için), async-profiler (Java için) gibi düşük-yan-etkili profiler kullanın.

Senaryo 6: "Ağ Trafiği Yüksek, Kim Çekiyor?"

# Genel resim
nload eth0                   # toplam bandwidth grafiği

# Bağlantı bazlı
iftop -i eth0 -n -P          # hangi IP, hangi port

# Process bazlı
nethogs eth0                 # hangi process

Tipik suçlular: cron job rsync (büyük backup transfer), botnet brute-force (port 22/3306), DDoS, scrape bot, ya da meşru viral içerik.

DDoS şüphesi varsa:

ss -tn state syn-recv | wc -l                # half-open SYN sayısı
tcpdump -nn -i eth0 'tcp[tcpflags] & (tcp-syn) != 0' -c 1000

Mitigation: Cloudflare proxy aktif, iptables/firewalld rate-limit, fail2ban dinamik blok.

Senaryo 7: "Kim Port 80'i Tutuyor?"

Bir servis yeniden başlamıyor, "Address already in use" hatası:

ss -tunap | grep ':80 '
# tcp LISTEN 0 511 *:80 *:* users:(("nginx",pid=1234,fd=6))

# Veya lsof
lsof -i :80

PID'i öğrendiniz, kill veya systemctl stop ile durdurun.

Senaryo 8: "Zombi Süreçler"

ps aux | awk '$8=="Z"'           # zombie process'ler
# veya
ps -eo pid,ppid,state,comm | grep Z

Zombie'nin PID'ine kill etki etmez (zaten ölü). Parent process'i restart edin (PPID sütununa bakın). Çoğu zombie kendi başına 1-2 saniyede temizlenir; sürekli artıyorsa parent'ta wait() çağrısı eksik (uygulama bug'ı).

Senaryo 9: "OOM Killer Çalıştı Mı?"

dmesg | grep -i "killed process"
# veya
journalctl -k --since "1 hour ago" | grep -i kill

Çıkış varsa kernel bir process'i bellek yetersizliği yüzünden öldürmüş. Hangisi, ne zaman, neden? Log analizi + Senaryo 3.

USE Method (Brendan Gregg) — Sistematik Tanı

Netflix'te performans mühendisi Brendan Gregg'in popüler hale getirdiği USE Method, her resource (CPU, RAM, disk, network, vb.) için üç soru sorar:

• Utilization — kaynak ne kadar dolu çalışıyor (% — örn. CPU %85)
• Saturation — kaynak istemleri sıraya giriyor mu (queue length — örn. run queue 8)
• Errors — kaynakta hata var mı (paket kaybı, disk read error, vb.)

Resource	Utilization	Saturation	Errors
CPU	top %CPU	uptime load avg, vmstat r	mcelog (rare hardware)
Memory	free -h available	vmstat si/so swap activity	dmesg OOM
Disk I/O	iostat %util	iostat avgqu-sz	dmesg I/O errors, S.M.A.R.T
Network	nload, iftop	netstat queue, ss queue	ifconfig errors, dropped

USE Method, sistemli düşünmenizi sağlar. Bir kaynağa odaklanmadan önce diğer üç boyutu da kontrol edin.

RED Method (Tom Wilkie) — Servis Bazlı

Weaveworks'ten Tom Wilkie tarafından önerilen RED Method ise servisleri (request handling) izlemek için:

• Rate — saniyede istek sayısı (req/s)
• Errors — başarısız istek sayısı (5xx, timeout)
• Duration — istek süresi dağılımı (p50, p95, p99)

Servis	Rate	Errors	Duration
Nginx	access log + GoAccess	5xx oran	$request_time
PHP-FPM	status page + /status	error log 500	slow.log >1s
MariaDB	SHOW STATUS Queries	error_log	slow_query_log

USE ve RED birbirini tamamlar: USE altyapı kaynakları için, RED uygulama servisleri için.

Geçmiş Analiz: sysstat / sar / atop

Gerçek hayatta sorunlar genelde "iki saat önce yaşandı, ben sonradan baktım" şeklinde olur. Gerçek zamanlı izleme yetmez; geçmiş veri kritik.

sysstat / sar Kurulumu

apt install -y sysstat
# /etc/default/sysstat içinde ENABLED="true" yap
systemctl enable --now sysstat
systemctl enable --now sysstat-collect.timer    # her 10 dakika snapshot
systemctl enable --now sysstat-summary.timer    # günlük özet

# Snapshot aralığını değiştir: /etc/sysstat/sysstat (Debian/Ubuntu)
# veya /etc/sysconfig/sysstat (RHEL/AlmaLinux)

Şimdi 30 gün geriye kadar veri /var/log/sysstat/ veya /var/log/sa/ altında.

sar -u 1 3                   # canlı, son 3 örnek
sar -u                       # bugün tüm gün CPU
sar -r                       # bugün RAM
sar -d                       # bugün disk
sar -n DEV                   # bugün network
sar -u -s 14:00:00           # belirli saat aralığı
sar -u -f /var/log/sysstat/sa11   # 11. günün verisi

atop Replay

atop da arka planda log tutar, ama daha zengin (per-process kalitesi). Replay ile kritik dakikaya ulaşırsınız:

ls /var/log/atop/             # dosya isimleri tarih bazlı
atop -r /var/log/atop/atop_20260510   # 10 Mayıs'ın log'u
# 't' ile ileri/'T' geri, 'b' ile saat:dakika yaz ve atla

Otomatik Monitoring Stack — Kavramsal

Manual araçlar ad-hoc tanı için harikadır; 24/7 monitoring + alerting + tarihçe + grafik ihtiyacı için modern monitoring stack kurun. Detaylı karşılaştırma: VDS Monitoring rehberi ve Zabbix kurulum.

Netdata Self-Host (10 Dakika Kurulum)

Netdata, real-time UI + sıfır config monitoring aracı. VDS'te tek satırda kurulum:

# Resmi kurulum scripti
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

# Veya paket
apt install -y netdata
dnf install -y netdata

# Sonra tarayıcıdan
http://YOUR_VDS_IP:19999

Netdata default 1 saniye granularite ile tüm sistem metriklerini grafiğe döker. Diskte 1-3 GB tarihçe, hafif (~%2 CPU yan etki). Cloud sürümü ile çoklu sunucu merkezi izleme de mümkün.

Prometheus + node_exporter + Grafana

Endüstri standardı stack:

[node_exporter]     → her sunucuda /metrics endpoint
[Prometheus]        → 15 saniyede bir pull, time-series DB
[Grafana]           → dashboard
[Alertmanager]      → email/Slack/Telegram alert

Setup detayı uzun; KOBİ ölçeğinde Netdata daha pratik, kurumsal/çoklu sunucu için Prometheus stack standarttır. Detay: VDS monitoring rehberi.

Zabbix

Klasik kurumsal monitoring; agent-based, geniş özellik seti. Detay kurulum: Zabbix + Nagios rehberi.

Uptime Kuma

Hafif self-host status page + uptime monitoring. HTTP/HTTPS/TCP/Ping/DNS kontrol, Discord/Telegram/Slack notification, public status page. Docker tek satırda kurulur.

Alerting: Email, Discord, Slack, Telegram

Monitoring olmadan alert işe yaramaz; alert olmadan monitoring sadece güzel grafiktir.

Prometheus Alertmanager (Kavramsal)

# alertmanager.yml
route:
  receiver: 'telegram-team'

receivers:
  - name: 'telegram-team'
    telegram_configs:
      - bot_token: 'YOUR_BOT_TOKEN'
        chat_id: -100123456789

  - name: 'discord-team'
    webhook_configs:
      - url: 'https://discord.com/api/webhooks/...'

  - name: 'slack-team'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#alerts'

Alert kuralları (örnek):

# /etc/prometheus/rules.yml
groups:
  - name: system
    rules:
      - alert: HighCPU
        expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        annotations:
          summary: "CPU yuksek: {{ \$value }}%"

      - alert: DiskAlmostFull
        expr: (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 < 10
        for: 10m
        annotations:
          summary: "Disk dolmak uzere: %{{ \$value }} bos"

Basit Bash + Cron + Webhook

Prometheus stack kurmak istemiyor musunuz? cron ile basit alert:

#!/bin/bash
# /usr/local/bin/disk-alert.sh
USE=\$(df / | tail -1 | awk '{print \$5}' | sed 's/%//')
if [ "\$USE" -gt 85 ]; then
  curl -X POST -H 'Content-type: application/json' \
    --data "{\"content\":\"Disk doluluk %\$USE — buyukweb-vds\"}" \
    https://discord.com/api/webhooks/YOUR_WEBHOOK
fi

# Cron her 10 dakika
echo "*/10 * * * * /usr/local/bin/disk-alert.sh" | crontab -

Bash escape notu: Bu rehberdeki bash kod örneklerinde \$ görüyorsunuz; bu sadece dökümantasyon rendering escape'idir. Gerçek kullanımda direkt \$VAR yazın.

Performance Tuning Hatırlatma

Bu rehberin temel odağı izleme ve tanıdır; spesifik tuning (kernel, sysctl, PHP-FPM, MariaDB, OPcache) için ayrı rehberimiz: Sunucu Performans Optimizasyonu.

Hızlı hatırlatma:

• swappiness = 10 (varsayılan 60) — swap'a daha az iner
• vm.dirty_ratio / dirty_background_ratio — write buffer
• net.ipv4.tcp_tw_reuse = 1 — TIME-WAIT socket'leri yeniden kullan
• fs.file-max — max open files
• ulimit -n 65535 — process başına file descriptor
• systemd resource limit — /etc/systemd/system/SERVICE.service.d/limit.conf
• cgroups v2 — modern resource isolation

Kernel Performance Subsystem

Daha derin gözlemleme isteyenler için modern Linux'ta eBPF tabanlı araçlar standart haline geliyor. Detay konusunu burada işlemiyoruz ama farkındalık için:

perf (Native Profiler)

perf top                              # canlı hot function
perf stat -p ${PID} -- sleep 10       # CPU sayaçları (cache miss, branch, vb.)
perf record -F 99 -a -g -- sleep 30   # tüm sistem örnekleme
perf report                           # interaktif analiz

ftrace (Function Trace)

Kernel function-level trace; /sys/kernel/debug/tracing/ üzerinden manual kullanım, ya da trace-cmd aracıyla daha kolay.

eBPF / bpftrace (Modern)

apt install -y bpftrace
dnf install -y bpftrace

# Hangi syscall en yoğun
bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }'

# Process açan/kapatan
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s %s\n", comm, str(args->filename)); }'

eBPF, Brendan Gregg'in BCC toolkit'i ve bpftrace ile kernel/user-space gözlemini ezbere bilen sistem yöneticisinin başarısı çok yüksek olur.

WordPress / cPanel Bağlamı

Kurumsal müşterilerimizin çoğu cPanel paylaşımlı paketinde WordPress çalıştırır; cPanel sunduğu izleme panelleri:

CPU and Concurrent Connection Usage

cPanel ana ekranında "CPU and Concurrent Connection Usage" widget'ı son 24 saatte:

• Hesabınızın CPU kullanım % grafiği
• Eş zamanlı bağlantı sayısı grafiği
• Disk I/O grafiği
• "Faulted" sayısı — limit aşıldığında hata sayısı

Buyukweb'de bu sayılarla hesap limitini aştığınızda sistem otomatik 503 dönüyor. Trend analizi için kritik panel.

WHM Server Status (Reseller / VPS Hesap Sahipleri)

WHM'de Home → Server Status → Server Information altında:

• CPU usage
• Memory usage
• Disk usage
• Apache MPM worker durumu
• MySQL/MariaDB process listesi
• Server load average

Daha ileri için Munin veya mod_status modülü cPanel'den kurulabilir.

Server Load Average — cPanel/WHM Bağlamı

cPanel makine bazlı çalıştığı için server load average kritik metriktir. WHM'de yüksek load gözlemlenirse:

• CSF firewall stat — yoğun bağlantı kaynağı
• Top Processes by CPU — WHM widget
• Apache Status — aktif istek sayısı, request URL
• MySQL Processes — uzun süreli query

VDS'te 10 Satırlık Netdata Kurulum

VDS müşterilerimiz için pratik script:

#!/bin/bash
# Netdata + Discord alerting kurulum
set -e

bash <(curl -Ss https://my-netdata.io/kickstart.sh) --dont-wait --non-interactive

cat > /etc/netdata/health_alarm_notify.conf <<EOF
DISCORD_WEBHOOK_URL[default]="https://discord.com/api/webhooks/YOUR_HOOK"
SEND_DISCORD="YES"
EOF

systemctl restart netdata
echo "Netdata kuruldu — http://\$(hostname -I | awk '{print \$1}'):19999"

10 dakikada self-host monitoring + alerting çalışır halde.

8 Yaygın Hata

Sistem yöneticilerinin sık karşılaştığımız tipik hataları:

1. Sadece top'a Bakmak

top genel resim verir ama: per-thread, per-core, network, disk gibi detayları göstermez. htop + iotop + iftop + nethogs kombinasyonu öğrenin.

2. htop 24/7 Açık Bırakmak

Saniyede ~%1 CPU az gibi gelir; ancak terminal session'da uzun süreli izlemenin yeri yoktur. Netdata + alerting kurun; htop sadece tanı için açın.

3. vmstat 1 Sonsuz Açık Bırakmak

vmstat 1 veya dstat 1 sürekli çalışırsa terminal scroll buffer'ı dolar, RAM tüketir, ve hiç kullanılmayan veri üretir. Belirli süre veya batch mode kullanın (vmstat 1 60).

4. strace Üretim Ortamında

strace process'in her syscall'unu yakalar — process'i 10-100x yavaşlatır. Üretim sunucusunda PHP-FPM worker'ına strace eklerseniz uygulama durur. perf, bpftrace, py-spy gibi düşük-yan-etkili alternatif kullanın.

5. "Load Avg 5 = 5 Process" Yanılgısı

Load average run queue + uninterruptible sleep'tedir. 4 vCPU'lu sunucuda load avg 5 → 1 process kuyrukta bekliyor, geri kalan 4 vCPU'da çalışıyor. Load avg'ı vCPU sayısına oranlayın: load_avg / vCPU > 1.0 ise darboğaz.

6. Disk /var/log Dolup Sunucu Çakıldıktan Sonra Fark Etmek

/var/log rotation kapalı, MariaDB ibdata growing, PHP-FPM error.log gigabaytlık. logrotate config'i mutlaka kontrol edin; du -sh /var/log/* haftalık check.

7. cPanel Hesap Limit Faulted Sayısını Görmezden Gelmek

cPanel'in "Faulted" sayısı her ay artıyor mu? Paketinizin limiti yetmiyor — paket upgrade veya VDS'e geçiş düşünün. Faulted = müşteri 503 görüyor demektir, dönüşüm kaybeder.

8. Monitoring Kurmuş Ama Alert'siz Bırakmak

Grafana grafiği güzel ama kimse 24/7 bakmaz. Alertmanager + Discord/Slack/Telegram webhook kurmadığınız her monitoring sistemi yarı doğmuş.

Sık Sorulan Sorular (SSS)

"Top yerine ne kullanmalıyım?"

Klasik kullanım için top yeterli — her sunucuda kurulu, sıfır kurulum yükü. Daha okunabilir günlük kullanım için htop, modern UI sevenler için btop, geçmiş replay için atop. Tek bir araç değil, durum bazlı kombinasyon kullanın. Her terminal session'ında htop açık yerine, kısa süreli tanı + Netdata uzun süreli izleme idealdir.

"Netdata ücretsiz mi? Self-host versiyonu yetiyor mu?"

Netdata Agent tamamen açık kaynak ve ücretsiz. Tek başına bir VDS'i monitör etmek için sınırsız kullanılabilir. Çoklu sunucu merkezi izleme için Netdata Cloud ücretsiz tier (5 node'a kadar) mevcut; üzeri için ücretli plan var ama self-host multiple node da elle yapılabilir. Yani çoğu Buyukweb VDS müşterisi tamamen ücretsiz kapsamda kalır.

"cPanel paylaşımlı paketimde bu araçlar çalışır mı?"

cPanel'de SSH erişimi var ancak jailed shell olabilir; top, htop, ps aux, du, df, free, basit netstat çalışır. iotop, iftop, nethogs, tcpdump, perf, bpftrace gibi root gerektiren araçlar paylaşımlı'da çalışmaz. Kurumsal/gelişmiş tanılama için VDS gereklidir.

"Production'da strace kullanmak güvenli mi?"

Hayır. strace syscall yakalama yaparken process'i durdurup-başlatır; bu üretim PHP-FPM/MariaDB process'ini 10-100x yavaşlatır. Asla canlı kullanıcı isteklerini handle eden process'e strace eklemeyin. Yerine: perf, bpftrace, py-spy (Python), async-profiler (Java) kullanın — yan etkisi minimal.

"Load average ile CPU% arasında ne fark var?"

CPU% anlık çalışma yüzdesidir (örn. %85). Load average ise run queue + uninterruptible sleep'tedir — 1/5/15 dakika ortalamasıdır. CPU %20 ama load avg 8 ise — process'ler disk I/O bekliyor (D state). Her ikisini birlikte yorumlayın.

"Bir VDS'e hangi araçları kurmamı önerirsiniz?"

İlk gün kurulum: htop, iotop, iftop, nethogs, ncdu, sysstat, atop, glances, lnav. Kurulum sonrası Netdata ile self-host monitoring. Bu kombinasyon %95 vakanın hepsini kapsar. eBPF/bpftrace ilerideki ihtiyaca göre eklenebilir.

"Saatte 1.000 ziyaretçi alan WP sitesi VDS'de hangi metrikleri 24/7 izlemeliyim?"

CPU < %80, RAM available > %20, disk < %85 dolu, load avg < vCPU sayısı, MariaDB query < 100ms p95, Nginx 5xx < %1, response time p95 < 1 saniye. Bu altıyı Netdata + Alertmanager (veya basit bash + cron + Discord webhook) ile 24/7 alert kurun.

"Backup ve monitoring aynı sunucuda olabilir mi?"

Backup deposu kesinlikle ayrı bir disk/sunucu olmalı; ama monitoring agent (Netdata) ana sunucuda yan bir servis olarak çalışır. Merkezi monitoring (Prometheus/Zabbix sunucusu) ayrı bir VDS'te en doğrusu — bir sunucu çöktüğünde uyarı alabilmek için.

Sonuç ve Sonraki Adımlar

Linux performans izleme tek bir aracın işi değil; bir araç ekosisteminin pratik kullanımıdır. Bu rehberi özetlemek gerekirse:

1. Genel resim → htop (modern) veya btop (sexy UI)
2. Per-thread/CPU detay → mpstat, perf top, turbostat
3. Bellek detay → free -h, vmstat, smem, slabtop
4. Disk I/O → iotop -o, iostat -x, sar -d
5. Network → iftop, nethogs, ss -tunap, tcpdump
6. Disk doluluk → df -hT, ncdu, du -sh
7. Process tree → pstree, ps auxf
8. Geçmiş analiz → sysstat (sar), atop -r
9. 24/7 monitoring → Netdata, Prometheus, Zabbix
10. Alerting → Alertmanager, basit bash + cron + Discord/Slack/Telegram webhook

USE Method (Brendan Gregg) ve RED Method (Tom Wilkie) sistemli tanı için temel framework. eBPF / bpftrace modern observability'nin geleceği — bilmenizde fayda var.

Buyukweb müşterilerimiz için pratik öneri: VDS satın aldığınız ilk gün htop + iotop + iftop + nethogs + ncdu + sysstat + atop + glances + Netdata paketini kurun. Bu kurulum 20 dakika alır ve hayat kurtarır.

---

İlgili Büyükweb Hizmetleri

• VDS Sunucu — Root erişim, tüm performans aracı kurulabilir, Bursa Tier 3 datacenter
• cPanel Web Hosting — CPU/Connection panel + WHM Server Status entegre
• Linux Süreç Yönetimi — ps/top/htop/kill/systemctl detay
• Sunucu Performans Optimizasyonu — sysctl, PHP-FPM, MariaDB tuning
• VDS Monitoring Karşılaştırması — Netdata vs Zabbix vs Prometheus seçim rehberi
• Zabbix Kurulum Rehberi — Kurumsal monitoring detay
• Ağ İzleme ve Bandwidth — Bandwidth, iftop, Zabbix network derinlemesine

Linux performans tanılama, modern monitoring stack kurulumu (Netdata/Prometheus), VDS optimizasyonu desteği için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden 7/24 izlenen VDS altyapısı sağlıyoruz.