Yüksek Gecikme Sorunları: Kaynak Tespiti ve Optimizasyon
Ağ gecikme sorunları, sysadmin hayatının en sinir bozucu problemlerinden biridir. Kullanıcılar “sistem çok yavaş” diye şikayet ediyor, siz de saatlerce ekrana bakıyorsunuz. Asıl sorun şu: gecikme (latency) tek bir kaynaktan gelmez. Ağ altyapısı, sunucu kaynakları, uygulama katmanı, hatta DNS çözümlemesi bile suçlu olabilir. Bu yazıda, yüksek gecikme sorunlarını sistematik şekilde nasıl tespit edeceğinizi ve optimize edeceğinizi gerçek dünya senaryolarıyla anlatacağım.
Gecikme Nedir ve Neyi Ölçüyoruz?
Gecikme, basitçe bir paketin kaynaktan hedefe ulaşma süresidir. Ama işin içine girince çok daha karmaşık bir tablo ortaya çıkıyor. RTT (Round Trip Time), TTFB (Time to First Byte), jitter gibi kavramları birbirinden ayırt etmek, sorunu doğru katmanda aramak için kritiktir.
Gerçek bir senaryoyla başlayalım: Şirket içi bir uygulama sunucusuna bağlanan kullanıcılar, sabah 09:00-11:00 arasında ciddi yavaşlama yaşıyor. Öğleden sonra sorun kayboluyor. Bu pattern bize çok şey söylüyor: saatlik yoğunlukla bağlantılı, muhtemelen ağ veya CPU kaynaklı.
Temel Tanılama: Nereden Başlamalı?
Ping ile İlk Kontrol
En basit araçtan başlıyoruz ama ping’i doğru kullanmak önemli:
# Standart ping - paket kaybı ve RTT
ping -c 100 -i 0.2 hedef-sunucu.local
# Flood ping (root gerektirir) - anlık congestion testi
ping -f -c 1000 hedef-sunucu.local
# Paket boyutu değiştirerek MTU sorunlarını test et
ping -s 1472 -M do hedef-sunucu.localBurada -s 1472 kullanmamızın sebebi, 1472 byte + 28 byte IP/ICMP header = 1500 byte, yani standart Ethernet MTU değeri. Eğer bu paket iletilmiyorsa MTU sorunu var demektir.
Traceroute ile Yolu İzleme
Ping sonuçları kötüyse, sorunun tam olarak nerede olduğunu bulmak için traceroute kullanıyoruz:
# Linux traceroute - UDP kullanır
traceroute -n hedef-sunucu.com
# ICMP tabanlı traceroute (bazı firewall'ları daha iyi geçer)
traceroute -I -n hedef-sunucu.com
# TCP tabanlı - web sunucularını test için ideal
traceroute -T -p 443 -n hedef-sunucu.com
# MTR - gerçek zamanlı, traceroute + ping kombinasyonu
mtr --report --report-cycles 100 hedef-sunucu.comMTR benim favori araçlarımdan biridir. Tek ekranda hem hop’ları hem de her hop’taki paket kaybı ve gecikme istatistiklerini görürsünüz. 100 döngü toplayarak çalıştırmak, anlık değil ortalama değer elde etmenizi sağlar.
Katman Katman Analiz
Ağ Katmanı Sorunları
Eğer MTR çıktısında belirli bir hop’tan sonra gecikme dramatik şekilde artıyorsa, sorun o noktadadır. Ama dikkat: bazı router’lar ICMP paketlerine düşük öncelik verdiği için yanlış yüksek gecikme görebilirsiniz. Sonraki hop’lar normal görünüyorsa, o hop sorunlu değildir.
Gerçek senaryo: Bir müşterinin CDN’e bağlantısında 200ms+ gecikme vardı. MTR çıktısı 8. hop’ta spike gösteriyordu ama 9. ve 10. hop’lar normaldi. Bu klasik ICMP rate-limiting durumuydu. Asıl sorun değildi.
# Belirli bir interface'in istatistiklerini izle
watch -n 1 'cat /proc/net/dev | grep eth0'
# SS ile socket istatistiklerini gör
ss -s
# Ağ interface hatalarını kontrol et
ip -s link show eth0
# Ethtool ile interface sorunlarına bak
ethtool -S eth0 | grep -i errorethtool -S çıktısında rx_errors, tx_errors, rx_dropped gibi değerlerin artıyor olması ciddi bir problem işaretidir. Bu değerler sıfırdan büyükse ve artmaya devam ediyorsa, kablo sorunu, duplex uyuşmazlığı veya donanım problemi olabilir.
TCP Bağlantı Sorunları
Yüksek gecikmenin kaynağı bazen TCP’nin kendisidir. Nagle algoritması, TCP buffer boyutları ve congestion control mekanizmaları gecikmeye doğrudan etki eder:
# Mevcut TCP bağlantılarının durumunu gör
ss -tnp | grep ESTAB
# TCP yeniden iletimlerini izle
netstat -s | grep -i retransmit
# Gerçek zamanlı TCP istatistikleri
watch -n 2 'netstat -s | grep -E "retransmit|failed|reset"'Eğer retransmit sayısı sürekli artıyorsa, ağda paket kaybı var demektir. Paket kaybı, TCP’yi yeniden iletim yapmaya zorlar ve bu gecikmeyi katlar.
Linux Kernel Ağ Parametrelerinin Optimizasyonu
TCP Buffer ve Queue Ayarları
Yüksek gecikmeli veya yüksek bant genişlikli ağlarda (WAN bağlantıları, uzak veri merkezleri arası), TCP buffer’larını artırmak ciddi fark yaratır:
# Mevcut değerleri kontrol et
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
# Geçici olarak uygula (test için)
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"Kalıcı hale getirmek için /etc/sysctl.conf veya /etc/sysctl.d/99-network-tuning.conf dosyasına ekleyin:
cat >> /etc/sysctl.d/99-network-tuning.conf << 'EOF'
# TCP buffer optimizasyonu
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
# Bağlantı kuyruğu optimizasyonu
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
# TCP Fast Open aktif et
net.ipv4.tcp_fastopen = 3
# BBR congestion control (kernel 4.9+)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl -p /etc/sysctl.d/99-network-tuning.confBBR (Bottleneck Bandwidth and Round-trip propagation time) Google tarafından geliştirilen modern bir congestion control algoritmasıdır. Özellikle yüksek gecikmeli WAN bağlantılarında CUBIC’e göre çok daha iyi performans gösterir. Desteklenip desteklenmediğini kontrol etmek için:
# Kullanılabilir congestion control algoritmalarını listele
sysctl net.ipv4.tcp_available_congestion_control
# BBR aktif mi kontrol et
sysctl net.ipv4.tcp_congestion_controlUygulama Katmanı Gecikmesi
Ağ tamamen sağlıklı görünüyor ama gecikme hala yüksekse, sorun uygulamanın kendisindedir.
DNS Gecikmesi
DNS çözümlemesi gözardı edilen ama ciddi gecikme kaynağıdır. Özellikle mikro-servis mimarilerinde, her servis çağrısı DNS sorgusu yapıyorsa bu birikir:
# DNS sorgu süresini ölç
time dig @8.8.8.8 hedef-domain.com
# Detaylı DNS trace
dig +trace hedef-domain.com
# Yerel DNS cache durumu (systemd-resolved)
resolvectl statistics
# DNS yanıt sürelerini izle
dig +stats hedef-domain.com | grep "Query time"Bir projede uygulama sunucusundaki her API çağrısının 300-400ms sürdüğünü bulduk. Network trace alınca görüldü ki her çağrı öncesinde 200ms+ DNS sorgusu yapılıyordu ve DNS cache düzgün çalışmıyordu. /etc/nsswitch.conf dosyasında dns önce geliyordu, files sonra. Bunu düzelttikten ve yerel DNS cache aktif edildikten sonra gecikme 50ms’nin altına düştü.
Uygulama Performans Analizi
Web uygulamalarında TTFB (Time to First Byte) gecikmesi için:
# curl ile detaylı zamanlama
curl -w "nnDNS Lookup: %{time_namelookup}snTCP Connect: %{time_connect}snTLS Handshake: %{time_appconnect}snTTFB: %{time_starttransfer}snTotal: %{time_total}sn"
-o /dev/null -s https://hedef-uygulama.com/api/endpoint
# Birden fazla istek ortalaması almak için
for i in {1..10}; do
curl -w "%{time_total}n" -o /dev/null -s https://hedef-uygulama.com/
done | awk '{sum+=$1; count++} END {print "Ortalama:", sum/count, "saniye"}'Bu curl format stringi altın değerindedir. DNS’ten TLS handshake’e kadar her adımın süresini ayrı ayrı gösterir. Gecikmenin tam olarak hangi adımda olduğunu birkaç saniyede anlarsınız.
Sistem Kaynaklarının Gecikmeye Etkisi
CPU ve I/O Beklemesi
Ağ tamam, uygulama da tamam görünüyor ama hala gecikme var? Sistem kaynakları tıkanmış olabilir:
# Genel sistem yükü ve CPU I/O wait
iostat -x 1 10
# Hangi process en fazla I/O yapıyor
iotop -o -d 1
# CPU beklemesini detaylı izle
mpstat -P ALL 1 5
# Gerçek zamanlı sistem durumu
vmstat 1 10vmstat çıktısında wa (I/O wait) sütununa dikkat edin. Bu değer sürekli 20-30’un üzerindeyse, disk I/O darboğazı var demektir ve bu doğrudan ağ yanıt sürelerine yansır. Sunucu ağ paketine yanıt vermeden önce disk işlemini bekliyor olabilir.
IRQ Affinity ve Ağ Performansı
Yüksek trafikli sunucularda, ağ kartı kesmeleri (interrupts) tek bir CPU çekirdeğine yığılırsa ciddi gecikme yaşanır:
# IRQ dağılımını kontrol et
cat /proc/interrupts | grep -E "eth|eno|ens"
# CPU başına interrupt sayısını izle
watch -n 1 'cat /proc/interrupts | grep eth0'
# IRQ affinity ayarla (eth0 için IRQ numarasını bul)
IRQ=$(cat /proc/interrupts | grep eth0 | awk '{print $1}' | tr -d ':')
echo "f" > /proc/irq/$IRQ/smp_affinity # Tüm CPU'lara dağıtBunu daha doğru yapan araç irqbalance‘dır. Çoğu dağıtımda kurulu gelir ama aktif olup olmadığını kontrol edin:
systemctl status irqbalance
systemctl enable --now irqbalancePratik Senaryo: Veritabanı Bağlantı Gecikmesi
En sık karşılaştığım senaryo: uygulama sunucusu ile veritabanı arasında yüksek gecikme. Şirketteki bir projede PostgreSQL sorgularının 5-10ms olması gerekirken 150-200ms sürdüğünü bulduk.
Adım adım analiz:
# 1. Önce ağ gecikmesini kontrol et
ping -c 50 db-sunucu.local
# Sonuç: 0.3ms - ağ tamam
# 2. TCP bağlantı süresini ölç
time nc -zv db-sunucu.local 5432
# Sonuç: 1ms - bağlantı tamam
# 3. PostgreSQL'e bağlanıp basit sorgu süresi
time psql -h db-sunucu.local -U appuser -c "SELECT 1;"
# Sonuç: 180ms - problem burada
# 4. pg_stat_activity ile neyin beklediğine bak
psql -h db-sunucu.local -U postgres -c
"SELECT pid, wait_event_type, wait_event, state, query
FROM pg_stat_activity
WHERE state != 'idle';"Sonuç ilginçti: wait_event_type: Client ve wait_event: ClientRead görüyorduk. Uygulama sunucusu sorguyu gönderip yanıt beklerken beklenmedik gecikmeler yaşanıyordu. Daha derine inince anladık: uygulama her sorgu için yeni TCP bağlantısı açıyordu ve bu bağlantı kurulum maliyeti 150ms’ye mal oluyordu. Connection pooling (PgBouncer) ekleyince sorun tamamen çözüldü.
Monitoring ve Alerting Kurulumu
Gecikme sorunlarını reaktif değil proaktif yakalamak için monitoring şart. Basit ama etkili bir script:
#!/bin/bash
# latency-monitor.sh - Kritik servisleri izle ve alert ver
HEDEFLER=("web-sunucu.local:80" "db-sunucu.local:5432" "cache-sunucu.local:6379")
ESIK_MS=100 # ms cinsinden eşik değeri
LOG_DOSYA="/var/log/latency-monitor.log"
for hedef in "${HEDEFLER[@]}"; do
HOST=$(echo $hedef | cut -d: -f1)
PORT=$(echo $hedef | cut -d: -f2)
# TCP bağlantı süresini ölç (ms cinsinden)
SURE=$(( TIMEFORMAT='%R'; { time nc -zw1 $HOST $PORT 2>/dev/null; } ) 2>&1 |
awk '{print $1 * 1000}')
ZAMAN=$(date '+%Y-%m-%d %H:%M:%S')
if (( $(echo "$SURE > $ESIK_MS" | bc -l) )); then
echo "$ZAMAN UYARI: $HOST:$PORT gecikme ${SURE}ms (eşik: ${ESIK_MS}ms)" | tee -a $LOG_DOSYA
# Buraya mail/Slack notification eklenebilir
else
echo "$ZAMAN OK: $HOST:$PORT gecikme ${SURE}ms" >> $LOG_DOSYA
fi
doneBu scripti crontab’a ekleyerek her dakika çalıştırabilirsiniz:
# Crontab'a ekle
echo "* * * * * /usr/local/bin/latency-monitor.sh" | crontab -Windows Tarafında Gecikme Analizi
Windows sunucularda da benzer sorunlar yaşanır. PowerShell ile hızlı analiz:
# Test-NetConnection ile detaylı ağ testi
Test-NetConnection -ComputerName hedef-sunucu -Port 443 -InformationLevel Detailed
# Traceroute Windows'ta
tracert -d hedef-sunucu.com
# pathping - hem traceroute hem ping
pathping -n hedef-sunucu.com
# Ağ adapter istatistikleri
Get-NetAdapterStatistics | Select-Object Name, ReceivedDiscardedPackets, OutboundDiscardedPacketsWindows’ta sık gözden kaçan bir sorun: TCP Chimney Offload ve RSS (Receive Side Scaling) ayarları. Bazı eski driver’larla bu özellikler performans sorunu çıkarabilir. Kontrol için:
# Network offload ayarlarını kontrol et
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -like "*RSS*"
# Sorun yaratıyorsa devre dışı bırak (test ortamında dene)
Disable-NetAdapterRss -Name "Ethernet"Sonuç
Yüksek gecikme sorunları sabır ve sistematik yaklaşım gerektiriyor. Özetleyecek olursam:
- Önce ölç, sonra hareket et: Elinizde sayısal veri olmadan optimizasyon kör uçuştur. ping, mtr, curl timing formatları başlangıç noktanız olsun.
- Katmandan katmana ilerle: Ağ fiziksel katman, TCP, DNS, uygulama, sistem kaynakları sırasıyla kontrol edin. Sorunu doğru katmanda bulmadan yapılan her değişiklik zaman kaybıdır.
- Tek değişken prensibi: Aynı anda birden fazla şeyi değiştirmeyin. Neyin işe yaradığını anlayamassınız.
- Baseline oluştur: Sistem sağlıklıyken referans değerler toplayın. Sorun çıkınca neyle karşılaştıracağınızı bilesiniz.
- BBR ve modern TCP ayarları: Yüksek gecikmeli WAN bağlantılarında BBR congestion control ve optimized buffer ayarları gerçek fark yaratır.
- DNS’i küçümseme: Gecikmenin önemli bir kısmı DNS’ten geliyor olabilir. Her zaman ölçün.
Her gecikme sorunu farklıdır ama araçlar ve yaklaşım her zaman aynıdır: ölç, daraltа, çöz, doğrula. Bir sonraki “sistem yavaş” şikayetinde saatler değil dakikalar içinde kaynağı bulacaksınız.