Web sunucusu sorun giderme için Linux komutları

Site açılmıyor. SSH ile bağlanıyorsunuz, giriyorsunuz ve şimdi on dakika içinde sorunun CPU'dan mı, diskten mi, web servisinden mi yoksa DNS'ten mi kaynaklandığını anlamanız gerekiyor. Bu makale tam olarak o yol: Linux komutları alfabetik sırayla değil, gerçekte çalıştırıldıkları sırayla.

Her şeyden önce bir kural: burada gördüğünüz her komutu önce bir test sunucusunda çalıştırın, production'da değil. Bunlardan bazıları yalnızca okur ve zararsızdır; bir ikisi değil.

Önce siteye değil, sunucunun yüküne bakın

Site yavaşladığında veya zaman aşımı verdiğinde bakmanız gereken ilk sayı load average'dır:

uptime
# 14:32:07 up 41 days,  3:12,  2 users,  load average: 12.40, 9.85, 4.20

Son üç sayı, geçmiş bir, beş ve on beş dakikadaki ortalama yüktür. Pratik kural: bu sayı CPU çekirdek sayısını aşarsa kuyruk oluşmuş demektir. nproc ile çekirdek sayısını görün. 4 çekirdekli bir sunucuda load 12, kapasitenin üç katı demektir; 16 çekirdekli bir sunucuda load 12 ise hâlâ yeriniz var demektir.

Önemli nokta: yüksek load her zaman CPU'nun dolu olduğu anlamına mı gelir? Hayır. Load yüksekse ama top CPU'nun boşta olduğunu gösteriyorsa, sorun disk I/O'dur. Burada hata yapılır: site yöneticisi load'un yükseldiğini görür, sunucuyu yükseltir ve sorun ağ diskinin yavaşlığıysa olduğu gibi kalır.

top -o %CPU
free -h
df -h
df -i

free -h çıktısını dikkatlice okuyun. Önemli olan available sütunudur, free değil. Linux boş belleği cache için harcar ve bu normaldir; available sıfıra yaklaşır ve swap dolarsa, işte o zaman bellek sorununuz var demektir. df -h disk alanını, df -i ise inode sayısını gösterir. df -h %40 boş diyorken alınan "No space left on device" hatası neredeyse her zaman inode'ların tükendiği anlamına gelir — genellikle milyonlarca küçük session veya cache dosyası yüzünden.

Diski hangi süreç yiyor

Bellek ve CPU'ya göre en çok tüketen süreçleri görmek için:

ps aux --sort=-%mem | head -n 10
ps aux --sort=-%cpu | head -n 10

Ve hangi sürecin gerçekten disk I/O ürettiğini anlamak için iotop kurun (iotop paketi standart depolarda mevcuttur). iotop yoksa vmstat 1 de yeterlidir: si ve so sütunları büyük sayılar gösteriyorsa, sistem swap yapıyor demektir ve bu bir web sunucusu için en kötü durumdur.

Açıkça söylemem gereken bir ödünleşim: bir süreci kill -9 ile öldürmek en hızlı yoldur ve ben de acil durumlarda bunu yaparım, ancak süreç bir veritabanıysa tabloları bozabilir ve yeniden başlatmadan sonra recovery hatasıyla karşılaşabilirsiniz. Önce kill -15 gönderin, on saniye bekleyin, sonra yanıt vermezse -9.

Web servisi ve portlar

Site hiç yanıt vermiyorsa, her şeyden önce web servisinin canlı olup olmadığına bakın:

systemctl status nginx
systemctl status apache2
systemctl status php8.2-fpm

Ve sonra portlara:

ss -tulpn | grep -E ':80|:443|:3306'

Port 80 dinlemiyorsa, sorun site kodunda değil servis katmanındadır. Dinliyorsa ama dışarıdan yanıt alamıyorsanız, muhtemelen arada güvenlik duvarı veya Cloudflare vardır. ss, netstat'ın yerini almıştır; yeni dağıtımlarda netstat hiç kurulu olmayabilir.

Sunucunun kendisinden, DNS aracısı olmadan HTTP yanıtını test etmek için:

curl -I -H "Host: example.com" http://127.0.0.1
curl -o /dev/null -s -w "%{time_total}\n" https://example.com

İkinci sayı, isteğin toplam süresidir (saniye cinsinden). Bu sayı 0.5'in altındaysa ve kullanıcılar hâlâ şikâyet ediyorsa, sorun sizin sunucunuzda değil; ağ yolunda veya DNS'tedir. 502 ve 504 gibi durum kodlarının ayrımı HTTP durum kodu rehberinde yer alıyor ve bu aşama için tam olarak ihtiyacınız olan şeydir.

Loglar: gerçek cevabın olduğu yer

Hiçbir komut log okumanın yerini tutmaz. Yollar dağıtıma göre değişir:

tail -f /var/log/nginx/error.log
tail -n 200 /var/log/nginx/access.log
journalctl -u php8.2-fpm --since "30 min ago"
journalctl -xe

Access log'da 500 kodlarını arayın ve hangi yolun en çok tekrarlandığına bakın:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

Belirli bir IP sunucuyu dövüyorsa, onu tam orada bulursunuz. 500 hatası belirli bir betikte yoğunlaşıyorsa, sorun sunucuda değil eklentide veya koddadır. WordPress siteleri için eklenti denetimi genellikle herhangi bir sunucu tuning'inden daha hızlı sonuç verir.

Pratik bir uyarı: saniyede binlerce satır üreten bir log üzerinde tail -f, terminalinizi kilitleyebilir. Yüksek hacim için ham izleme yerine filtreli grep kullanın.

Ağ, DNS ve veritabanı bağlantısı

Site sunucunun içinden yanıt veriyor ama dışarıdan vermiyorsa, test sırası şöyledir:

dig +short example.com A
dig +trace example.com
ping -c 4 8.8.8.8
mtr -rw example.com

dig +trace tam resolve yolunu gösterir ve bir yerde kesilirse, tam orada belli olur. NXDOMAIN hatası, kaydın olmadığı veya zone'un doğru yüklenmediği anlamına gelir; tanısının ayrıntıları DNS_PROBE_FINISHED_NXDOMAIN hatasında yer alıyor.

Veritabanı için iki şeyi ayrı ayrı test edin: ağ bağlantısı ve kimlik doğrulama bağlantısı.

mysql -h 127.0.0.1 -u appuser -p -e "SELECT 1;"
mysqladmin -u root -p status

mysqladmin status çıktısındaki Threads_connected sayısı max_connections sınırına yaklaşıyorsa, sorun buradadır: web istekleri bağlantı kuyruğunun arkasında bekler ve CPU veya diskte sorun olmadan site yavaşlar. Bu, herkesin web sunucusuna baktığı ve suçlunun veritabanı olduğu durumlardan biridir.

Zaman kazandıran birkaç komut

• du -sh /var/log/* | sort -h — diski dolduran şişkin logları bulmak.
• lsof -i :80 — portu hangi süreç tutuyor.
• find /var/www -name "*.php" -mtime -1 — son 24 saatte hangi dosyalar değişti; şüpheli değişikliği izlemek için.
• crontab -l ve ls /etc/cron.d/ — sabah 3'te sunucuyu uyutan yedekleme veya betik.
• last -n 20 — son girişler; bilinmeyen bir IP görürseniz, önce şifreleri değiştirin sonra sorun giderin.

WordPress'te SSH erişiminiz varsa, WP-CLI panelden kat kat hızlıdır: wp plugin list --status=active ve wp cron event list birkaç saniyede arka planda neyin çalıştığını gösterir. WordPress cron'u takılmışsa, site her ziyarette yavaşlar; tanı kalıbı wp-cron sorununda açıklanmıştır.

Bu işler ne zaman yeterli olmaz

Tüm bunlardan sonra load düşükse, disk sağlıklıysa, logda hata yoksa ama site hâlâ yavaşsa, sorun muhtemelen platform katmanındadır: depolama ağı, konteyner CPU kotası veya sanal bir ana makinedeki yüksek tüketimli komşu. Burada artık Linux komutları işe yaramaz ve sağlayıcıyla iletişime geçmeniz gerekir. Paylaşımlı hosting veya WordPress hosting kullanıyorsanız, bu tam olarak terminalde debelenmek yerine ticket açmanın daha mantıklı olduğu noktadır.

Günlük işler için, her beş dakikada bir uptime, free -h ve df -h çıktısını bir dosyaya yazan küçük bir betik, herhangi bir pahalı araçtan daha çok işinize yarar. Site çöktüğünde, son iki saatteki bu üç sayının geçmişine sahip olmak, tahmin ile teşhis arasındaki farktır. Daha fazla hazır araç ücretsiz araçlarda ve adım adım kılavuzlar dokümantasyonda mevcuttur.

Sık sorulan sorular

Sorunun CPU'dan mı yoksa diskten mi olduğunu nasıl anlarım?

Load average yüksekse ama top CPU'nun büyük kısmının boşta (id) olduğunu gösteriyorsa, darboğaz disktir. vmstat 1 ile wa sütununa bakın; %20'nin üzerindeki bir sayı, süreçlerin I/O beklediği anlamına gelir. Bu durumda CPU yükseltmek hiçbir işe yaramaz.

kill -15 ile kill -9 arasındaki fark nedir ve hangisini kullanmalıyım?

kill -15 temiz bir sonlandırma isteği gönderir ve sürecin dosyaları ve bağlantıları kapatmak için zamanı olur. kill -9 derhal ve fırsat vermeden öldürür ve veritabanı için uzun bir recovery'ye neden olabilir. Her zaman önce 15, on saniye sonra süreç hâlâ duruyorsa 9.

df yer var diyor ama neden No space left on device hatası alıyorum?

Çünkü alan değil, inode tükenmiştir. df -i ile kontrol edin. Yaygın neden, çok sayıda küçük dosyadır: PHP session'ları, cache dosyaları veya e-posta kuyruğu. Bunları bulmak, şüpheli klasörlerde find /path -type f | wc -l ile başlar.

Site sunucunun içinden açılıyor ama dışarıdan açılmıyor; nereden başlamalıyım?

Önce dig +short example.com A ile DNS'i kontrol edin ve dönen IP'nin sunucunun IP'si olduğundan emin olun. Sonra güvenlik duvarını ve açık portları ss -tulpn ile görün. Her ikisi de doğruysa, muhtemelen arada bir proxy veya CDN vardır ve o katmanın ayarlarını incelemeniz gerekir.