Kernel Parametreleri ile Sistem Optimizasyonu: sysctl Rehberi

Sunucularınızın performansını artırmak için her zaman daha pahalı donanım almak zorunda değilsiniz. Linux çekirdeği, doğru parametrelerle ayarlandığında inanılmaz bir performans artışı sağlayabilir. sysctl tam da bu iş için tasarlanmış, kernel parametrelerini çalışma zamanında değiştirmenize olanak tanıyan güçlü bir araçtır. Bu yazıda sysctl’in ne olduğunu, nasıl kullanıldığını ve gerçek dünya senaryolarında hangi parametrelerin fark yarattığını detaylıca ele alacağız.

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

sysctl, /proc/sys/ dizini altındaki kernel parametrelerini okuyup yazmanızı sağlayan bir araçtır. Linux çekirdeği, sistem davranışını kontrol eden yüzlerce parametre sunar ve bunların büyük çoğunluğu sistem yeniden başlatılmadan değiştirilebilir. Bu özellik, production ortamlarında canlı testler yapmanıza imkan tanır.

/proc/sys/ altındaki yapıya bakacak olursak:

• /proc/sys/kernel/ – Çekirdek parametreleri
• /proc/sys/net/ – Ağ yığını parametreleri
• /proc/sys/vm/ – Sanal bellek parametreleri
• /proc/sys/fs/ – Dosya sistemi parametreleri

Değişiklikler iki şekilde yapılabilir: geçici (reboot ile sıfırlanır) veya kalıcı (/etc/sysctl.conf veya /etc/sysctl.d/ altındaki dosyalar aracılığıyla). Production’da bir şeyi test ederken önce geçici yapmanızı, sonuçlardan memnun kaldığınızda kalıcı hale getirmenizi şiddetle tavsiye ederim.

Temel sysctl Komutları

# Tüm parametreleri listele
sysctl -a

# Belirli bir parametreyi oku
sysctl net.ipv4.tcp_fin_timeout

# Parametre değerini değiştir (geçici)
sysctl -w net.ipv4.tcp_fin_timeout=30

# Kalıcı değişiklikler için sysctl.conf'u yükle
sysctl -p /etc/sysctl.conf

# Belirli bir dosyadan parametreleri yükle
sysctl -p /etc/sysctl.d/99-custom.conf

# Parametre arama
sysctl -a | grep tcp_mem

Kalıcı değişiklikler için /etc/sysctl.d/ dizini altında ayrı dosyalar oluşturmanızı öneririm. Bu sayede hangi değişikliği neden yaptığınızı takip etmek çok daha kolay olur.

Ağ Performansı Optimizasyonu

Ağ parametreleri, özellikle yüksek trafik alan web sunucuları ve veritabanı sunucuları için kritik öneme sahiptir. Yanlış ayarlanmış ağ parametreleri, bağlantı zaman aşımlarına, paket kayıplarına ve genel performans sorunlarına yol açar.

TCP/IP Yığını Optimizasyonu

Yüksek trafikli bir web sunucusunda karşılaşılan en yaygın sorunlardan biri TIME_WAIT durumundaki bağlantıların birikmesidir. Bunu şöyle düşünün: her HTTP bağlantısı kapandığında TCP, 2*MSL (Maximum Segment Lifetime) süresince TIME_WAIT durumunda bekler. Çok sayıda kısa ömürlü bağlantıda bu durum port tükenmesine neden olabilir.

# /etc/sysctl.d/99-network-performance.conf

# TIME_WAIT soketlerini yeniden kullan
net.ipv4.tcp_tw_reuse = 1

# FIN_WAIT2 timeout süresini kısalt (varsayılan: 60)
net.ipv4.tcp_fin_timeout = 30

# TCP keepalive ayarları
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15

# SYN backlog kuyruğunu artır (DDoS koruması ve yüksek trafik için)
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 65535

# Ephemeral port aralığını genişlet
net.ipv4.ip_local_port_range = 10000 65535

# TCP receive/send buffer boyutları
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Gerçek bir senaryoyu paylaşayım: Bir e-ticaret müşterisinin Nginx sunucusunda kampanya dönemlerinde bağlantı hataları alıyorduk. ss -s çıktısına baktığımızda binlerce TIME_WAIT soketi görüyorduk. Yukarıdaki parametreleri uyguladıktan sonra sorun tamamen ortadan kalktı.

Ağ Buffer ve Queue Ayarları

# Network interface receive queue uzunluğu
net.core.netdev_max_backlog = 50000

# TCP okuma/yazma buffer otomatik ayarını etkinleştir
net.ipv4.tcp_moderate_rcvbuf = 1

# SYNACK yeniden deneme sayısını azalt
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 3

# TCP Fast Open'ı etkinleştir (sunucu ve istemci için)
net.ipv4.tcp_fastopen = 3

# Ağ gecikmesini azaltmak için Nagle algoritması
net.ipv4.tcp_low_latency = 1

Bellek Yönetimi Optimizasyonu

Sanal bellek parametreleri, sistemin RAM’i nasıl kullandığını doğrudan etkiler. Özellikle veritabanı sunucularında yanlış ayarlanmış vm parametreleri ciddi performans sorunlarına yol açabilir.

Swappiness ve Bellek Baskısı

vm.swappiness parametresi, çekirdeğin swap alanını ne kadar agresif kullanacağını belirler. 0 ile 100 arasında değer alır. Veritabanı sunucularında (özellikle MySQL/PostgreSQL) bu değerin düşük tutulması kritiktir.

# /etc/sysctl.d/99-memory.conf

# Veritabanı sunucuları için swap kullanımını minimize et (varsayılan: 60)
vm.swappiness = 10

# Dirty page yazma eşikleri (yoğun I/O için optimize et)
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# Dirty page yazma gecikmeleri
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500

# Overcommit politikası (0: heuristic, 1: her zaman izin ver, 2: hiçbir zaman)
vm.overcommit_memory = 1

# Minimum free memory (OOM killer'ı erken tetiklemek için)
vm.min_free_kbytes = 65536

# Transparent Huge Pages için
vm.nr_hugepages = 0

vm.dirty_ratio ve vm.dirty_background_ratio parametrelerine özel dikkat etmenizi öneririm. dirty_background_ratio, kernel’ın arka planda disk yazma işlemini başlatacağı eşiği belirler. dirty_ratio ise yazma işlemini bloke edeceği üst sınırı gösterir. Yüksek I/O workload’larında bu değerleri düşük tutmak, ani I/O spike’larını önler.

Büyük Bellek Sayfaları (Huge Pages)

Büyük bellek sayfaları (2MB veya 1GB), özellikle büyük veritabanları ve SAP gibi kurumsal uygulamalar için TLB (Translation Lookaside Buffer) miss sayısını dramatik şekilde azaltır.

# Mevcut huge pages durumunu kontrol et
grep -i huge /proc/meminfo

# Huge pages yapılandırması
sysctl -w vm.nr_hugepages=512

# Huge pages pool boyutu
sysctl -w vm.nr_overcommit_hugepages=128

# Kalıcı yapılandırma için
echo "vm.nr_hugepages = 512" >> /etc/sysctl.d/99-hugepages.conf

PostgreSQL için huge pages kullanımı şöyle etkinleştirilir: postgresql.conf içinde huge_pages = on yapıp yeterli huge page rezerve etmeniz gerekir. 16GB shared_buffers için yaklaşık 8200 huge page ayırmanız gerekebilir.

Dosya Sistemi ve I/O Parametreleri

Yüksek yük altında çalışan sunucularda dosya tanımlayıcı limitleri ve inotify limitleri sıkça karşılaşılan sorun kaynaklarıdır.

Dosya Tanımlayıcı Limitleri

# /etc/sysctl.d/99-filesystem.conf

# Maksimum açık dosya tanımlayıcı sayısı
fs.file-max = 2097152

# İnotify limitleri (Elasticsearch, Kafka gibi uygulamalar için kritik)
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512
fs.inotify.max_queued_events = 32768

# AIO maksimum request sayısı
fs.aio-max-nr = 1048576

Elasticsearch kullananlar bu parametreye özellikle dikkat etmeli. Elasticsearch, her index shard için çok sayıda dosya izler ve varsayılan max_user_watches değeri olan 8192 çoğu zaman yetersiz kalır. Bu durumda Elasticsearch loglarında too many open files veya inotify limit reached hatalarını görürsünüz.

Kernel ve Güvenlik Parametreleri

Güvenlik ile performans arasında denge kurmak sysadmin’lerin en önemli görevlerinden biridir. Bazı güvenlik parametreleri performansı etkilerken, bazı performans optimizasyonları güvenlik açıklarına yol açabilir.

Temel Kernel Güvenlik Ayarları

# /etc/sysctl.d/99-security.conf

# IP forwarding (router değilseniz kapalı tutun)
net.ipv4.ip_forward = 0

# Source routing'i devre dışı bırak
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# ICMP redirect'leri devre dışı bırak
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# Spoofed paketlere karşı reverse path filtering
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# SYN flood koruması
net.ipv4.tcp_syncookies = 1

# Broadcast ICMP'yi yoksay
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Bogus ICMP error yanıtlarını yoksay
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Kernel pointer'larını gizle
kernel.kptr_restrict = 2

# dmesg erişimini kısıtla
kernel.dmesg_restrict = 1

# Core dump'ları kısıtla
fs.suid_dumpable = 0

# Magic SysRq tuşunu devre dışı bırak (production için)
kernel.sysrq = 0

NUMA ve CPU Optimizasyonu

Çok soketli sunucularda NUMA (Non-Uniform Memory Access) farkındalığı kritik öneme sahiptir. Yanlış NUMA politikası ciddi latency sorunlarına yol açabilir.

# NUMA balancing etkinleştir
kernel.numa_balancing = 1

# Scheduler optimizasyonu
kernel.sched_migration_cost_ns = 5000000
kernel.sched_autogroup_enabled = 0

# Semaphore limitleri (Oracle DB için genellikle artırılması gerekir)
kernel.sem = 250 32000 100 128

# Shared memory limitleri
kernel.shmmax = 68719476736
kernel.shmall = 4294967296

Gerçek Dünya Senaryoları ve Profiller

Farklı workload tiplerine göre hazırladığım başlangıç profillerini paylaşıyorum. Bunları doğrudan kullanmak yerine kendi ortamınıza göre test ederek uyarlamanızı öneririm.

Yüksek Trafikli Web Sunucusu Profili

Günlük milyonlarca istek alan bir Nginx/HAProxy sunucusu için:

# /etc/sysctl.d/99-webserver.conf
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_syn_backlog = 16384
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
vm.swappiness = 10
fs.file-max = 1000000

BBR (Bottleneck Bandwidth and RTT) congestion control algoritması, özellikle yüksek bant genişliği ve yüksek latency’li bağlantılarda çok iyi sonuçlar verir. Google’ın geliştirdiği bu algoritma, 2017’den itibaren Linux kernel’ına dahil edilmiştir.

Veritabanı Sunucusu Profili (PostgreSQL/MySQL)

# /etc/sysctl.d/99-database.conf
vm.swappiness = 5
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
vm.nr_hugepages = 2048
kernel.shmmax = 137438953472
kernel.shmall = 33554432
kernel.sem = 250 32000 100 128
net.ipv4.tcp_keepalive_time = 200
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 20
fs.file-max = 500000
vm.min_free_kbytes = 131072

Bir üretim ortamında PostgreSQL sunucusunda periyodik performans düşüşleri yaşıyorduk. iostat ve vmstat çıktılarına bakıldığında ani ve uzun disk write spike’ları görünüyordu. vm.dirty_ratio değeri varsayılan olan 20’deydi. Bunu 10’a, vm.dirty_background_ratio‘yu ise 5’ten 3’e düşürdükten sonra spike’lar küçüldü ve daha sık ama kısa süren write işlemlerine dönüştü. Uygulama latency’si %30 iyileşti.

Parametreleri İzleme ve Doğrulama

Değişiklik yaptıktan sonra etkilerini ölçmezseniz, neyin işe yarayıp neyin yaramadığını bilemezsiniz. İşte bu noktada bazı araçlar devreye giriyor.

# Ağ istatistiklerini izle
ss -s
ss -tn state time-wait | wc -l

# Bellek durumunu kontrol et
cat /proc/meminfo | grep -E "Dirty|Writeback|Hugepage"

# Mevcut sysctl değerlerini dışa aktar (baseline için)
sysctl -a > /tmp/sysctl-before-$(date +%Y%m%d).txt

# Değişiklikten sonra karşılaştır
sysctl -a > /tmp/sysctl-after-$(date +%Y%m%d).txt
diff /tmp/sysctl-before-*.txt /tmp/sysctl-after-*.txt

# TCP istatistikleri
netstat -s | grep -E "failed|overflow|drop|reject"

# Kernel ring buffer'ı izle (parametre değişikliklerinin etkisi için)
dmesg -w | grep -E "TCP|memory|OOM"

Değişikliklerden önce mutlaka bir baseline oluşturun. Bunu bir alışkanlık haline getirin. Production’da “sanırım iyileşti” demek yerine sayılarla konuşmak her zaman daha güvenilirdir.

Yapılandırma Yönetimi İpuçları

Değişiklikleri Organize Etme

# Değişiklikleri kategorilere ayır
ls /etc/sysctl.d/
# 99-network.conf
# 99-memory.conf  
# 99-security.conf
# 99-database.conf

# Tüm sysctl.d dosyalarını uygula
sysctl --system

# Belirli bir dosyayı uygula ve verbose çıktı al
sysctl -p /etc/sysctl.d/99-network.conf --dry-run 2>/dev/null || sysctl -p /etc/sysctl.d/99-network.conf

Ansible veya Salt gibi configuration management araçları kullanıyorsanız, sysctl modülleri bu değişiklikleri idempotent şekilde yönetmenizi sağlar. Ansible’da ansible.posix.sysctl modülü ile hem geçici hem kalıcı değişiklik yapabilirsiniz.

Rollback Stratejisi

Production’da bir değişiklik yapacaksanız her zaman geri alma planınız olsun:

# Mevcut değerleri kaydet
sysctl -a 2>/dev/null | grep "vm.|net.ipv4.tcp" > /tmp/sysctl-backup-$(date +%Y%m%d-%H%M).txt

# Değişikliği uygula
sysctl -w vm.swappiness=10

# İstenen süre izle, sorun varsa geri al
sysctl -w vm.swappiness=60  # eski değere dön

# Kalıcı değişiklikleri geri almak için
cp /etc/sysctl.conf /etc/sysctl.conf.bak
# Değişiklik yap
sysctl -p  # veya --system

Dikkat Edilmesi Gereken Noktalar

Sysctl parametrelerini değiştirirken bazı önemli noktalara dikkat etmek gerekir:

• Kernel versiyonu farkları: Bazı parametreler belirli kernel versiyonlarında kaldırılmış veya ismi değiştirilmiş olabilir. sysctl -a 2>&1 | grep unknown ile geçersiz parametreleri tespit edebilirsiniz.
• Workload’a özgü test: Bir parametre bir workload için mükemmelken, başka bir workload için zararlı olabilir. Her değişikliği kendi ortamınızda test edin.
• OOM Killer davranışı: vm.overcommit_memory = 1 agresif overcommit’e izin verir. Container ortamlarında bu bazen beklenmedik OOM Kill durumlarına yol açabilir.
• Container ve VM farkları: Container ortamlarında (Docker, LXC) bazı network parametreleri host’tan inherit edilir ve container içinden değiştirilemez. Kubernetes’te bazı parametreler securityContext ile yönetilir.
• Reboot sonrası doğrulama: Kalıcı yaptığınızı düşündüğünüz değişikliklerin reboot sonrası gerçekten uygulandığını kontrol edin. Bazı servisler (systemd-sysctl) bu dosyaları belirli bir sırayla yükler.

Sonuç

sysctl parametreleri, Linux sistem yönetiminin en güçlü ama aynı zamanda en riskli araçlarından biridir. Doğru kullanıldığında ekstra donanım maliyeti olmadan ciddi performans kazanımları sağlayabilir. Ancak “kopyala yapıştır” yaklaşımıyla yapılan değişiklikler, production ortamında beklenmedik sorunlara kapı aralayabilir.

Benim önerim şu: her değişikliği küçük adımlarla yapın, ölçün, sonra bir sonraki adıma geçin. Bir sunucuda mükemmel sonuç veren parametreler, farklı workload veya donanımda tamamen farklı davranabilir. Baseline metrikleri alın, değişiklik yapın, karşılaştırın. Sonuçlar beklendiği gibi değilse geri dönmekten çekinmeyin.

Son olarak, bu yazıda bahsettiğim değerler başlangıç noktası olarak düşünülmelidir. Kendi ortamınızın ihtiyaçlarını anlamak için perf, bpftrace, strace ve vmstat gibi araçlarla sisteminizi iyi tanımanız gerekir. Sisteminizi ne kadar iyi tanırsanız, parametreleri o kadar doğru ayarlayabilirsiniz.