Sunucu Yavaşladı mı? 10 Dakikada Performans Sorunlarını Tespit Etme
Sabah 09:00, telefon çalıyor: "Site açılmıyor, ne oldu?" En sık aldığımız çağrılardan biri. Müşteri panikle, biz sakin. Çünkü 14 yıldır aynı senaryoyu yüzlerce kere gördük. Çoğu zaman 10 dakikada tespit edilir, 30 dakikada çözülür. Bu yazıda, sunucu yavaşlama sorunlarını nasıl tespit edeceğinizi, hangi komutları kullanacağınızı ve sık karşılaşılan 10 problemi nasıl çözeceğinizi anlatacağız. Teknik bilginiz yoksa bile takip edebilirsiniz.
İlk 60 Saniye: Hızlı Teşhis
Sunucuya SSH ile bağlandınız. İlk yapmanız gerekenler:
# 1. Load average kontrol (1-5-15 dakika ortalaması)
uptime
# Çıktı: load average: 2.50, 1.80, 1.20
# Kural: CPU sayısından fazlaysa sorun var
# 2. Bellek durumu
free -h
# Available sütununa bakın, %10'un altındaysa sorun
# 3. Disk kullanımı
df -h
# %95+ doluysa kritik
# 4. En çok kaynak tüketen processler
top
# Shift+P: CPU'ya göre sırala
# Shift+M: RAM'e göre sırala
60 Saniye Teşhis Sonuçları:
- Load average yüksek: CPU sorunu (devam edin Adım 1'e)
- Available memory düşük: RAM sorunu (Adım 2)
- Disk %95+ dolu: Disk sorunu (Adım 3)
- Hepsi normal: Network sorunu (Adım 4)
Sorun 1: Yüksek CPU Kullanımı
Belirti:
- Load average > CPU sayısı
- top'ta %100 CPU kullanan processler
- Site yavaş ama çökmedi
Teşhis Komutları:
# En çok CPU kullanan 10 process
ps aux --sort=-%cpu | head -11
# Hangi kullanıcı ne kadar kullanıyor
ps aux | awk '{cpu[$1]+=$3} END {for (user in cpu) print user, cpu[user]}'
# Gerçek zamanlı CPU izleme (htop daha iyi)
htop
# F6 ile CPU'ya göre sırala
Yaygın Sebepler ve Çözümler:
1. PHP-FPM veya Apache süreçleri çok fazla
# PHP-FPM süreç sayısını kontrol et
ps aux | grep php-fpm | wc -l
# Çözüm: pm.max_children değerini düşür
nano /etc/php/8.2/fpm/pool.d/www.conf
pm.max_children = 20 # 50'den 20'ye düşür
systemctl restart php8.2-fpm
2. MySQL query'leri yavaş
# Yavaş query'leri bul
mysql -e "SHOW FULL PROCESSLIST;" | grep -v Sleep
# Slow query log aktifleştir
nano /etc/mysql/my.cnf
slow_query_log = 1
long_query_time = 2
# Log'u incele
tail -f /var/log/mysql/slow.log
3. Cron job sonsuz döngüde
# Çalışan cron'ları kontrol et
ps aux | grep cron
# Belirli bir scripti kill et
pkill -f backup.sh
Sorun 2: RAM Dolu (Out of Memory)
Belirti:
- free -h'da Available < 500 MB
- Swap kullanımı yüksek
- Processler rastgele kapanıyor (OOM Killer)
# Bellek durumu detaylı
free -h
# total used free shared buff/cache available
# Mem: 16Gi 12Gi 200Mi 500Mi 3.8Gi 2.5Gi
# Swap: 8Gi 6Gi 2Gi
# En çok RAM kullanan 10 process
ps aux --sort=-%mem | head -11
# OOM Killer logları
dmesg | grep -i "killed process"
Acil Çözümler:
1. Cache temizle (geçici çözüm)
# PageCache, dentries, inodes temizle
sync; echo 3 > /proc/sys/vm/drop_caches
# Sonuç kontrol
free -h
2. Bellek sızıntısı olan servisi restart
# Örnek: Apache 8 GB kullanıyorsa
systemctl restart apache2
# PHP-FPM
systemctl restart php8.2-fpm
3. MySQL buffer pool küçült
# /etc/mysql/my.cnf
innodb_buffer_pool_size = 2G # 8G'den 2G'ye düşür
systemctl restart mysql
Gerçek Vaka: Bir WordPress sitesi günde 3 kere çöküyordu. Sebep: WP Rocket cache plugin, 12 GB RAM biriktirmiş. Plugin kaldırınca sorun çözüldü. Ders: Her eklenti RAM tüketir.
Sorun 3: Disk Dolu
Belirti:
- df -h'da %95+ kullanım
- "No space left on device" hatası
- Log yazılamıyor, database lock
# Disk kullanımı
df -h
# En büyük dizinler (root'tan başla)
du -h --max-depth=1 / | sort -rh | head -20
# Belirli dizinde en büyük dosyalar
find /var/log -type f -exec du -h {} + | sort -rh | head -20
Yaygın Sebepler:
1. Log dosyaları şişmiş
# En büyük log dosyalarını bul
find /var/log -type f -size +100M
# Güvenli temizlik (dosyayı silmeden içini boşalt)
> /var/log/apache2/access.log
> /var/log/mysql/error.log
# Eski logları sil
find /var/log -type f -mtime +30 -delete
2. Backup dosyaları birikmiş
# 30 günden eski backup'ları sil
find /backup -type f -mtime +30 -name "*.tar.gz" -delete
3. Tmp dosyaları temizlenmemiş
# /tmp temizliği
find /tmp -type f -atime +7 -delete
# PHP session dosyaları
find /var/lib/php/sessions -type f -mtime +7 -delete
Sorun 4: Yüksek Disk I/O
Belirti:
- Site yavaş ama CPU/RAM normal
- top'ta "wa" (wait) yüksek
- Database sorguları takılıyor
# I/O istatistikleri (iostat kurulumu gerekebilir)
apt install sysstat
iostat -x 1 5
# %util > 80 ise disk bottleneck var
# Hangi process disk kullanıyor (iotop kurulu olmalı)
apt install iotop
iotop -o
# -o: Sadece aktif I/O yapanlar
Çözümler:
1. MySQL slow query sorunu
# Index eksikliği kontrol
mysql -e "SELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA='dbname' AND INDEX_LENGTH=0;"
# Query cache aç (MySQL 5.7)
query_cache_size = 64M
query_cache_type = 1
2. Swap kullanımı yüksek (disk'e yazıyor)
# Swappiness azalt (RAM'e öncelik ver)
sysctl vm.swappiness=10
echo "vm.swappiness=10" >> /etc/sysctl.conf
Sorun 5: Network Bağlantı Sorunu
Belirti:
- SSH bağlantısı yavaş
- Site arada açılıyor arada açılmıyor
- API istekleri timeout
# Aktif bağlantı sayısı
netstat -an | grep ESTABLISHED | wc -l
# Hangi IP'den en çok bağlantı var
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
# Port 80/443 dinliyor mu
netstat -tlnp | grep :80
netstat -tlnp | grep :443
Yaygın Sebepler:
1. DDoS saldırısı altında
# SYN flood kontrolü
netstat -an | grep SYN | wc -l
# 1000+ ise saldırı var
# Acil çözüm: Rate limiting
iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT
2. DNS çözümleme yavaş
# DNS response time test
dig @8.8.8.8 sistemdc.com
# Query time kontrol et
# Alternatif DNS kullan
nano /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
Sorun 6: Servis Çökmüş
# Hangi servisler çalışıyor
systemctl list-units --type=service --state=running
# Apache durumu
systemctl status apache2
# Nginx durumu
systemctl status nginx
# MySQL durumu
systemctl status mysql
# Servis başlatma
systemctl start apache2
# Hata logları
journalctl -u apache2 -n 50
SistemDC 7/24 Monitoring ve Müdahale
SistemDC sunucularında otomatik monitoring aktiftir:
- Uptime monitoring: Her 60 saniyede kontrol
- Resource alerts: CPU > %90, RAM < %10, Disk > %90
- 7/24 NOC: Alarm geldiğinde mühendis müdahale eder
- Otomatik restart: Kritik servisler çöktüğünde otomatik başlatılır
Managed Support Paketi: Aylık 500 TL'den başlayan fiyatlarla, tüm performans sorunlarını biz çözüyoruz. Siz işinize odaklanın, teknik detaylar bizde kalsın.
Proaktif Önlemler: Sorun Yaşamadan Yapın
1. Monitoring Kurun
# Netdata kurulumu (lightweight monitoring)
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
# http://sunucu-ip:19999 adresinden erişin
2. Otomatik Yedekleme
# Günlük database backup
0 2 * * * mysqldump --all-databases > /backup/db-$(date +\%Y\%m\%d).sql
3. Log Rotation
# /etc/logrotate.d/apache2
/var/log/apache2/*.log {
daily
rotate 7
compress
delaycompress
missingok
}
Sunucu Sorunu mu Yaşıyorsunuz?
Teknik ekibimiz 7/24 hizmetinizde. Acil müdahale gerekiyorsa hemen arayın.
Acil Destek:
[email protected]
Kurumsal Whatsapp: 0224 334 02 42
Sonuç: Hızlı Teşhis, Hızlı Çözüm
Sunucu performans sorunlarının %80'i yukarıdaki 6 kategoriden birine giriyor. 14 yıldır yüzlerce sorun gördük, deneyimimiz şu:
- İlk 60 saniyede doğru teşhis yaparsanız, 10 dakikada çözersiniz
- Monitoring olmadan reaktif kalırsınız, proaktif olamazsınız
- Çoğu sorun, küçük yapılandırma değişiklikleriyle önlenebilir
- Yedekleme şart, aksi halde bir hata felakete dönüşebilir
Bu komutları bir yere not edin. Sorun yaşadığınızda panik yapmayın, sistematik yaklaşın. Çözemezseniz, biz varız.
Not: Bu yazıdaki komutlar Ubuntu 24.04 ve Debian tabanlı sistemler için test edilmiştir. Üretim sunucusunda değişiklik yapmadan önce yedek aldığınızdan emin olun. Kritik sistemlerde önce test ortamında deneyin.
AMD Ryzen Sunucu Avantajları
Ryzen Paketleri
