sysctl ile Kernel Parametreleri Ayarlama

Linux çekirdeği, dağıtımı hangi donanıma kuracağınızı bilmediği için son derece muhafazakâr, "her yerde çalışır" varsayılan değerlerle gelir. Bu varsayılanlar 512 MB belleği olan küçük bir VPS ile 128 GB belleği olan bir veritabanı sunucusunu aynı şekilde ayarlar. İşte tam bu noktada sysctl devreye girer: sistemi yeniden derlemeden veya yeniden başlatmadan, çalışan çekirdeğin yüzlerce davranışını okuyabilir ve anında değiştirebilirsiniz. Ağ tamponlarından bellek yönetimine, dosya tanıtıcı limitlerinden TCP el sıkışma davranışına kadar birçok parametre bu araçla kontrol edilir.

Bu rehberde sysctl komutunun günlük kullanımını, yaygın olarak dokunulan parametreleri ve en önemlisi bu değişiklikleri sunucu yeniden başladığında kaybolmayacak şekilde kalıcı hale getirmeyi anlatacağız. Amacımız "internetten kopyalanan sihirli 40 satırlık sysctl.conf" kültüründen uzaklaşıp, her parametrenin ne işe yaradığını anlayarak, yüksek trafikli bir web veya uygulama sunucusu için güvenli ve gerekçeli değerler seçmenizi sağlamak. Yanlış bir değerin sunucuyu nasıl yavaşlatabileceğine veya erişilemez hale getirebileceğine de değineceğiz.

sysctl Nedir ve Nasıl Çalışır#

sysctl, çekirdeğin çalışma zamanı parametrelerini /proc/sys/ altındaki sanal dosya sistemi üzerinden yöneten bir arayüzdür. Buradaki her "dosya" aslında çekirdek içinde bir değişkene karşılık gelir. Örneğin /proc/sys/net/ipv4/ip_forward dosyasının içeriği 1 ise IP yönlendirme açık, 0 ise kapalıdır. sysctl komutu bu dosya yollarındaki / karakterlerini . ile değiştirerek daha okunabilir bir isimlendirme sunar; yani net.ipv4.ip_forward ile /proc/sys/net/ipv4/ip_forward aynı şeydir.

Parametreler mantıksal ailelere ayrılır. En sık dokunduğunuz aileler şunlardır:

Bu araç yalnızca çalışma zamanındaki değeri değiştirir. Yani bir parametreyi elle değiştirirseniz sunucu yeniden başladığında değer varsayılanına döner. Kalıcılık için değerleri yapılandırma dosyalarına yazmanız gerekir; bunu birazdan ele alacağız.

Değerleri Görüntüleme ve Anında Değiştirme#

Mevcut tüm parametreleri listelemek için -a bayrağını kullanırsınız. Çıktı çok uzun olacağı için genellikle bir arama ile birleştirilir:

# Tüm parametreleri listele
sudo sysctl -a

# Belirli bir aileyi filtrele
sudo sysctl -a | grep somaxconn
sudo sysctl net.ipv4.tcp_syncookies

# /proc üzerinden doğrudan okuma (aynı sonuç)
cat /proc/sys/net/core/somaxconn

Bir değeri anlık olarak değiştirmek için -w (write) bayrağını kullanırsınız. Bu değişiklik hemen etkin olur ancak kalıcı değildir:

# somaxconn değerini geçici olarak 1024 yap
sudo sysctl -w net.core.somaxconn=1024

# Aynı işlem doğrudan yazarak da yapılabilir
echo 1024 | sudo tee /proc/sys/net/core/somaxconn

Değişiklik yapmadan önce mutlaka mevcut değeri not alın. Böylece bir sorun çıkarsa geri dönebilirsiniz. Üretim sunucusunda "önce dene, sonra kalıcı yap" yaklaşımı en güvenli yoldur: parametreyi -w ile ayarlayın, birkaç saat gözlemleyin, davranış beklediğiniz gibiyse yapılandırma dosyasına yazın. Böyle çalıştığınızda kötü bir değer en fazla bir yeniden başlatmaya kadar sizinle kalır.

Değişiklikleri Kalıcı Hale Getirmek#

Kalıcı ayarların iki adresi vardır: klasik /etc/sysctl.conf dosyası ve daha modern /etc/sysctl.d/ dizini. Günümüzde en iyi uygulama, sysctl.conf dosyasına dokunmadan /etc/sysctl.d/ altında amaca yönelik ayrı dosyalar oluşturmaktır. Bu, ayarlarınızı dağıtımın veya paketlerin koyduğu değerlerden ayrı tutar ve geri almayı kolaylaştırır.

# Özel ayarlarınız için ayrı bir dosya oluşturun
sudo nano /etc/sysctl.d/99-cloutr-tuning.conf

Dosyanın içeriği parametre = değer formatında olur. # ile başlayan satırlar yorumdur ve her ayarın neden orada olduğunu yazmanız gelecekteki kendiniz için büyük bir iyilik olur:

# Yüksek trafikli web sunucusu ayarları
# Dinleme kuyruğunu büyüt (nginx/php-fpm için)
net.core.somaxconn = 4096

# Bekleyen SYN bağlantı kuyruğu
net.ipv4.tcp_max_syn_backlog = 8192

# Bellek takas eğilimini düşür
vm.swappiness = 10

# Sistem geneli dosya tanıtıcı limiti
fs.file-max = 2097152

Dosya adındaki sayı öneki (örneğin 99-) yükleme sırasını belirler; yüksek numaralı dosyalar sonra yüklenir ve önceki değerleri ezer. Bu yüzden kendi ayarlarınızı 99- gibi yüksek bir numarayla adlandırmak, dağıtımın varsayılanlarının üzerine yazmanızı garanti eder. Dosyayı kaydettikten sonra değişiklikleri yeniden başlatmadan uygulayın:

# Tek bir dosyayı uygula
sudo sysctl -p /etc/sysctl.d/99-cloutr-tuning.conf

# Tüm sistem sysctl dosyalarını yeniden yükle
sudo sysctl --system

sysctl --system komutu /etc/, /run/, /usr/lib/ gibi standart dizinlerdeki tüm .conf dosyalarını doğru sırayla okur ve uygular. Bir üretim sunucusunda değişiklik yaptıktan sonra bu komutu çalıştırıp çıktısında hata olup olmadığını kontrol etmek iyi bir alışkanlıktır; yanlış yazılmış bir parametre adı orada uyarı olarak görünür.

Ağ Parametreleri ve TCP Ayarları#

En çok kazanç sağlanan alan genellikle ağ katmanıdır çünkü çekirdeğin varsayılanları düşük eş zamanlı bağlantı sayısına göre ayarlanmıştır. Yoğun bir web sunucusunda aynı anda binlerce açık bağlantı olabilir ve varsayılan kuyruklar bu yükü kaldıramaz.

net.core.somaxconn parametresi, bir sokete gelen ve henüz accept() edilmemiş tamamlanmış bağlantıların kuyruğunun üst sınırıdır. Eski çekirdeklerde varsayılan 128'dir ve bu, ani trafik dalgalarında bağlantıların sessizce düşmesine yol açar. Nginx veya PHP-FPM gibi uygulamaların kendi backlog ayarları da bu değerle sınırlıdır; yani uygulamada backlog=65535 yazsanız bile çekirdek somaxconn değerinde kırpar. Bu yüzden ikisini birlikte düşünmek gerekir:

# nginx: dinleme backlog'u somaxconn ile uyumlu olmalı
server {
    listen 443 ssl backlog=4096;
    server_name ornek.clou.tr;
}

Aşağıdaki tablo yüksek trafikli bir sunucu için sık kullanılan ağ parametrelerini ve makul başlangıç değerlerini özetliyor. Bunlar mutlak doğrular değil; iş yükünüze göre gözlemleyerek ayarlamalısınız:

tcp_tw_reuse = 1 özellikle çok sayıda giden bağlantı açan uygulamalarda (ters vekil sunucular, API geçitleri) TIME-WAIT durumundaki soketlerin tükenmesini önler. Ancak geçmişte var olan tcp_tw_recycle parametresinden uzak durun; NAT arkasındaki istemcilerde bağlantı kopmalarına yol açtığı için modern çekirdeklerden tamamen kaldırılmıştır. Bunun gibi eski rehberlerde geçen ama artık zararlı olan ayarlar, "internetten kopyala yapıştır" yaklaşımının neden tehlikeli olduğunun en iyi örneğidir.

Modern bir Linux'ta tıkanıklık kontrol algoritması olarak BBR'yi etkinleştirmek, özellikle uzak coğrafyalara servis veren sunucularda çıktıyı belirgin biçimde artırabilir:

# BBR tıkanıklık kontrolü (çekirdek 4.9+)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

Bellek ve Dosya Limiti Parametreleri#

Bellek tarafında en çok konuşulan parametre vm.swappiness değeridir. Bu, çekirdeğin RAM yerine takas alanını (swap) ne kadar istekli kullanacağını 0 ile 100 arasında belirler. Masaüstü dağıtımlarında varsayılan 60'tır; bu, bir veritabanı veya web sunucusunda gereksiz yere sık takas yapılmasına ve gecikmelere neden olabilir. Sunucularda 10 gibi düşük bir değer, çekirdeği belleği son ana kadar tutmaya teşvik eder. Swap alanının nasıl oluşturulacağını ve boyutlandırılacağını swap alanı oluşturma rehberimizde ayrıntılı olarak ele aldık.

# Belleği agresif tutmayı tercih et
vm.swappiness = 10

# "Kirli" sayfaların diske yazılma eşikleri (yüzde)
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

vm.dirty_ratio ve vm.dirty_background_ratio, henüz diske yazılmamış "kirli" bellek sayfalarının hangi eşikte diske akıtılacağını belirler. Yüksek değerler yazma işlemlerini biriktirip ani ve uzun disk yazma dalgalarına yol açabilir; düşük değerler ise daha sık ama küçük yazmalar üretir. Yoğun yazma yapan veritabanı sunucularında bu iki değeri düşürmek, gecikme sıçramalarını düzeltir.

Dosya tanıtıcı limitleri, çok sayıda eş zamanlı bağlantı işleyen sunucularda kritik bir tıkanma noktasıdır. Her açık soket, her açık dosya bir tanıtıcı tüketir. fs.file-max sistem geneli üst sınırdır:

# Sistem geneli açık dosya sayısı limitini gör
sysctl fs.file-max

# Anlık kullanımı incele (ilk sayı = kullanımda)
cat /proc/sys/fs/file-nr

Burada önemli bir ayrım vardır: fs.file-max çekirdek düzeyinde tüm sistemin toplam sınırıdır, ancak her kullanıcı ve süreç için ayrıca ulimit (yani /etc/security/limits.conf içindeki nofile) sınırı geçerlidir. sysctl ile sistem limitini 2 milyona çıkarsanız bile, süreç başına ulimit -n değeri hâlâ 1024 ise uygulamanız "too many open files" hatası alır. Yüksek eş zamanlılık için ikisini birlikte yükseltmelisiniz:

# /etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576

Güvenlik Odaklı Kernel Parametreleri#

sysctl yalnızca performans için değil, sertleştirme (hardening) için de kullanılır. Ağ katmanında birkaç basit parametre, sunucunuzu yaygın saldırı ve keşif tekniklerine karşı belirgin biçimde dayanıklı kılar. Bu ayarlar sunucu sertleştirmenin doğal bir parçasıdır; konunun bütününü sunucu güvenliği temelleri rehberimizde ele alıyoruz.

# SYN flood saldırılarına karşı SYN çerezleri
net.ipv4.tcp_syncookies = 1

# Yönlendirilen (spoofed) paketleri logla ve reddet
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# ICMP yönlendirmelerini kabul etme (MITM riski)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Kaynak yönlendirmeli paketleri reddet
net.ipv4.conf.all.accept_source_route = 0

# Sahte broadcast ping'lerini yoksay
net.ipv4.icmp_echo_ignore_broadcasts = 1

tcp_syncookies, SYN flood tipi hacim saldırılarında bağlantı tablosunun dolmasını engelleyen hafif ama etkili bir korumadır. rp_filter ise ters yol doğrulaması yaparak kaynağı sahte olan (spoofed) paketleri düşürür. Bunlar birçok modern dağıtımda zaten açık gelir, ancak sunucuyu devraldığınızda değerleri doğrulamak iyi bir alışkanlıktır. Şunu da unutmayın: sysctl düzeyindeki bu korumalar bir güvenlik duvarının veya profesyonel bir DDoS kalkanının yerini tutmaz; hacimsel saldırılar için ağ kenarında çalışan bir DDoS koruma ve uygulama katmanı için bir WAF çözümü hâlâ gereklidir.

Değişiklikleri Doğrulama ve Geri Alma#

Bir ayarı uyguladıktan sonra gerçekten etkin olduğunu doğrulamak, "kaydettim ama işe yaramadı" tuzağından kurtulmanın tek yoludur. En temiz doğrulama, çalışan değeri okumaktır:

# Uygulanan değeri kontrol et
sysctl net.core.somaxconn
sysctl vm.swappiness

# Ağ istatistikleriyle sonucu gözlemle
ss -s
netstat -s | grep -i "listen\|overflow\|drop"

netstat -s çıktısında "listen queue overflow" veya "SYNs to LISTEN sockets dropped" gibi satırların artması, kuyruk parametrelerinizin hâlâ küçük olduğunun somut kanıtıdır; bu sayılar zamanla artmıyorsa ayarınız yeterlidir. Ölçmeden ayar yapmak karanlıkta ok atmaktır — daima bir metrik ile karar verin.

Bir şey ters giderse geri dönüş de kolaydır. sysctl.d altındaki dosyanızı silmek veya değiştirmek ve ardından sysctl --system çalıştırmak yeterlidir; en kötü durumda sunucuyu yeniden başlatmak tüm çalışma zamanı değişikliklerini varsayılana döndürür (çünkü kalıcı olan yalnızca dosyaya yazdıklarınızdır). Bu yüzden riskli bir değişikliği ilk kez denerken, sunucuya konsol veya VNC erişiminiz olduğundan emin olun; örneğin net.ipv4.ip_forward gibi bir ağ parametresini yanlış ayarlarsanız SSH bağlantınız kopabilir ve yalnızca panel üzerindeki konsoldan kurtulabilirsiniz. Sanal ve VDS sunucularımızda bu konsol erişimi panel içinden her zaman elinizin altındadır.

Sıkça Sorulan Sorular#

sysctl -w ile yaptığım değişiklik neden yeniden başlatınca kayboluyor?#

Çünkü sysctl -w yalnızca çalışan çekirdeğin bellekteki değerini değiştirir, hiçbir yere yazmaz. Sunucu yeniden başladığında çekirdek yeniden yüklenir ve tüm parametreler yapılandırma dosyalarındaki değerlerle (yoksa fabrika varsayılanlarıyla) sıfırlanır. Kalıcı olması için değeri /etc/sysctl.d/99-özel.conf gibi bir dosyaya parametre = değer biçiminde yazıp sudo sysctl --system ile uygulamanız gerekir.

vm.swappiness değerini kaça ayarlamalıyım?#

Genel bir web veya uygulama sunucusu için 10 civarı bir değer çoğu durumda idealdir; çekirdeği belleği son ana kadar RAM'de tutmaya teşvik eder ama swap'i tamamen devre dışı bırakmaz. Veritabanı sunucularında bazı yöneticiler 1 gibi çok düşük değerler tercih eder. Sıfır yapmak swap'i acil durum güvenlik ağı olmaktan çıkarabileceği için genellikle önerilmez; amaç swap'i "asla" değil, "yalnızca gerçekten gerektiğinde" kullandırmaktır.

Sistem geneli fs.file-max yüksek olduğu halde neden "too many open files" hatası alıyorum?#

Bu klasik bir karışıklıktır. fs.file-max tüm sistemin toplam tanıtıcı sınırıyken, her sürecin ayrıca ulimit -n (nofile) sınırı vardır ve uygulamanız bu ikinci sınıra takılır. Çözüm için /etc/security/limits.conf içinde nofile değerini yükseltmeniz, systemd ile çalışan servislerde ise ilgili servis biriminde LimitNOFILE ayarını da artırmanız gerekir. Yalnızca sysctl tarafını değiştirmek yeterli olmaz.

Yüksek trafik için internette bulduğum hazır sysctl.conf listesini doğrudan uygulayabilir miyim?#

Bunu kesinlikle önermiyoruz. Bu listelerin çoğu yıllar önce yazılmıştır ve tcp_tw_recycle gibi artık zararlı sayılan ve NAT arkasındaki kullanıcılarda bağlantı kopmasına yol açan parametreler içerir. Ayrıca değerler belirli bir donanım ve iş yükü için seçilmiştir; sizin sunucunuza uymayabilir. Doğru yaklaşım, her parametrenin ne işe yaradığını anlayıp önce sysctl -w ile deneyerek, metrikleri gözlemleyerek ilerlemektir.

sysctl değişikliğim başka bir dosya tarafından eziliyor gibi, nasıl anlarım?#

Aynı parametre birden fazla dosyada tanımlıysa, sysctl --system bunları dosya adına göre sayısal sırayla yükler ve son okunan kazanır. Hangi değerin nereden geldiğini görmek için sysctl --system çıktısını izleyebilir ya da grep -r parametre_adi /etc/sysctl.conf /etc/sysctl.d/ /usr/lib/sysctl.d/ komutuyla tüm tanımları tarayabilirsiniz. Kendi ayarlarınızı 99- gibi yüksek bir önekle adlandırmak, dağıtım varsayılanlarının üzerine yazmanızı garantiler.

Kapanış#

sysctl, doğru kullanıldığında bir sunucunun kapasitesini yeniden başlatmadan, tek bir kod satırı derlemeden belirgin biçimde artırabilen güçlü bir araçtır. Ancak gücü aynı zamanda riskini de barındırır: körü körüne kopyalanan değerler performansı düşürebilir, güvenlik açığı yaratabilir, hatta sunucuyu erişilemez kılabilir. Altın kural değişmez — her parametreyi anlayarak, önce geçici deneyip metrikle doğrulayarak ve yalnızca sonra kalıcı hale getirerek ilerleyin.

Bu ayarların gerçek karşılığını görmek için altında sağlam, esnek bir altyapı gerekir. Yüksek trafikli projeleriniz için tam root erişimi ve panel içi konsol sunan VDS ve sanal sunucu çözümlerimizi, işletim sistemi ve çekirdek düzeyindeki bakımı bizim üstlendiğimiz sunucu yönetimi hizmetimizi ya da daha hafif ihtiyaçlar için performansa göre ölçeklenen hosting paketlerimizi inceleyebilirsiniz. Kurulumdan sertleştirmeye kadar her adımda Clou.TR ekibi yanınızda.