Linux Sunucu Tuning: Nginx ve Çekirdek Ayarları

Önkoşullar ve Kapsam

Bu rehber, orta seviye Linux kullanıcılarını hedef alır. Komut satırı, systemd, dosya izinleri ve temel ağ kavramlarına aşina olduğunuzu varsayar. Örnekler Debian/Ubuntu tabanlı dağıtımlarda apt paket yöneticisi üzerinden verilmiştir; RHEL türevi dağıtımlarda paket adları ve yollar farklılık gösterebilir.

Sürüm notu: Bu metin belirli bir Nginx veya kernel sürümüne bağlı değildir. Kullandığınız sürümün varsayılan değerleri ve modül desteği farklı olabilir; uygulamadan önce nginx -v ve uname -r ile kendi ortamınızı doğrulayın. Aşağıdaki değerler başlangıç noktasıdır, kopyala-yapıştır ile üretime alınacak kesin ayarlar değildir.

Neden Tuning Gerekir

Bir sunucu varsayılan ayarlarla çalıştığında genellikle tek bir iş yükü profili için (düşük eşzamanlılık, sınırlı bağlantı) yapılandırılmıştır. Trafik arttığında darboğaz; dosya tanıtıcı limitleri, TCP geri kuyruğu, bellek yönetimi veya Nginx worker yapılandırması gibi katmanlardan birinde ortaya çıkar. Tuning, bu katmanları ölçüme dayalı olarak ayarlamak anlamına gelir — körlemesine değer büyütmek değil.

1. Ölçüm ve Baseline

Değişiklik yapmadan önce mevcut durumu kaydedin. Karşılaştırma yapamadığınız bir ayarın işe yaradığını bilemezsiniz.

• uptime ve vmstat 1: yük ortalaması, CPU bekleme, swap kullanımı.
• ss -s: açık soket sayıları ve durum dağılımı.
• sar (sysstat paketi): zaman içinde CPU, bellek, ağ kullanımı.
• Nginx için stub_status modülü: aktif bağlantı, okuma/yazma/bekleme sayıları.

Bu metrikleri değişiklik öncesi ve sonrası aynı koşullarda toplayın. Anlık top çıktısı tek başına yeterli değildir.

2. Dosya Tanıtıcı ve Süreç Limitleri

Yüksek eşzamanlılıkta en sık karşılaşılan hatalardan biri "too many open files" hatasıdır. Her TCP bağlantısı bir dosya tanıtıcısı tüketir.

systemd tabanlı sistemlerde servis limitleri /etc/systemd/system/<servis>.service.d/override.conf içinde tanımlanır:

[Service]
LimitNOFILE=65535

Değişiklikten sonra systemctl daemon-reload ve systemctl restart <servis> gerekir. Çalışan bir süreç için limiti prlimit --pid <pid> ile doğrulayabilirsiniz.

Dikkat: sysctl fs.file-max sistem geneli üst sınırdır; servis limitini bunun üzerine çıkarmak işe yaramaz. Ayrıca limiti gereğinden yükseğe çekmek bellek tüketimini artırabilir; gerçek eşzamanlı bağlantı sayınıza göre seçin.

3. Çekirdek ve Ağ Ayarları

/etc/sysctl.d/ altına bir dosya ekleyerek kalıcı ayar yapın; sysctl -w ile yapılan değişiklikler yeniden başlatmada kaybolur.

# /etc/sysctl.d/99-tuning.conf
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_local_port_range = 10240 65000
net.ipv4.tcp_tw_reuse = 1

• somaxconn: listen() çağrısının kabul ettiği maksimum bekleyen bağlantı sayısı. Nginx'teki backlog değeri bununla uyumlu olmalı.
• tcp_max_syn_backlog: SYN kuyruğu boyutu; SYN flood altında etkili olur.
• ip_local_port_range: giden bağlantılar için kullanılabilir port aralığı.
• tcp_tw_reuse: TIME_WAIT durumundaki soketlerin yeniden kullanımına izin verir; istemci yoğun sunucularda faydalıdır.

Bu değerleri uygulamadan önce sysctl -a ile mevcut değerlerini kontrol edin. Bazı dağıtımlar bu parametreleri farklı varsayılanlarla gelir.

4. Nginx Worker Yapılandırması

/etc/nginx/nginx.conf içindeki ana blok:

worker_processes auto;
worker_rlimit_nofile 65535;

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

• worker_processes auto: çekirdek sayısına göre worker açar.
• worker_rlimit_nofile: worker başına dosya tanıtıcı limiti. LimitNOFILE ile tutarlı olmalı; aksi halde Nginx başlangıçta uyarı verir.
• worker_connections: worker başına eşzamanlı bağlantı. Teorik üst sınır worker_processes × worker_connections; pratikte ters proxy durumunda her istemci bağlantısı ek bir upstream bağlantısı tüketir, yani gerçek kapasite yaklaşık yarısıdır.
• use epoll: Linux'ta varsayılan ve uygun olan yöntem; çoğu kurulumda açıkça yazmak gerekmez.

5. Bağlantı ve Zaman Aşımı Ayarları

http bloğunda:

http {
    keepalive_timeout 30s;
    keepalive_requests 1000;
    client_body_timeout 12s;
    client_header_timeout 12s;
    send_timeout 10s;
    reset_timedout_connection on;
}

• keepalive_timeout: istemci bağlantısının boşta kalma süresi. Çok yüksek değer boşta bağlantı biriktirir; çok düşük değer her istekte yeni el sıkışma maliyeti doğurur.
• reset_timedout_connection: zaman aşımına uğrayan bağlantının soketini RST ile kapatır, kaynakları daha hızlı serbest bırakır.

Bu değerler iş yükünüze göre ayarlanmalıdır; statik içerik sunan bir sunucu ile uzun süreli bağlantı tutan bir WebSocket sunucusu aynı ayarları kullanmaz.

6. Sıkıştırma ve Önbellekleme

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript application/xml;
gzip_vary on;

• gzip_comp_level: 5 civarı, CPU/maliyet dengesi için yaygın bir tercihtir; 9'a çıkmak genelde kazanç sağlamaz, CPU'yu boşa harcar.
• gzip_min_length: çok küçük yanıtları sıkıştırmak anlamsızdır.
• gzip_vary on: önbelleklerin sıkıştırılmış ve ham yanıtları ayrı tutmasını sağlar.

Statik dosyalar için expires ve Cache-Control başlıkları doğru ayarlanmazsa, istemci ve ara önbellekler her istekte sunucuya döner.

7. Ters Proxy ve Upstream

upstream backend {
    least_conn;
    server 127.0.0.1:8080;
    keepalive 32;
}

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

• keepalive 32: upstream'e açık tutulan boşta bağlantı havuzu; her istekte yeni TCP bağlantısı kurulmasını engeller. proxy_http_version 1.1 ve boş Connection başlığı bu havuzun çalışması için gereklidir.
• X-Forwarded-For başlığı uygulama tarafında güvenilir kaynaktan geldiğine göre yorumlanmalıdır; aksi halde istemci tarafından sahte değer gönderilebilir.

8. Güvenlik Etkileri

• X-Forwarded-For ve benzeri başlıkları yalnızca kendi proxy'nizden geldiğinde güvenilir sayın.
• server_tokens off; sürüm bilgisini gizler; güvenlik açıklarını kapatmaz, yalnızca bilgi ifşasını azaltır.
• autoindex on; dizin listelemeyi açar; üretimde varsayılan olarak kapalı tutun.
• Tuning amacıyla limitleri yükseltmek, SYN flood veya yavaş bağlantı (slowloris) saldırılarına karşı yüzeyi büyütebilir. limit_req ve limit_conn modülleriyle hız sınırlaması düşünün.
• tcp_tw_reuse yalnızca giden bağlantılar için geçerlidir ve NAT arkasındaki bazı senaryolarda beklenmedik davranışa yol açabilir; test edin.

9. Yaygın Hatalar

• Ölçüm yapmadan değerleri kopyalamak. Her iş yükü farklıdır.
• worker_connections ile worker_rlimit_nofile ve sistem limitlerini tutarsız bırakmak.
• sysctl -w ile yapılan değişikliğin kalıcı olduğunu sanmak.
• Tüm ayarları tek seferde değiştirmek; hangi değişikliğin etkili olduğunu ayırt edememek.
• Yapılandırmayı nginx -t ile test etmeden yeniden yüklemek.

10. Doğrulama

Değişiklikten sonra:

nginx -t
systemctl reload nginx

Ardından baseline metriklerini tekrar toplayın ve karşılaştırın. Beklenen davranış; hatasız yapılandırma testi, artan eşzamanlı bağlantı kapasitesi ve düşen hata oranıdır. Değişikliklerin etkisini görmek için yük altında test yapın; boşta duran bir sunucuda tuning sonuçları anlamlı görünmez.

Ayar değişikliklerini sürüm kontrolünde tutun ve her birini geri alınabilir biçimde uygulayın. Tuning tek seferlik bir iş değil, izleme ve ölçümle beslenen sürekli bir döngüdür.