Linux Sunucu Bakımı: Adım Adım Optimizasyon

Linux sunucu bakımı; CPU, bellek, disk alanı, inode girdileri, sistem logları ve arka plan servislerini güvenli çalışma sınırları içinde tutan düzenli denetimler bütünüdür. Bu periyodik kontroller yapılmadığında sunucularda anlık 502 Bad Gateway, 504 Gateway Timeout hataları, kontrolsüz kilitlenmeler ve kapatılmamış güvenlik açıkları kaçınılmaz hale gelir.

Hızlı Bakım Kontrol Listesi (Özet Adımlar)

1. Kaynak Tüketimini Ölçün: uptime, free -m ve htop ile CPU yükünü ve serbest bellek miktarını doğrulayın.
2. Depolama ve Inode Durumuna Bakın: df -h ile blok alanını, df -i ile dosya indeks doluluğunu kontrol edin.
3. Log ve Paket Artıklarını Temizleyin: journalctl --vacuum-size=200M çalıştırın, paket yöneticisi önbelleğini arındırın.
4. Servisleri Optimize Edin: PHP-FPM havuz sınırlarını bellek kapasitenize göre dengeleyin, MySQL slow query loglarını inceleyin.
5. Ağ ve Güvenliği Denetleyin: ss -tulpn ile bilinmeyen portları tespit edin, aktif cron görevlerini gözden geçirin.

Linux Sunucu Bakımı Neden Gerekir?

Bir Linux sunucu kurulup yayına alındığı ilk gün genellikle sorunsuz çalışır. Ancak sistem çalıştığı her saniye diskte izler bırakır, paket güncellemelerinden kalan eski bağımlılıkları depolar ve web trafiğinin oluşturduğu oturum (session) verilerini biriktirir. Proaktif bir bakım rutini bulunmadığında sunucu, donanım arızası olmaksızın sadece bu operasyonel birikimler yüzünden hizmet veremez hale gelir.

Zamanla Biriken Yükün Mekanizması

İşletim sisteminde biriken yük çoğunlukla sessizce büyüyen şu bileşenlerden kaynaklanır:

• Dönmeyen (Unrotated) Sistem Logları: /var/log altındaki loglar veya systemd journal veritabanı sınırlandırılmadığında onlarca gigabaytlık alanı işgal edebilir.
• Uygulama Önbellekleri ve Oturum Dosyaları: Özellikle PHP tabanlı platformlarda /tmp veya /var/lib/php/sessions dizinlerinde biriken milyonlarca küçük dosya, disk boyutunu doldurmasa bile inode limitlerini tüketir.
• Eski Paket ve Çekirdek Kalıntıları: apt veya dnf güncellemelerinden sonra diskte kalan indirilmiş .deb / .rpm arşivleri ve eski Linux kernel sürümleri /boot bölümünü doldurarak yeni güvenlik güncellemelerinin yüklenmesini engeller.
• Veritabanı Şişmesi: MySQL veya MariaDB üzerinde optimize edilmemiş tablolar, silinmiş kayıtların bıraktığı boş alanlar ve aşırı büyüyen binary log (binlog) dosyaları disk IOPS sınırlarını tüketir.

Bakımdan Önce Temel Durum Tespiti

Herhangi bir temizlik veya yapılandırma değişikliğine başlamadan önce sistemin anlık yük profilini net rakamlarla görmek gerekir.

# Sistem genel yük durumu ve çalışma süresi
uptime

# Detaylı bellek ve takas (swap) analizi
free -m

# Disk alanı ve inode doluluğu
df -h
df -i

Kaynak Kullanımı: top, htop, free -m ve Uptime Load Average

uptime komutunu çalıştırdığınızda karşınıza çıkan üç rakam (örneğin: load average: 0.85, 1.20, 2.10), sistemin son 1, 5 ve 15 dakikalık süreçte CPU kuyruğunda bekleyen veya kesintisiz disk G/Ç (I/O) işleminde olan görev sayısını ifade eder.

Yük ortalamasını doğru yorumlamak için sunucudaki çekirdek sayısını (nproc komutuyla) bilmeniz şarttır:

• 4 çekirdekli bir sunucuda 15 dakikalık yük ortalaması 3.50 ise sistem güvenli çalışma aralığındadır.
• Aynı sunucuda yük 8.00 seviyesine çıkmışsa, CPU her saniye işlem sırası bekleyen iş parçacıklarına yetişemiyor demektir.
• Yük çok yüksek fakat CPU kullanımı düşük görünüyorsa, darboğaz büyük ihtimalle disk G/Ç (iowait) darboğazıdır.

free -m çıktısında ise available sütunu gerçek kullanılabilir belleği gösterir. buff/cache alanının yüksek olması Linux'un dosya sistemini hızlandırmak için boş belleği akıllıca kullandığını gösterir ve bir sorun teşkil etmez. Ancak Swap satırında sürekli ve artan bir kullanım (özellikle sıfırın belirgin üzerine çıkılması) varsa, fiziksel RAM tükenmiş ve sunucu aşırı yavaş olan diski bellek gibi kullanmaya başlamış demektir.

Disk ve Inode Kontrolü: df -h ve df -i Farkı

Sık karşılaşılan hatalardan biri, diskte gigabaytlarca boş alan varken sistemin No space left on device uyarısı vermesidir. Bunun nedeni inode tükenmesidir.

Linux dosya sistemlerinde (ext4, XFS vb.) her dosya, klasör ve sembolik bağ bir inode yapısına kaydedilir. Diskiniz biçimlendirilirken toplam blok boyutuna göre belirli sayıda inode oluşturulur. Örneğin sunucunuzda 50 GB boş disk alanı bulunsa dahi, oluşturulabilecek inode sınırı 2.000.000 ise ve diskte 2 milyon adet 1 baytlık önbellek dosyası birikmişse, yeni tek bir dosya bile yazılamaz.

• df -h: Blok tabanlı veri boyutunu (GB, MB) raporlar.
• df -i: Kullanılan ve kalan toplam inode adedini raporlar.

# En çok dosya ve inode barındıran dizinleri tespit etmek için
find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n | tail -20

Disk ve Log Temizliği

Kritik Bakım Kuralı: Disk temizliğine başlamadan önce daima bir sanallaştırma katmanı snapshot'ı veya tam sistem yedeği alın. Çalışan aktif servislerin kilitli tuttuğu log dosyalarını (access.log gibi) doğrudan rm ile silmeyin; dosya silinmiş görünse de disk alanı serbest kalmaz (lsof | grep deleted). Bunun yerine dosya içeriğini boşaltın (truncate -s 0 dosya_adi) veya yalnızca logrotate tarafından arşivlenmiş .gz ya da .1 uzantılı eski kopyaları temizleyin.

journalctl --vacuum-size ve logrotate Yapılandırması

Systemd kullanan dağıtımlarda sistem logları ikili (binary) formatta /var/log/journal/ dizininde tutulur. Varsayılan sınırlandırma yapılmadığında bu alan 10-20 GB seviyelerine kolayca ulaşabilir.

# Logların diskte kapladığı toplam alanı kontrol edin
journalctl --disk-usage

# Log boyutunu son 200 MB ile sınırlandırarak eski verileri silin
journalctl --vacuum-size=200M

# Alternatif olarak 14 günden eski sistem loglarını silin
journalctl --vacuum-time=14d

Kalıcı çözüm için /etc/systemd/journald.conf dosyasında SystemMaxUse=200M parametresini tanımlayıp servisi yeniden başlatın (systemctl restart systemd-journald).

Geleneksel servis logları (Nginx, Apache, PHP, MySQL) için /etc/logrotate.conf ve /etc/logrotate.d/ altındaki kuralları denetleyin. Log dosyalarının haftalık döngüyle döndürüldüğünden (weekly), sıkıştırıldığından (compress) ve 4 haftadan eski arşivlerin silindiğinden (rotate 4) emin olun.

Geçici Dizinler ve Paket Önbelleği

Paket yöneticileri indirilen kurulum dosyalarını önbellekte saklar. Uzun süre temizlenmeyen paket depoları gigabaytlarca alan tüketir.

# Debian / Ubuntu sistemler için
apt update
apt autoremove --purge -y   # Artık gerekmeyen bağımlılıkları ve eski kernelleri kaldırır
apt clean                  # İndirilen .deb arşiv önbelleğini tamamen temizler

# RHEL / Rocky Linux / AlmaLinux sistemler için
dnf autoremove -y
dnf clean all
rm -rf /var/cache/dnf

# /tmp dizininde 7 günden eski geçici dosyaları temizleme
find /tmp -type f -atime +7 -delete

Servis ve Performans Ayarları

Sunucu donanımı ne kadar güçlü olursa olsun, yazılım servisleri eldeki kaynak sınırlarına göre yapılandırılmamışsa kaynak tüketimi kontrolsüz şekilde artar. Kullanıcı tarafında yaşanan gecikmelerin temelinde yalnızca sunucu altyapısı değil, uygulama kodları da yer alabilir; bu ayrımı kavramak için web sitesi neden yavaş olabilir konusundaki teşhis adımlarını bilmek analiz sürecinizi kolaylaştırır.

Nginx Worker ve Keepalive Mantığı

Nginx gibi modern web sunucuları olay tabanlı (event-driven) mimariyle çalışır. nginx.conf içindeki worker_processes parametresi sunucudaki çekirdek sayısına (auto) eşitlenmelidir.

events {
    worker_connections 2048;
    multi_accept on;
    use epoll;
}

http {
    keepalive_timeout 30;
    keepalive_requests 1000;

    # Gzip sıkıştırma ile bant genişliği ve transfer süresi optimizasyonu
    gzip on;
    gzip_comp_level 5;
    gzip_types text/plain text/css application/javascript application/json image/svg+xml;
}

keepalive_timeout değerinin çok uzun tutulması (örn. 120 sn), istemciler işlem yapmasa bile açık bağlantıların bellekte tutulmasına yol açar. Yoğun trafikli sistemlerde 15-30 saniye aralığı ideal bir dengedir.

PHP-FPM pm.max_children Hesabı

PHP-FPM, sunucularda bellek taşması (Out of Memory - OOM) kaynaklı kilitlenmelerin bir numaralı failidir. pm = dynamic veya pm = ondemand kullanırken en kritik parametre pm.max_children değeridir.

Eğer bu parametreye rasgele yüksek bir değer (örneğin 100) verirseniz ve her bir PHP süreciniz 90 MB bellek tüketiyorsa, yoğun bir anda PHP tek başına 9 GB RAM talep eder. Sunucuda 8 GB RAM varsa işletim sistemi takas alanına (swap) düşer ya da OOM Killer mekanizması MySQL veya web sunucusunu aniden sonlandırır.

Maksimum çocuk süreç sınırı belirlenirken toplam sistem belleğinden işletim sistemi ve veritabanı için ayrılan güvenli pay çıkarılır; kalan bellek miktarı ise tek bir PHP işleminin ortalama bellek tüketimine bölünür.

Örnek bir senaryo üzerinden incelersek:

• Toplam RAM: 8192 MB (8 GB)
• İşletim sistemi ve MariaDB için ayrılan pay: 3000 MB
• PHP için kalan güvenli bellek: 5192 MB
• Ortalama PHP süreci (ps --no-headers -o 'rss,cmd' -C php-fpm7.4 | awk '{sum+=$1} END {print sum/NR/1024}'): 65 MB

Bu senaryoda 5192 değeri 65 değerine bölündüğünde güvenli pm.max_children tavanı yaklaşık 79 olarak hesaplanır. Bu sınır, sunucunuzun eşzamanlı trafik altında swap alanına düşmeden ve kilitlenmeden ayakta kalmasını sağlar.

MySQL/MariaDB Buffer Pool ve Slow Query Analizi

Veritabanı performansındaki en önemli parametre InnoDB motoru için innodb_buffer_pool_size değeridir. Bu havuz, veritabanı indekslerini ve sık kullanılan verileri disk yerine bellekte tutar.

• Yalnızca veritabanı barındıran sunucularda bu değer fiziksel RAM'in %70-80'i olarak atanabilir.
• Web sunucusu, PHP ve MySQL'in bir arada bulunduğu hibrit sunucularda ise toplam RAM'in %40-50'sini aşmamalıdır.

Düzenli bakımda yavaş sorguları (slow query) açığa çıkarmak hayati önem taşır:

# /etc/mysql/mariadb.conf.d/50-server.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 1
log_queries_not_using_indexes = 0

Belirli aralıklarla mysqldumpslow /var/log/mysql/mariadb-slow.log komutunu çalıştırarak indeks eksikliği yüzünden diski meşgul eden sorguları tespit edip optimize edin.

Güncelleme ve Yama Yönetimi

Güvenlik açıklarının kapatılması sistem stabilitesi kadar kritiktir. Ancak rastgele zamanlarda yapılan kontrolsüz güncellemeler uyumsuzluklara neden olabilir.

1. Paket Listelerini Güncelleyin: apt update veya dnf check-update ile mevcut güncellemeleri listeleyin.
2. Güvenlik Yamalarını Önceliklendirin:
   - Debian/Ubuntu: unattended-upgrades yapılandırmasıyla kritik güvenlik yamalarını otomatikleştirin.
   - RHEL/AlmaLinux: dnf update --security ile yalnızca güvenlik açığı kapatan yamaları yükleyin.
3. Yeniden Başlatma (Reboot) Gereksinimini Kontrol Edin: Linux çekirdeği (kernel), glibc veya systemd güncellendiğinde sistemin yeni kütüphaneleri kullanabilmesi için yeniden başlatılması gerekir.

# Debian/Ubuntu üzerinde reboot gereksinimi kontrolü
if [ -f /var/run/reboot-required ]; then
    echo "Sunucunun yeniden başlatılması gerekiyor!"
    cat /var/run/reboot-required.pkgs
fi

# RHEL türevlerinde kütüphane kontrolü
needs-restarting -r

Güvenlik Kontrolleri

Bakım rutini, yetkisiz erişim teşebbüslerini ve sisteme sızmış arka plan süreçlerini denetlemeyi de kapsamalıdır. Sunucunuzun dış dünyaya açık kapılarını asgari düzeye indirmek için güvenli ağ altyapısı için temel ipuçları prensiplerini uygulayarak güvenlik duvarı seviyesinde izolasyon sağlamalısınız.

Açık Portlar, SSH ve Koruma Katmanı

Sunucuda hangi servislerin hangi ağ arayüzlerini dinlediğini düzenli olarak listeleyin:

ss -tulpn

Burada 0.0.0.0 veya ::: adresine bağlı tüm portlar tüm dünyaya açıktır. MySQL (3306) veya Redis (6379) gibi dahili servislerin yalnızca 127.0.0.1 (localhost) veya yerel ağ IP'sini dinlediğinden emin olun.

• SSH Sıkılaştırması: Parola ile girişleri /etc/ssh/sshd_config dosyasından kapatın (PasswordAuthentication no), yalnızca Ed25519 veya RSA SSH anahtarlarıyla erişime izin verin. Varsayılan portu değiştirmek tarayıcı botların gürültüsünü azaltır.
• Fail2ban veya CrowdSec: Başarısız kimlik doğrulama denemelerini izleyerek şüpheli IP adreslerini iptables/nftables seviyesinde otomatik olarak engelleyen bir servisi mutlaka devrede tutun.

Şüpheli Süreçler ve Kripto Madenci Tespiti

Sisteme yetkisiz erişim sağlandığında genellikle ilk yapılan eylem, arka planda CPU tüketen bir kripto para madencisi (XMRig vb.) çalıştırmak veya tersine kabuk (reverse shell) açmaktır.

Bu tür tehditleri yakalamak için bakım sırasında şu noktaları inceleyin:

• Zamanlanmış Görevler: /etc/crontab, /etc/cron.* dizinleri ve tüm kullanıcıların cron tablolarını (for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l; done) tarayın. Base64 ile şifrelenmiş veya curl | sh içeren bilinmeyen cron satırları doğrudan tehlike işaretidir.
• Geçici Dizinlerde Çalışan İkilikler: Kötü amaçlı yazılımlar genellikle yazma yetkisi açık olan /tmp, /var/tmp veya /dev/shm dizinlerine indirilir ve oradan çalıştırılır. ls -la /tmp ve lsof +D /tmp komutlarıyla bu alanlarda çalışan şüpheli binary dosyaları araştırın.
• Gizlenen Süreçler: top veya htop açıldığında aniden kapanan ya da rastgele karakter dizilerinden oluşan (örn. kworkerds, sysupdate, xm64) yüksek CPU tüketen süreçleri ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -15 komutuyla listeleyin.

Düzenli Bakım Takvimi

Sunucu yönetimini reaktif kriz yönetiminden kurtarıp proaktif bir yapıya dönüştürmek için bakım işlemlerini belirli periyotlara bölmek gerekir.

Günlük Kontroller

• Otomatik yedekleme betiklerinin veya snapshot görevlerinin başarıyla tamamlandığını doğrulayın.
• Disk doluluk oranını (df -h) göz ucuyla denetleyin; beklenmedik ani bir sıçrama olup olmadığına bakın.
• Güvenlik duvarı engelleme kayıtlarını ve web erişim loglarındaki aşırı 4xx/5xx hata patlamalarını izleyin.

Haftalık Kontroller

• Sistem log boyutunu (journalctl --disk-usage) ve /var/log doluluğunu kontrol edin.
• Paket yöneticisi güvenlik bildirimlerini tarayın (apt update && apt list --upgradable).
• PHP-FPM ve veritabanı yavaş sorgu loglarını inceleyerek darboğaz yaratan fonksiyonları not edin.

Aylık Kapsamlı Bakım Protokolü

1. Yedek Alma ve Doğrulama: Çalışan servislerin tam veritabanı ve dosya yedeğini alın; mümkünse yedeği test ortamında geri yükleyerek çalışabilirliğini teyit edin.
2. Paket Temizliği: apt autoremove --purge ve apt clean (veya DNF muadilleri) ile eski paket ve kernel kalıntılarını silin.
3. Inode ve Önbellek Arındırma: Oturum dosyalarını, terk edilmiş geçici verileri ve /tmp artıklarını temizleyin.
4. İşletim Sistemi Yamaları: Güvenlik ve kararlılık güncellemelerini test ederek uygulayın.
5. Yapılandırma İncelemesi: Servis bağlantı limitlerini, worker sayılarını ve bellek kullanım dağılımını artan trafiğe göre güncelleyin.
6. Güvenlik Taraması: Açık portları (ss -tulpn), yetkili SSH anahtarlarını (authorized_keys) ve kullanıcı cron görevlerini baştan aşağı denetleyin.
7. Kontrollü Yeniden Başlatma: Gerekli çekirdek güncellemeleri sonrasında sunucuyu kontrollü olarak yeniden başlatarak tüm servislerin sorunsuz ayağa kalktığını doğrulayın.

Sunucu altyapınızın bakımını, log temizliğini ve performans optimizasyonunu şirket içinde yürütmek istemiyorsanız; Signalique tarafından sağlanan Linux Sunucu Bakım, Temizlik ve Optimizasyon Hizmeti kök (root) seviyesinde kapsamlı bir teknik çözüm sunar. İhtiyacınıza göre tek seferlik kapsamlı disk, log, Nginx/LiteSpeed, PHP-FPM ve MySQL optimizasyonu sunan Sunucu Bakım, Temizlik & Performans Paketi, sızılmış sistemler için zararlı yazılım temizliği, SSH anahtar sıkılaştırması ve CrowdSec/WAF kurulumu içeren Acil Zararlı Temizliği, Kurtarma & Tam Sıkılaştırma veya altyapınızın sürekli izlenip güncellendiği Aylık Proaktif Yönetim & Bakım Paketi seçeneklerini değerlendirebilirsiniz. Güncel paket kapsamlarını ve teknik ayrıntıları ilgili hizmet sayfasından inceleyebilirsiniz.

Sıkça Sorulan Sorular

Linux sunucuda ne sıklıkla bakım yapılmalı?

Hafif disk ve kaynak kontrolleri günlük otomasyonlarla izlenmeli, log ve önbellek arındırmaları haftalık periyotlarla gözden geçirilmelidir. Paket güncellemeleri, servis optimizasyonları ve derinlemesine güvenlik taramalarını kapsayan genel sistem bakımı ise ayda en az bir kez planlı bir kesinti penceresinde uygulanmalıdır.

Disk dolu görünmüyor ama 'No space left on device' hatası alıyorum, neden?

Bu durum neredeyse her zaman dosya sistemindeki inode limitinin tükenmesinden kaynaklanır. Diskinizde gigabaytlarca boş alan olsa bile, milyonlarca küçük geçici dosya (örneğin session dosyaları veya e-posta kuyrukları) sistemin izin verdiği maksimum dosya kayıt indeksini (inode) tüketmiştir. df -i komutuyla kullanım oranını denetleyebilir ve en çok dosya barındıran dizinleri temizleyerek sorunu çözebilirsiniz.

Sunucumda kripto madenci olup olmadığı nasıl anlaşılır?

Kripto madenciler genellikle işlemciyi sürekli %90-100 seviyesinde tutar. top veya htop çalıştırdığınızda işlemciyi tüketen süreç kendini gizliyorsa, ps -eo pid,ppid,cmd,%cpu --sort=-%cpu komutuyla gizlenmeye çalışan binary dosyaları yakalayabilirsiniz. Ayrıca /tmp, /var/tmp ve /dev/shm dizinlerindeki şüpheli çalıştırılabilir dosyalar ile kullanıcıların crontab girdilerindeki yabancı indirme betikleri madenci varlığına işaret eder.

Bakımı kendim mi yapmalıyım yoksa uzman desteği mi almalıyım?

Temel terminal bilgisine, Linux dizin hiyerarşisine hakimseniz ve düzenli yedek alıyorsanız temel log temizliği ve paket güncellemelerini kendiniz yürütebilirsiniz. Ancak üretim (production) ortamlarında çalışan, kesinti tolere edemeyen, karmaşık PHP-FPM/veritabanı optimizasyonu veya güvenlik sıkılaştırması gerektiren sistemlerde profesyonel sistem yönetimi desteği almak veri kaybı ve plansız kesinti risklerini ortadan kaldırır.