Minecraft Sunucu Optimizasyonu: TPS’i 20’de Tutma Rehberi

Minecraft sunucu optimizasyonu, sunucunun her saniyede 20 tick üretmeye devam etmesini sağlamak için donanım, JVM ve yapılandırma katmanlarını birlikte ayarlama işidir. Doğru sıra şudur: önce ölçün, sonra en pahalı işi kesin, en son ince ayar yapın. Tick süresi 50 milisaniyenin altında kaldığı sürece TPS 20’dir; bu eşiği aşan her iş oyuncuya doğrudan gecikme olarak yansır.

Bu rehber, Batihost’ta çalışan Paper ve Purpur sunucularında karşılaştığımız gerçek darboğazları temel alır. Rastgele config kopyalamak yerine her ayarın neyi neden değiştirdiğini açıklıyoruz; çünkü bir sunucuda TPS’i kurtaran ayar, başka bir sunucuda oyun deneyimini bozup hiçbir kazanç sağlamayabilir. 26.2 “Chaos Cubed” sürümü üzerinde geçerli değerlerle ilerliyoruz.

Önce Ölçün: TPS, MSPT ve Gerçek Darboğaz#

Optimizasyonun ilk kuralı, neyi düzelttiğinizi bilmektir. Minecraft sunucusu saniyede 20 kez “tick” çalıştırır; her tick’e ayrılan bütçe 50 milisaniyedir. Tick 50 ms’in altında bitiyorsa sunucu kalan süreyi bekleyerek geçirir ve TPS tam 20 görünür. Tick 50 ms’i aşarsa TPS düşmeye başlar.

Bu yüzden TPS tek başına yanıltıcı bir metriktir. TPS 20 gösteren iki sunucudan biri tick’lerini 12 ms’de bitiriyor, diğeri 48 ms’de bitiriyor olabilir. İkincisi tek bir TNT patlamasıyla çöker. Bakmanız gereken değer MSPT, yani tick başına milisaniyedir.

Paper sunucularında bu değerleri konsoldan doğrudan okuyabilirsiniz:

tps
mspt
spark tps
spark health

spark health komutu TPS, MSPT, CPU kullanımı, bellek durumu ve disk doluluğunu tek ekranda verir. Sorunun CPU’dan mı bellekten mi geldiğini ayırt etmek için ilk bakılacak yer burasıdır. Derinlemesine analiz için spark profiler raporu okuma rehberini izleyin.

Donanım Katmanı: Tek Çekirdek Hızı Her Şeyi Belirler#

Minecraft’ın ana tick döngüsü tek bir iş parçacığında çalışır. Chunk yükleme, ağ ve dünya kaydetme ayrı iş parçacıklarına dağıtılmıştır ama entity mantığı, redstone, blok güncellemeleri ve eklentilerin çoğu tek çekirdekte sıraya girer. Bu, sunucu donanımı seçiminde tek belirleyici gerçeği ortaya koyar: çekirdek sayısı değil, saat hızı önemlidir.

32 çekirdekli 2,1 GHz bir sunucu işlemcisi, 8 çekirdekli 5,4 GHz bir Ryzen 9’un yanında Minecraft için belirgin şekilde yavaş kalır. Bu yüzden Batihost’un Minecraft paketleri yüksek frekanslı AMD Ryzen platformları üzerinde çalışır.

Disk tarafı sıklıkla gözden kaçar. Bir oyuncu yeni bir alana yürüdüğünde sunucu region/r.x.z.mca dosyalarından okuma yapar. HDD veya paylaşımlı SATA SSD üzerinde bu okuma milisaniyeler yerine onlarca milisaniye sürer ve doğrudan tick bütçesini yer. NVMe zorunludur, tercih değil.

JVM Katmanı: Heap Boyutu ve Çöp Toplayıcı#

Java sunucusunun bellek davranışı, TPS grafiklerinde düzenli aralıklarla görünen sivri düşüşlerin en yaygın sebebidir. Çöp toplayıcı duraklaması sırasında tick ilerleyemez; 200 ms süren bir toplama, 4 tick’in kaybolması demektir.

Xms ve Xmx daima eşit verilir#

JVM’in heap’i çalışma sırasında büyütüp küçültmesi gereksiz iştir. Başlangıç ve maksimum değerini eşitleyerek bu işi baştan ortadan kaldırın. Ayrıca işletim sistemine, chunk önbelleğine ve JVM’in heap dışı belleğine pay bırakın; paketinizin tamamını heap’e vermeyin.

Çöp toplayıcı seçimi: G1GC mi ZGC mi?#

Burada 2026’da en sık yapılan hatayı düzeltelim. Minecraft 26.1 changelog’undaki “garbage collection has been changed from G1GC to ZGC” satırı oyun istemcisini ilgilendirir; Minecraft Launcher’ın istemci JVM varsayılanı değişmiştir. Sunucu jar’ının launcher’ı yoktur, sunucunun çöp toplayıcısını tamamen sizin verdiğiniz bayraklar belirler. Aynı şekilde “varsayılan RAM 4 GB’a çıktı” değişikliği de istemci tahsisidir.

Pratik öneri nettir: 8-12 GB heap kullanıyorsanız G1GC ve Aikar’s Flags en iyi sonucu verir. PaperMC’nin resmî Aikar’s Flags dokümanı 26.x çıkışlarından sonra geri çekilmemiştir, bayrak seti hâlâ geçerlidir. 16 GB ve üzeri heap ile çalışıyorsanız ya da ağır modlu bir sunucu işletiyorsanız ZGC’yi değerlendirebilirsiniz.

8-12 GB heap için G1GC tabanlı başlatma satırı:

java -Xms10G -Xmx10G \
  -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M -XX:G1ReservePercent=20 \
  -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar paper-26.2.jar nogui

16 GB ve üzeri heap için ZGC alternatifi çok daha kısa yazılır:

java -Xms28G -Xmx28G \
  -XX:+UseZGC -XX:+AlwaysPreTouch \
  -XX:+PerfDisableSharedMem -XX:+DisableExplicitGC \
  -jar paper-26.2.jar nogui

Bellek ayarlarının tamamı ve her bayrağın ne yaptığı için RAM ayarları ve JVM flag rehberini okuyun.

server.properties: En Yüksek Etkili Üç Ayar#

Yapılandırma katmanında en büyük kazancı üç satır sağlar. Bunları doğru ayarlamadan diğer ince ayarlara geçmenin anlamı yoktur.

view-distance=8
simulation-distance=6
max-tick-time=60000
network-compression-threshold=256
sync-chunk-writes=false
entity-broadcast-range-percentage=80

view-distance oyuncuya gönderilen chunk yarıçapıdır ve maliyeti karesel artar. 10’dan 8’e inmek yüklü chunk sayısını yaklaşık üçte bir azaltır. simulation-distance ise entity ve blok mantığının işlediği yarıçaptır; asıl CPU maliyeti buradadır. Oyuncular manzarayı görmeye devam etsin ama uzaktaki mob’lar hesaplanmasın istiyorsanız view-distance’ı 8-10’da tutup simulation-distance’ı 5-6’ya çekin.

sync-chunk-writes=false chunk yazımını ana iş parçacığından çıkarır ve NVMe diskte belirgin fark yaratır. network-compression-threshold değerini 256 yapmak, aynı makinedeki proxy bağlantılarında gereksiz sıkıştırmayı azaltır.

Entity ve Mob Yükünü Kesmek#

Uzun süredir açık olan sunucularda tick süresinin büyük kısmını entity işlemleri yer. Mob çiftlikleri, yere düşmüş itemler, minecart’lar ve armor stand’ler birikir. Bunları üç ayrı yerden sınırlarsınız.

bukkit.yml içinde global spawn limitleri ve spawn aralığı:

spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  water-ambient: 2
  ambient: 1
ticks-per:
  animal-spawns: 400
  monster-spawns: 4
  autosave: 6000
chunk-gc:
  period-in-ticks: 600

spigot.yml içinde entity activation range ve birleştirme ayarları:

world-settings:
  default:
    entity-activation-range:
      animals: 16
      monsters: 24
      raiders: 40
      misc: 8
      water: 8
      villagers: 16
    merge-radius:
      item: 3.5
      exp: 4.0
    max-entity-collisions: 2
    item-despawn-rate: 4000
    arrow-despawn-rate: 300
    nerf-spawner-mobs: true

entity-activation-range, bir entity’nin oyuncudan ne kadar uzakta yapay zekâsının uyanık kalacağını belirler. Bu değerleri düşürmek uzaktaki mob’ların tick’lenmesini durdurur ve genellikle en hızlı hissedilen kazançtır. merge-radius ise yere düşen itemleri birleştirerek entity sayısını azaltır; item değerini 3.5’in üstüne çıkarmak oyuncuların item toplama hissini bozar.

Bu dosyaların satır satır açıklaması ve sunucu türüne göre önerilen değerler için paper.yml ve spigot.yml optimizasyon rehberine geçin.

Chunk Yönetimi ve Ön Üretim#

Yeni chunk üretmek, sunucunun tek tick içinde yapabileceği en pahalı işlerden biridir. Bir oyuncu at üstünde keşfe çıktığında MSPT anında iki katına çıkabilir. Çözüm, dünyayı oyuncular gelmeden önce üretmektir.

1. Dünya sınırını belirleyin#

   Sunucunuzun ihtiyacı olan alanı gerçekçi seçin. 50 oyunculu bir survival sunucusu için 10.000 blok yarıçap fazlasıyla yeterlidir.

   worldborder center 0 0
   worldborder set 20000

2. Chunk’ları önceden üretin#

   Chunky gibi bir eklenti ile sınır içindeki tüm chunk’ları oyuncular yokken üretin. Bu işlem saatler sürebilir, gece yapın.

   chunky world world
   chunky center 0 0
   chunky radius 10000
   chunky start

3. Üretim sonrası dünyayı optimize edin#

   Ön üretim biten dünyada boş bölge dosyalarını temizleyin ve saatler süren bu işin sonucunu kaybetmemek için tam yedek alın.

Ayrıca Nether ve End dünyalarını unutmayın. Nether’da bir blok 8 bloğa karşılık geldiği için 20.000 bloklu bir overworld sınırı, Nether’da 2.500 blok yarıçapla karşılanır.

Eklenti Denetimi: Sayı Değil Maliyet#

“Çok eklenti kurdum, sunucu yavaşladı” cümlesi çoğu zaman yanlış teşhistir. 40 hafif eklentili bir sunucu sorunsuz çalışırken, tek bir kötü yazılmış eklenti sunucuyu dize getirebilir. Ayırt etmenin tek yolu profil almaktır.

spark profiler --timeout 300 --thread server
spark profiler --info

Beş dakikalık profil sonunda çıkan bağlantıyı tarayıcıda açın ve çağrı ağacında eklenti paket adlarını arayın. Tick süresinin %10’undan fazlasını tek başına tüketen bir eklenti varsa alternatif arayın.

Tipik pahalı eklenti davranışları şunlardır:

Şüphelendiğiniz eklentiyi doğrudan üretim sunucusunda kaldırmayın. Aynı dünyanın kopyasıyla bir test örneği açın, eklentiyi orada devre dışı bırakın ve benzer yük altında ölçümü tekrarlayın.

Sunucu Yazılımı Seçimi#

Vanilla sunucu jar’ı optimizasyon yamaları içermez. Aynı donanımda Paper, vanilla’ya göre kat kat daha fazla oyuncu taşır çünkü chunk yükleme, entity işleme ve dünya kaydetme yolları yeniden yazılmıştır.

Eklenti tabanlı bir sunucu işletiyorsanız Paper taban, Purpur ise ek performans yamaları isteyenler için doğru tercihtir. Purpur zaten Pufferfish’in yamalarını içerdiği için ayrıca Pufferfish aramanıza gerek yok. Ayrıntılı karşılaştırma sunucu yazılımları karşılaştırma sayfasında.

Modlu sunucularda performans modları#

Fabric veya NeoForge kullanıyorsanız sunucu tarafına Lithium (genel oyun mantığı), FerriteCore (bellek) ve Krypton (ağ) modlarını ekleyin. Bunlar oyun içeriğini değiştirmez, yalnızca aynı işi daha ucuza yapar.

Disk, Kaydetme ve Yeniden Başlatma Düzeni#

Otomatik kaydetme (autosave) varsayılan olarak her 6000 tick’te, yani beş dakikada bir çalışır. Büyük dünyalarda bu işlem MSPT’de düzenli sıçramalara sebep olur. Paper bunu parçalara böler ama yine de disk hızı belirleyicidir.

chunk-loading-advanced:
  auto-config-send-distance: true
  player-max-concurrent-chunk-generates: 0
  player-max-concurrent-chunk-loads: 0
chunk-system:
  io-threads: 4
  worker-threads: 6

Günde bir kez planlı yeniden başlatma, birikmiş entity’leri ve bellek parçalanmasını sıfırladığı için pratikte en ucuz optimizasyondur. Oyuncu sayısının en düşük olduğu saati seçin ve uyarı verin.

say Sunucu 5 dakika icinde yeniden baslatilacak.
save-all
stop

Yeniden başlatmayı Linux’ta systemd servisi, Windows’ta ise Görev Zamanlayıcı ile otomatikleştirebilirsiniz; ayrıntılar systemd servisi rehberinde ve Windows servisi rehberinde.

Ağ Tarafı ve Oyuncu Deneyimi#

Sunucu tarafında TPS 20 olsa bile oyuncu takılma yaşayabilir. Bu durumda sorun ağdadır. Türkiye’deki oyuncu kitlesi için Türkiye lokasyonundaki bir sunucu, yurt dışı lokasyona göre 40-60 ms daha düşük ping verir ve bu fark PvP sunucularında doğrudan hissedilir.

Ağ tarafında kontrol edilecekler:

Lokasyon

Oyuncu kitlenize en yakın veri merkezi.

Port hızı

1 Gbit; chunk gönderimi ve resource pack dağıtımı için gerekli.

DDoS filtresi

Bot saldırıları tick’i değil bağlantı kabul kuyruğunu boğar; sağlayıcı seviyesinde filtre şarttır.

Proxy yapılandırması

Velocity kullanıyorsanız modern forwarding ve sıkıştırma eşiği doğru ayarlanmalı.

Lag türünü ayırt etmekte zorlanıyorsanız lag sorunu teşhis rehberi sunucu lag’i, ping lag’i ve istemci FPS düşüşünü ayrı ayrı ele alıyor.

Optimizasyon Kontrol Listesi#

Aşağıdaki sırayı takip ederseniz çoğu sunucuda birkaç saat içinde ölçülebilir kazanç elde edersiniz.

1. Temel ölçümü alın#

   spark health ve 5 dakikalık spark profiler raporuyla başlangıç durumunu kaydedin. Sonradan karşılaştıracaksınız.

2. Sunucu yazılımını ve Java’yı güncelleyin#

   Paper 26.2 veya Purpur 26.2 ile Temurin JDK 25 kullanın. Eski Java sürümüyle 26.x başlamaz.

3. Heap ve GC bayraklarını düzeltin#

   Xms = Xmx yapın, 8-12 GB heap için G1GC + Aikar’s Flags, 16 GB üzeri için ZGC değerlendirin.

4. view-distance ve simulation-distance ayarlayın#

   8 / 6 ikilisiyle başlayın, ölçün, gerekirse 7 / 5’e inin.

5. Entity limitlerini ve activation range’i uygulayın#

   spigot.yml ve bukkit.yml değerlerini yukarıdaki örneklere göre düzenleyin, sunucuyu yeniden başlatın.

6. Chunk ön üretimi yapın ve sınır koyun#

   Overworld, Nether ve End için ayrı ayrı. Sonrasında dünya boyutu sabitlenir.

7. Eklentileri profille eleyin#

   Pahalı eklentileri değiştirin veya yapılandırmalarını hafifletin. Kullanılmayan eklentiyi silin.

8. Günlük yeniden başlatma kurun#

   Düşük yoğunluklu saatte, oyuncu uyarısıyla birlikte.

9. Yeniden ölçün ve karşılaştırın#

   Aynı oyuncu yoğunluğunda ikinci profil alın. Kazanç yoksa değişikliği geri alın; kör ayar biriktirmeyin.

Ne Zaman Donanım Yükseltmeli?#

Config ayarları sınırsız kazanç sağlamaz. Aşağıdaki üç işaretten ikisi varsa optimizasyon değil daha güçlü donanım gerekir:

• spark raporunda tick süresinin büyük kısmı vanilla oyun mantığında (entity tick, block tick, chunk tick) geçiyor, eklentilerde değil.
• view-distance 6’ya indirildiği hâlde MSPT 40 ms’in altına inmiyor.
• Oyuncu sayısı arttıkça MSPT doğrusal değil hızlanarak yükseliyor; CPU tek çekirdek doyuma ulaşmış demektir.

Bu noktada yapılacak şey, tek çekirdek performansı daha yüksek bir platforma geçmektir. Yüksek frekanslı Ryzen VDS paketleri orta ölçekli sunucular için, dedicated sunucular ise 100+ oyunculu ağlar için doğru adımdır. Kaç GB RAM’e ihtiyacınız olduğunu hesaplamak için oyuncu sayısına göre RAM tablosuna bakabilirsiniz.

Özetle#

Minecraft sunucu optimizasyonu sihirli bir config dosyası değil, ölçüm-müdahale-yeniden ölçüm döngüsüdür. Tick bütçeniz 50 milisaniyedir; işiniz bu bütçeyi aşmadan mümkün olan en zengin oyun deneyimini sunmaktır.

Sırasıyla: yüksek saat hızlı Ryzen 9 ve NVMe disk seçin, heap’i Xms = Xmx olacak şekilde paketinize göre ayarlayın, 8-12 GB’ta G1GC + Aikar’s Flags kullanın, view-distance ve simulation-distance’ı gerçekçi değerlere çekin, entity activation range ile mob yükünü kesin, dünyayı önceden üretip sınırlayın ve eklentilerinizi profille denetleyin. Her adımdan sonra ölçün. Kazanç sağlamayan ayarı geri alın; sunucunuzda anlamı olmayan yüz satırlık config birikintisi, ileride teşhisi zorlaştırmaktan başka işe yaramaz.