CS2SERVER.ORG.TR
Kurulum rehberi
CS2 Sunucu Kurma

Ubuntu VDS’de Oyun Sunucusu Performansını Artırma

Varsayılan Ubuntu imajı masaüstü/genel sunucu profiline göredir. Oyun dedicated’ı ise düşük gecikme, ani CPU patlamaları ve kesintisiz uptime ister. Bu rehberde Ubuntu 22.04/24.04 VDS üzerinde disk, RAM, CPU, ağ, limit, güvenlik ve izleme adımlarını nedenleriyle uygulayacaksınız — CS2 dahil Source/Unity/Unreal/Java sunucularına uyar.

Panel ile kurAdım özetine git
Ubuntu VDS oyun sunucusu performans artırma rehberi: sysctl, disk, CPU governor ve ağ optimizasyonu
Ubuntu 22.04/24.04 VDS için uçtan uca performans sertleştirme

Bu rehberde neler var?

  • Swappiness’i düşürmek oyun sunucusunda stutter riskini azaltır.

  • noatime ve doğru I/O scheduler disk gecikmesini düşürür (NVMe: none).

  • CPU governor “performance” ani tick/frame patlamalarında daha stabildir.

  • UDP yoğun oyunlarda sysctl buffer ve conntrack ayarları kritiktir.

  • Aynı VDS’de çoklu sunucu için ayrı port + cgroup/systemd izolasyonu kullanın.

Neden varsayılan Ubuntu oyun sunucusu için yetmez?

VDS üzerine oyun sunucusu kurmak dakikalar sürer; onu gerçekten doğru çalıştırmak ayrı bir iştir. Bu rehber yalnızca CS2’ye özel değildir — Minecraft, Rust, ARK, Valheim, GMod, Palworld veya Source/Unity/Unreal/Java dedicated sunucularında da aynı işletim sistemi katmanı geçerlidir: swap, ağ yığını, dosya limitleri, CPU frekansı ve disk zamanlayıcısı.

  • Oyun sunucusu çok sayıda küçük UDP/TCP paketi ve düşük gecikme ister.

  • Round/chunk/spawn anlarında ani CPU patlamaları olur.

  • Kesintisiz uptime için log, yedek ve limit hijyeni şarttır.

Temel Sistem Hazırlığı

Temel Sistem Hazırlığı adımlarını root yetkisiyle, sırayla uygulayın. Kör kopyalamak yerine her değişikliğin nedenini bilin.

01

1 Güncelleme ve gereksiz paketlerin temizlenmesi

sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove -y
sudo apt autoclean
01

2 Kullanılmayan servisleri kapatın

VDS sağlayıcıları çoğu zaman genel amaçlı bir imajla teslim eder. Yazıcı servisi, bluetooth, modem yöneticisi gibi bileşenler oyun sunucusunda hiçbir işe yaramaz ama RAM ve arka plan CPU döngüsü tüketir. Çıktıyı inceleyin, tanımadığınız/gerekmeyen servisleri kapatın: Uyarı: systemd-resolved, systemd-networkd, cron, ssh gibi çekirdek servisleri kapatmayın; sunucuya erişiminizi kaybedebilirsiniz.

systemctl list-units --type=service --state=running
sudo systemctl disable --now cups.service 2>/dev/null
sudo systemctl disable --now bluetooth.service 2>/dev/null
sudo systemctl disable --now ModemManager.service 2>/dev/null
sudo systemctl disable --now avahi-daemon.service 2>/dev/null
01

3 Zaman senkronizasyonu

Saat kayması log tutarsızlığına, bazı античheat/lisans doğrulamalarında reddedilmeye ve dağıtık sunucu ortamlarında (cluster/master-slave) senkron sorunlarına yol açar. chronyc tracking çıktısında "System time" sapması birkaç milisaniyeyi geçmemeli.

sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
01

4 Otomatik güvenlik güncellemeleri

Bu, kritik güvenlik yamalarının sunucu sizin haberiniz olmadan aylarca güncellenmemesini önler — ama çekirdek (kernel) güncellemeleri genelde yeniden başlatma gerektirdiğinden, oyun sunucusu için bakım penceresi belirlemenizi öneririm. ---

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

Dosya Sistemi ve Disk Optimizasyonu

Dosya Sistemi ve Disk Optimizasyonu adımlarını root yetkisiyle, sırayla uygulayın. Kör kopyalamak yerine her değişikliğin nedenini bilin.

02

1 Mount seçenekleri: `noatime`

Varsayılan olarak Linux, her dosya okunduğunda bile erişim zamanını (atime) diske yazar. Oyun sunucusu binlerce küçük dosyaya (harita, doku, config, log) saniyede defalarca erişir; bu gereksiz yazma trafiği disk performansını düşürür. /etc/fstab dosyasını açın: İlgili satırın sonuna noatime ekleyin, örnek: Yeniden başlatmadan uygulamak için:

sudo nano /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /  ext4  defaults,noatime  0  1
02

2 Disk G/Ç zamanlayıcısı (I/O scheduler)

Hangi diski, hangi zamanlayıcıyla kullandığınızı görün: ROTA değeri 0 ise SSD/NVMe, 1 ise mekanik disktir (HDD'de oyun sunucusu barındırmak zaten önerilmez). - NVMe: none (kernel zaten paralel kuyruklama yapıyor, ek zamanlayıcı yük katıyor) - SATA SSD: mq-deadline (SSD'ye uygun, düşük gecikmeli) - HDD (varsa): bfq Kalıcı hale getirin:

lsblk -d -o NAME,ROTA
cat /sys/block/DISK_ADI/queue/scheduler
echo none | sudo tee /sys/block/nvme0n1/queue/scheduler
02

3 Dosya sistemi seçimi

Elinizde seçenek varsa (yeni bir disk formatlıyorsanız), ext4 çoğu senaryoda yeterlidir ve olgunluğu kanıtlanmıştır. Çok sayıda küçük dosyayla uğraşan (Minecraft chunk dosyaları, çok haritalı Source sunucuları) yüklerde xfs bazı testlerde biraz daha iyi ölçeklenir, ama fark genelde marjinaldir — mevcut ext4 kurulumunu değiştirmek için veri kaybı riski almaya değmez.

02

4 Disk alanı izleme

Dolan disk, sunucunun log yazamamasından crash'e kadar birçok soruna yol açar: ---

df -h
du -sh /home/*/  --max-depth=1 2>/dev/null | sort -rh | head -20

Bellek (RAM) Yönetimi

Bellek (RAM) Yönetimi adımlarını root yetkisiyle, sırayla uygulayın. Kör kopyalamak yerine her değişikliğin nedenini bilin.

03

1 Swappiness

Değer 0-100 arasıdır; 0'a yaklaştıkça kernel RAM'i swap'a atmaktan kaçınır. Oyun sunucularında 10 dengeli bir değerdir — tamamen 0 yapmak, ani bellek patlamalarında OOM-killer'ın süreci öldürme riskini artırabilir.

sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
03

2 Güvenlik amaçlı küçük bir swap dosyası

RAM'iniz sınırlıysa (2-4 GB), sunucunun aniden öldürülmesini önlemek için küçük bir swap dosyası tutun:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
03

3 Transparent Huge Pages (THP) — özellikle Java tabanlı sunucular için

THP, genel amaçlı sunucularda faydalı olsa da Java tabanlı oyun sunucularında (Minecraft gibi) GC (garbage collection) duraklamalarını uzatabilir. Minecraft veya başka bir JVM tabanlı sunucu barındırıyorsanız devre dışı bırakmayı değerlendirin: Kalıcı hale getirmek için GRUB'a boot parametresi ekleyin: Source motoru (CS2, GMod, TF2), Unity (Rust, Valheim) ve UE4 (ARK) tabanlı sunucularda bu adım genelde gerekli değildir; asıl fark Java tabanlı sunucularda görülür.

cat /sys/kernel/mm/transparent_hugepage/enabled
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
sudo nano /etc/default/grub
03

4 Bellek aşırı taahhüdü (overcommit)

Çok sayıda küçük process/thread açan oyun sunucularında (özellikle plugin yoğun kurulumlarda) varsayılan overcommit davranışı bazen "fork bombası" gibi görünen hatalı bellek reddine yol açabilir: ---

echo 'vm.overcommit_memory=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

CPU Optimizasyonu

CPU Optimizasyonu adımlarını root yetkisiyle, sırayla uygulayın. Kör kopyalamak yerine her değişikliğin nedenini bilin.

04

1 CPU governor: performance modu

Kalıcı hale getirin: Paylaşımlı vCPU planlarında (birçok bütçe VDS böyledir) bu ayar sağlayıcı hipervizör seviyesinde zaten sabitlenmiş olabilir; komut hata vermez ama pratik etkisi olmayabilir.

sudo apt install -y linux-tools-common linux-tools-generic
sudo cpupower frequency-set -g performance
sudo tee /etc/systemd/system/cpu-performance.service > /dev/null <<'EOF'
[Unit]
Description=CPU performance governor
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable --now cpu-performance.service
04

2 CPU izolasyonu / pinning (birden fazla çekirdekli sunucularda)

4+ çekirdekli bir VDS'de tek bir yoğun oyun sunucusu çalıştırıyorsanız, o process'i belirli çekirdeklere sabitleyerek diğer sistem görevlerinin (SSH, cron, log) araya girmesini engelleyebilirsiniz: Bu örnek process'i 2. ve 3. çekirdeğe sabitler; 0 ve 1 sistem görevlerine kalır. Kalıcı olması için systemd servis dosyanıza CPUAffinity=2 3 satırı ekleyebilirsiniz.

taskset -cp 2,3 $(pgrep -f srcds_run)
04

3 Mitigations (Spectre/Meltdown yamaları) — dikkatli kullanılacak bir takas

Kernel seviyesindeki CPU güvenlik yamaları (mitigations) bazı yüklerde %5-%15 arası performans kaybına yol açabilir. Bunu kapatmak performans kazandırır ama güvenlik riskini artırır — yalnızca izole, tek kiracılı (dedicated), güvenilir bir ağdaki VDS'de ve riski bilerek değerlendirilmelidir; paylaşımlı hosting/bulut ortamında önerilmez. Bu adımı atlamak, çoğu kullanıcı için doğru seçimdir — buraya sadece "ne olduğunu bilmeden internette gördüğüm komutu kopyalamayın" uyarısı için ekledim.

sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="... mitigations=off"
04

4 Process önceliği (nice / ionice)

Systemd servis dosyasında kalıcı hale getirin: ---

sudo renice -n -5 -p $(pgrep -f srcds_run)
sudo ionice -c 2 -n 0 -p $(pgrep -f srcds_run)
[Service]
Nice=-5
IOSchedulingClass=1
IOSchedulingPriority=2

Ağ (Network) Derin Optimizasyonu

Bu bölüm, oyun sunucusu performansında en çok fark yaratan kısımdır — çünkü oyun trafiği dosya indirmeden çok farklı bir profildir: çok sayıda küçük, sık, gecikmeye duyarlı paket. /etc/sysctl.conf dosyasını açın: A�ağıdaki blokları ekleyin ve neden var olduklarını da not düştüm: Uygulayın: BBR'nin aktif olduğunu doğrulayın: conntrack modülü yüklü değilse nf_conntrack_max satırı hata verir; önce modülü yükleyi

05

1 Çok çekirdekli sunucularda ağ kesmelerini (IRQ) dağıtın

Tek/iki çekirdekli küçük VDS planlarında gözle görülür etkisi olmaz, atlayabilirsiniz.

sudo apt install -y irqbalance
sudo systemctl enable --now irqbalance
05

2 MTU ve fragmentasyon kontrolü

Bazı VDS sağlayıcılarında (özellikle VPN/tünel tabanlı ağlarda) varsayılan MTU 1500'den düşük olabilir, bu da paket parçalanmasına ve gizli gecikmeye yol açar: Yanıt "packet too large" veriyorsa MTU'yu düşürmeniz veya sağlayıcınızla teyit etmeniz gerekir. ---

ip link show
ping -M do -s 1472 8.8.8.8

Dosya Tanımlayıcı ve Process Limitleri

Sunucuyu çalıştıran kullanıcı adını (steam, gameserver vb. — kendi kullanıcı adınızla değiştirin) kullanarak ekleyin: Systemd servisleri PAM limitlerini miras almaz, bu yüzden her servis dosyasında ayrıca tanımlamanız gerekir: Uygulamak için kullanıcı oturumunu kapatıp açın (veya sunucuyu yeniden başlatın), sonra doğrulayın: ---

Dosya Tanımlayıcı ve Process Limitleri — örnek komutlar
sudo nano /etc/security/limits.conf
steam soft nofile 65535
steam hard nofile 65535
steam soft nproc 65535
steam hard nproc 65535
[Service]
LimitNOFILE=65535
LimitNPROC=65535
ulimit -n

Birden Fazla Oyun Sunucusunu Aynı VDS'de İzole Barındırma

Tek bir VDS üzerinde birden fazla oyun sunucusu (örneğin bir CS2 + bir Minecraft + bir Rust) çalıştırıyorsanız, bunları izole etmeden çalıştırmak "gürültülü komşu" (noisy neighbor) sorununa yol açar: biri diğerinin CPU/RAM'ini yer, biri çökerse diğerini etkiler.

07

1 systemd resource kontrolü (cgroups v2) ile kaynak sınırlama

Her oyun sunucusu için ayrı bir systemd servisi tanımlayıp CPU ve bellek payını sabitleyin: CPUQuota=200% bu sunucunun en fazla 2 çekirdek eşdeğeri CPU kullanabileceği anlamına gelir; MemoryMax aşıldığında kernel process'i sınırlar/öldürür, böylece bir sunucunun bellek sızıntısı diğerlerini etkilemez. Etkinleştirin: Anlık kaynak kullanımını görmek için:

sudo nano /etc/systemd/system/cs2server.service
[Unit]
Description=CS2 Dedicated Server
After=network.target

[Service]
User=steam
WorkingDirectory=/home/steam/cs2server
ExecStart=/home/steam/cs2server/game/bin/linuxsteamrt64/cs2 -dedicated ...
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
CPUQuota=200%
MemoryMax=4G
MemoryHigh=3.5G
Nice=-5

[Install]
WantedBy=multi-user.target
07

2 Docker/konteyner alternatifi

Daha esnek izolasyon isteyenler için her oyun sunucusunu ayrı bir Docker konteynerine almak da yaygın bir yaklaşımdır (--cpus, --memory bayraklarıyla aynı sınırlamalar konteyner seviyesinde uygulanır). Bu, ağ portu yönetimini ve güncellemeleri kolaylaştırır ama ek bir soyutlama katmanı olduğundan saf bare-metal performansa göre %2-5 arası ek yük getirebilir — rekabetçi, milisaniye hassasiyetli bir CS2 sunucusu için genelde systemd + doğrudan binary tercih edilir; Minecraft/Rust gibi CPU-boun

Oyun Motoruna Göre Özel Ayarlar

Buraya kadarki her şey işletim sistemi seviyesindeydi. Şimdi motor bazlı ince ayarlara bakalım.

08

1 Source motoru (CS2, GMod, TF2, CSS)

- -tickrate CS2'de artık geçerli değildir (sub-tick modeli); CS:GO/Source1 tabanlı diğer oyunlarda (GMod, TF2) hâlâ geçerlidir, ihtiyacınız kadar yüksek tutup gereksiz yere abartmayın (64 tick çoğu topluluk sunucusu için yeterlidir, 128 tick CPU maliyeti daha yüksektir). - -nobreakpad parametresi (varsa) gereksiz crash-dump işlemesini kapatır, minör CPU tasarrufu sağlar. - Plugin yoğun sunucularda (SourceMod) her ek plugin round başına ölçülebilir CPU maliyeti ekler; kullanmadığınız pluginle

08

2 Java tabanlı sunucular (Minecraft)

- Aria2/Aikar's flags olarak bilinen, toplulukça test edilmiş G1GC ayarlarını kullanın; varsayılan JVM GC ayarları büyük heap'lerde uzun "stutter" duraklamalarına yol açar. - Heap boyutunu fiziksel RAM'in tamamına değil, işletim sistemine ve diğer servislere pay bırakacak şekilde ayarlayın (örnek: 8 GB RAM'de -Xmx6G, geri kalanı OS+disk cache'e). - aikar.co/mcflags.html tarzı güncel, motoru (Paper/Spigot/Fabric) esas alan flag setlerini tercih edin; internetteki eski/2015 tarihli flag listel

08

3 Unity tabanlı sunucular (Rust, Valheim, 7 Days to Die)

- Bu sunucular tek çekirdek darboğazına Source motoru kadar, bazen daha fazla girer; CPU seçerken çekirdek sayısından çok tek çekirdek saat hızına bakın. - Rust'ta harita boyutu (world size) doğrudan RAM ve başlangıç (generation) süresini etkiler; sunucu RAM'i harita boyutuna göre paylaştırın (büyük haritalarda 8 GB+ önerilir). - Oyuncu/entity sayısı arttıkça tick süresi doğrusal değil katlanarak artabilir; sunucu doluluğunu donanımla dengeli tutun.

08

4 Unreal Engine tabanlı sunucular (ARK: Survival Evolved/Ascended)

- ARK bilinen şekilde yüksek RAM tüketir (özellikle çok haritalı/cluster kurulumlarda); her harita instance'ı için ayrı RAM bütçesi ayırın. - -USEALLAVAILABLECORES gibi başlatma parametreleri çok çekirdekli sistemlerde faydalı olsa da, düşük çekirdek sayısında ters etki yaratabilir; test ederek karar verin. - Otomatik kaydetme (auto-save) aralığı disk G/Ç'yi doğrudan etkiler; SSD kullanmıyorsanız bu değeri düşürmeyin. ---

Güvenlik Sertleştirme

Performans kadar önemli olan başka bir konu: kötüye kullanılan/ele geçirilen bir sunucu, "performanslı" olmaktan çıkar.

09

1 SSH'ı sadece anahtarla erişime kapatın

Dikkat: Bu adımı uygulamadan önce SSH anahtarınızın çalıştığından emin olun; aksi halde sunucudan dışarıda kalabilirsiniz.

sudo nano /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
09

2 Minimal firewall

Yalnızca gerçekten kullandığınız oyun portlarını açın; "belki lazım olur" mantığıyla port açmayın.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 27015/tcp
sudo ufw allow 27015/udp
sudo ufw enable
09

3 Brute-force koruması

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
09

4 RCON/admin şifrelerini güçlü tutun ve erişimi kısıtlayın

RCON gibi uzaktan yönetim arayüzlerini mümkünse yalnızca belirli IP'lere (kendi yönetim IP'niz) açık tutun; genel internete açık bırakmayın. ---

İzleme, Log Yönetimi ve Otomatik Bakım

İzleme, Log Yönetimi ve Otomatik Bakım adımlarını root yetkisiyle, sırayla uygulayın. Kör kopyalamak yerine her değişikliğin nedenini bilin.

10

1 Temel izleme araçları

Daha görsel, sürekli izleme isteyenler için netdata gibi hafif bir dashboard aracı kurulabilir.

sudo apt install -y htop iftop iotop sysstat
htop
iftop -i eth0
iostat -x 2
10

2 Log rotasyonu

Sunucu logları zamanla diski doldurup çökmeye yol açabilir:

sudo nano /etc/logrotate.d/gameserver
/home/steam/cs2server/game/csgo/logs/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}
10

3 Otomatik yeniden başlatma / watchdog

Uzun süre açık kalan sunucularda bellek sızıntısı birikimini önlemek için düzenli, planlı yeniden başlatma yaygın bir pratiktir: Sunucu beklenmedik şekilde çökerse otomatik ayağa kalkması için systemd zaten Restart=on-failure ile bunu yapar (7. bölümdeki örnek servis dosyasına bakın). ---

sudo crontab -e
0 6 * * * systemctl restart cs2server.service

Yedekleme Stratejisi

Performans optimizasyonu, veri kaybını önlemenin yerini tutmaz. Minimum bir yedekleme rutini: Bu örnek, config ve plugin dosyalarını günlük yedekler, 14 günden eski yedekleri temizler. Kritik oyuncu verisi (Minecraft world, Rust save dosyası) barındırıyorsanız bu yedekleme kapsamını genişletin ve mümkünse yedekleri sunucu dışına (uzak depolama/S3 vb.) da kopyalayın. ---

Yedekleme Stratejisi — örnek komutlar
sudo mkdir -p /backup
sudo crontab -e
0 4 * * * tar -czf /backup/gameserver-$(date +\%F).tar.gz /home/steam/cs2server/game/csgo/cfg /home/steam/cs2server/game/csgo/addons
0 5 * * 0 find /backup -type f -mtime +14 -delete

Uygulama Öncesi/Sonrası Kontrol Listesi

- [ ] Sistem güncel, gereksiz servisler kapalı - [ ] noatime mount aktif, disk zamanlayıcısı donanıma uygun - [ ] vm.swappiness=10, gerekiyorsa swap dosyası tanımlı - [ ] Java tabanlı sunucu varsa THP madvise moduna alınmış - [ ] CPU governor performance - [ ] sysctl ağ ayarları uygulanmış, BBR aktif - [ ] ulimit -n en az 65535 - [ ] Her sunucu için CPU/bellek kotası tanımlı (cgroups/systemd) - [ ] SSH yaln

Sonuç: ölçün, değiştirin, tekrar ölçün

VDS oyun sunucusu performansında sihirli tek komut yoktur. Sysctl, disk, CPU governor ve limitleri uyguladıktan sonra önce/sonra gecikme, hitch ve CPU grafiğini karşılaştırın.

CS2 kurulum yolunuz için CS2 sunucu kurma, VDS hazırlığı için Linux VDS, sorun giderme için sunucu hataları ve konsol sözlüğü rehberlerine geçin.

Adım adım

Ubuntu VDS oyun sunucusu performans sertleştirme

Güncelleme ve servis sadeleştirmesinden disk, bellek, CPU, ağ ve limit ayarlarına kadar VDS’i oyun sunucusu profiline alın.

Tahmini okuma: ~11 dakika · Uygulama süresi rehber adımlarına göre değişir

  1. 01

    Sistemi güncelleyin ve gereksiz servisleri kapatın

    apt full-upgrade sonrası cups/bluetooth gibi kullanılmayan servisleri disable edin; SSH ve ağ servislerine dokunmayın.

  2. 02

    Disk: noatime ve I/O scheduler

    fstab’a noatime ekleyin; NVMe için none, SATA SSD için mq-deadline seçin.

  3. 03

    Bellek ve CPU profili

    Swappiness’i düşürün; CPU governor’ı performance yapın ve kalıcı hale getirin.

  4. 04

    Ağ sysctl ve dosya limitleri

    UDP buffer, somaxconn ve fs.file-max / nofile limitlerini oyun yüküne göre ayarlayın.

  5. 05

    Ölçün ve yedekleyin

    Önce/sonra ping-hitch-CPU metriklerini karşılaştırın; sysctl ve fstab yedeğini alın.

Sık sorulan sorular

Bu rehber hangi oyun sunucuları için geçerli?

Bölüm 1-7 ve 9-11 tamamen işletim sistemi seviyesindedir, TCP/UDP üzerinden çalışan her dedicated server için (CS2, Minecraft, Rust, ARK, Valheim, GMod, SA-MP dahil) geçerlidir. Bölüm 8 ise motora göre değişen ince ayarları ayrı ayrı ele alır.

Tüm bu ayarları tek seferde mi uygulamalıyım?

Hayır. sysctl ağ ayarları ve CPU governor en hızlı, en ölçülebilir farkı yaratanlardır — oradan başlayın. Diğer adımları kademeli ekleyip her birinden sonra sunucuyu birkaç gün canlı trafikte gözlemleyin.

mitigations=off gibi riskli ayarları kullanmalı mıyım?

Genel kullanıcılar için önerilmez. Yalnızca izole, güvenilir, tek kiracılı bir ortamda ve riski bilerek tercih edilmelidir.

Zayıf donanımlı (1-2 çekirdek, 2 GB RAM) bir VDS'de bu ayarlar yeterli mi?

Kısmen. İşletim sistemi ayarları darboğazı azaltır ama fiziksel donanım sınırını aşamaz; oyuncu sayısı arttıkça gerçek çözüm CPU/RAM yükseltmesidir.

Birden fazla oyun sunucusunu aynı VDS'de barındırmak performansı düşürür mü?

Kaynak izolasyonu (7. bölüm) yapılmazsa evet, "gürültülü komşu" etkisiyle düşürür. cgroups/systemd ile CPU ve bellek kotası tanımlarsanız etkisi büyük ölçüde kontrol altına alınır. --- Bu adımların her biri tek başına küçük bir kazanım gibi görünebilir, ama birlikte uygulandığında toplamda gözle görülür bir fark yaratır — özellikle yoğun saatlerde ve oyuncu sayısı arttıkça. Değişiklik yapmadan önce ve sonra ölçüm almadan "iyileşti" demeyin; `htop`, `iftop`, sunucunun kendi tick/frame istatistikl

Kuruluma hazır mısınız?

Kendi VDS’inizi CS2SERVER.ORG.TR Panel’e bağlayın; SteamCMD, servis ve temel yönetimi yönlendirilmiş akışla tamamlayın.

Hizmet Paneline Git