Minecraft Sunucu Optimizasyonu ve TPS Çözümü

Minecraft sunucusunda optimizasyon, ayar dosyalarına rastgele değer yapıştırmak değil, önce ölçüp sonra tek tek müdahale etmektir: hedef 20.0 TPS ve tick başına 50 milisaniyenin altında bir MSPT değeridir — MSPT 50 ms'nin altında kaldığı sürece sunucunuz 20 TPS'te kalır. Lag yaşandığında RAM yükseltmek çoğu zaman hiçbir şey değiştirmez, çünkü sorun neredeyse her zaman dört yerden birindedir: varlık (entity) yükü, chunk üretimi, redstone ya da çöp toplama duraklamaları. Bu rehber, sorunu bulmayı ve doğru ayarı doğru yerde değiştirmeyi anlatıyor.

Önce ölçün: TPS ve MSPT ne anlatıyor?

İki rakamı ayırt etmek, optimizasyonun tamamının temelidir.

• TPS (Ticks Per Second): Sunucunun saniyede kaç tick işlediği. Hedef 20.0. Altına düştüğünde oyun içi zaman yavaşlar; oyuncular bunu gecikme ve ışınlanma olarak yaşar.
• MSPT (Milliseconds Per Tick): Bir tick'in işlenmesi kaç milisaniye sürüyor. Hedef 50 ms'nin altı. Çünkü 20 TPS demek, her tick için 50 ms bütçe demektir.

Aradaki ilişki şudur: MSPT 50 ms'yi aşmadığı sürece TPS 20'de kalır. Bu yüzden asıl izlenmesi gereken rakam MSPT'dir — TPS düşmeye başladığında iş işten geçmiştir, ama MSPT 45 ms'ye tırmandığında hâlâ vaktiniz vardır.

Bir başka önemli ayrım: TPS düşük ama oyuncu ping'i normalse sorun sunucu işleme tarafındadır. Ping de yüksekse ağ ya da lokasyon tarafına bakmanız gerekir.

Spark ile teşhis: tahmin etmeyi bırakın

spark, Minecraft sunucuları için profilleme ve izleme aracıdır ve optimizasyona buradan başlanır. Temel komutları:

• /spark tps — anlık TPS ve CPU kullanımı.
• /spark health — TPS, CPU, bellek ve disk kullanımını içeren genel sağlık raporu.
• /spark profiler — CPU ve bellek kullanımını örnekleyip ayrıntılı bir rapor üretir; sonuç çevrimiçi görüntüleyiciye yüklenir.
• /spark tickmonitor — eşiği aşan tek tek tick'leri izler, ani sıçramaları yakalamak için idealdir.

Doğru kullanım için iki kural var. Birincisi: profillemeyi sunucu boşken değil, lag yaşanırken yapın. Sessiz bir sunucuda alınan rapor size hiçbir şey söylemez.

İkincisi ve daha önemlisi: alev grafiğinde (flame graph) geniş bir dal, o kodun bozuk olduğunun kanıtı değildir — yalnızca örneklenen zamanın orada geçtiğini gösterir. Bir plugin geniş görünüyor olabilir çünkü asıl işi o yapıyordur. Grafiği her zaman o sıradaki oyuncu aktivitesiyle birlikte yorumlayın: kim neredeydi, hangi farm çalışıyordu, biri yeni bölgeye mi uçuyordu?

TPS'i düşüren 4 ana sebep

1. Varlık (entity) yükü

Profilleme raporunda ServerLevel#tickEntities CPU kullanımının %40'ını aşıyorsa suçlu mob, köylü ve item yığınlarıdır. En sık karşılaşılan iki kaynak: köylü yol bulma (pathfinding) hesaplamaları ve büyük hopper dizileri.

2. Chunk üretimi

Bir oyuncu üretilmemiş araziye doğru uçtuğunda sunucu gerçek zamanlı olarak chunk üretmek ve diske yazmak zorunda kalır. MSPT bu anlarda belirgin biçimde sıçrar. Belirtisi nettir: lag, oyuncular keşfe çıktığında başlar, normal oyunda yoktur.

3. Redstone

Vanilla redstone, zincirleme ışık ve blok güncellemeleri tetikler. Büyük redstone düzeneklerinin olduğu sunucularda tek başına ciddi yük üretir.

4. Çöp toplama (GC) duraklamaları

Belirtisi çok karakteristiktir: düzenli aralıklarla — örneğin her 30 saniyede bir — tekrarlayan TPS düşüşleri. Bu, Java'nın bellek temizliği için ana iş parçacığını dondurmasıdır. Sebebi genellikle yetersiz RAM değil, yanlış boyutlandırılmış yığın (heap) ve GC ayarlarıdır.

Ayar dosyaları: hangisi nerede?

Optimizasyon rehberlerini uygularken en sık yapılan hata, ayarı yanlış dosyada aramaktır. Paper, eski tek dosyalı paper.yml yapısını bıraktı; güncel yapı şöyle:

• server.properties — vanilla ayarları: view-distance, simulation-distance, max-players.
• bukkit.yml — mob doğma limitleri gibi temel Bukkit ayarları.
• spigot.yml — entity-activation-range, merge-radius gibi Spigot ayarları.
• config/paper-global.yml — sunucu genelinde geçerli Paper ayarları.
• config/paper-world-defaults.yml — tüm dünyalar için varsayılan değerler.
• world/dimensions/<namespace>/<key>/paper-world.yml — tek bir dünyaya özel istisnalar.

Sistem kalıtımla çalışır: bir dünya için açıkça tanımlanmayan her ayar paper-world-defaults.yml'den devralınır. Yani tüm yapılandırmayı her dünyaya kopyalamanız gerekmez, yalnızca istisnaları yazarsınız.

En yüksek getirili ayarlar

Aşağıdakiler, çoğu sunucuda kazancın büyük bölümünü veren ayarlardır. Hepsini aynı anda uygulamayın — birer birer değiştirip gerçek yük altında test edin.

Görüş ve simülasyon mesafesi

Tek başına en büyük etkiye sahip iki değer. view-distance istemciye gönderilen chunk sayısını, simulation-distance ise aktif olarak işlenen chunk sayısını belirler — CPU yükünün asıl kaynağı ikincisidir. Yoğun sunucularda 6–8 aralığı makul bir başlangıçtır. Simülasyon mesafesini görüş mesafesinin altında tutun: oyuncu uzağı görür ama uzaktaki chunk'lar işlenmez.

Varlık aktivasyon menzili

spigot.yml içindeki entity-activation-range, mobların hangi mesafeden itibaren işlenmeye başlayacağını belirler. Hayvan ve canavarlar için ölçülü biçimde düşürmek yük azaltır — ancak aşırıya kaçmak mobların oyuncunun burnunun dibinde donmasına yol açar ve oyun hissini bozar.

Item birleştirme

merge-radius değerini düşürülmüş item'lar için biraz artırmak, yerde biriken yığınları birleştirerek varlık sayısını düşürür.

Çarpışma sınırı

Paper'ın max-entity-collisions değeri (varsayılan 8) çarpışma hesaplamalarını sınırlar. Ayrıca only-players-collide seçeneği çarpışma tespitini yalnızca oyuncuların dahil olduğu durumlara indirger — mob sıkıştırma farmlarının olduğu sunucularda belirgin fark yaratır.

Hopper ayarları

Hopper'lar sessiz TPS katilidir. Paper'ın üç ayarı doğrudan işe yarar: cooldown-when-full dolu hopper'lara kısa gecikme uygular, ignore-occluding-blocks gereksiz konteyner taramasını atlar ve disable-move-event — resmî dokümantasyonun ifadesiyle hopper performansını çarpıcı biçimde iyileştirir. Son ayarı açmadan önce hopper olaylarına bağlı çalışan bir plugin'iniz olup olmadığını kontrol edin.

Chunk ayarları

delay-chunk-unloads-by chunk'ların hemen boşaltılmasını geciktirir (10s, 25m gibi süre biçiminde) — oyuncuların ileri geri dolaştığı bölgelerde sürekli yükleme-boşaltma döngüsünü kırar. max-auto-save-chunks-per-tick (varsayılan 24) ise tick başına kaydedilecek chunk sayısını sınırlayarak otomatik kayıt sırasındaki sıçramaları yumuşatır.

Redstone motoru

Paper, redstone uygulamasını değiştirmenize izin verir: VANILLA, EIGENCRAFT veya ALTERNATE_CURRENT. Alternatif motorlar aynı sonucu daha verimli algoritmalarla üretir ve büyük redstone düzeneklerinin olduğu sunucularda gözle görülür fark yaratır. Davranış farkları olabileceği için önce test dünyasında deneyin.

Diğerleri

optimize-explosions patlamalarda hesaplama yükünü azaltır. update-pathfinding-on-block-update ise mob yol bulmanın her blok güncellemesinde yeniden hesaplanmasını kontrol eder — köylü yoğun sunucularda bakılacak ayarlardandır.

Bellek ve çöp toplama

Düzenli aralıklı TPS düşüşleri görüyorsanız sorun buradadır. Üç kural:

• -Xms ve -Xmx eşit olsun. Bu, boşa ayrılan belleği ortadan kaldırır.
• Tam tüketildiğinde karşılayamayacağınız bir -Xmx vermeyin. İşletim sistemine ayrı kapasite kalmalıdır.
• Gereğinden fazla yığın ayırmak zarar verebilir. Çok büyük bir heap, GC aşamalarını uzatarak daha belirgin donmalara yol açar. "Ne kadar çok o kadar iyi" burada geçerli değildir.

Minecraft sunucularında yaygın olan G1GC yapılandırmasında, 10 GB'a kadar olan sunucularda -XX:G1NewSizePercent=50, -XX:G1MaxNewSizePercent=80 ve -XX:InitiatingHeapOccupancyPercent=10 gibi değerler kullanılır; 10 GB üzerinde bunlar sırasıyla 35, 60 ve 15 olarak ayarlanır.

Ne kadar RAM gerektiğini ve paket seçimini Minecraft sunucu satın alma rehberimizde ayrıntılı ele aldık.

Plugin denetimi

Plugin sayısı değil, ürettikleri yük önemlidir. Hafif 30 plugin, kötü yazılmış 5 plugin'den daha az sorun çıkarabilir. Denetim yöntemi:

• spark profillemesinde hangi plugin'in tick süresini yediğini ölçün.
• Kullanmadığınız plugin'leri devre dışı bırakmakla yetinmeyin, tamamen silin.
• Aynı işi yapan iki plugin varsa birini kaldırın (iki farklı arazi koruma, iki farklı chat yönetimi gibi).
• Her sayfa yüklemesinde kendi CSS/JS'ini ya da yoğun sorgusunu çalıştıran plugin'lere dikkat edin.

Plugin kurulumu, güncelleme ve /reload tuzağı hakkında ayrıntı için Minecraft sunucusuna plugin nasıl eklenir yazımıza bakabilirsiniz. Kısaca: canlı sunucuda /reload kullanmayın; plugin'leri düzgün kapatmadığı için bellek sızıntısı ve zamanlanmış görev çakışması üretir ve belirtiler saatler sonra ortaya çıkar.

Oyuncu kaynaklı lag

Bazı lag kaynakları ayar dosyasında değil, dünyanızın içindedir:

• Kontrolsüz mob farmları. Tek bir oyuncunun kurduğu büyük bir farm, tüm sunucunun TPS'ini düşürebilir.
• Yerde biriken item yığınları. Otomatik temizlik yapan bir plugin ve makul bir merge-radius bu sorunu büyük ölçüde çözer.
• Sürekli aktif redstone saatleri. Kimsenin kullanmadığı ama durmadan çalışan düzenekler.
• Chunk yükleyiciler. Oyuncu orada olmasa bile bölgeyi yüklü tutan yapılar.
• Aşırı hopper zincirleri. Depolama sistemlerinde yüzlerce hopper birikebilir.

Bu tür sorunlarda teknik çözümün yanında bir de kural koymak gerekir: farm boyutu sınırı, hopper yerine daha verimli alternatiflerin önerilmesi ve düzenli dünya denetimi. Yalnızca ayarla çözmeye çalışmak uzun vadede işe yaramaz.

Donanım: ayarla kapatamayacağınız kısım

Minecraft sunucusu işini büyük ölçüde tek bir iş parçacığında yapar. Bu yüzden TPS'i belirleyen şey çekirdek sayısı değil, işlemcinin frekansı ve neslidir. Yüksek frekanslı güncel nesil bir işlemcide çalışan 4 çekirdekli bir sunucu, eski nesil 8 çekirdekli bir sunucudan daha yüksek TPS verebilir.

Disk tarafı da göründüğünden önemlidir: chunk yükleme, otomatik kayıt ve dünya büyüdükçe artan disk I/O, NVMe M.2 SSD ile SATA arasında belirgin fark yaratır.

Bir de ölçülebilir bir tuzak var: sunucunuz paylaşımlı kaynakta çalışıyorsa TPS'iniz sizin kontrolünüzde değildir. Linux'ta top komutunu çalıştırıp CPU satırındaki %st (steal time) değerine bakın — yoğun saatlerde sürekli %10'un üzerindeyse fiziksel sunucu aşırı yüklüdür ve hiçbir ayar bunu düzeltmez. Konunun tamamını VDS ile VPS arasındaki fark yazımızda ele aldık.

Optimizasyon yaparken 6 kural

• Ölçmeden değiştirmeyin. Önce spark, sonra ayar.
• Tek seferde tek şey değiştirin ve gerçek yük altında test edin.
• İnternetten hazır ayar bloğu yapıştırmayın. Başkasının sunucusuna uyan değer sizinkine uymayabilir.
• Aşırı değerlerden kaçının. Oyun hissini bozan bir ayar, kazandığı TPS'ten daha pahalıya gelir.
• Her değişiklikten önce yedek alın.
• Kök sebebi çözün. Paper, varlık ve farm yüküyle boğulmuş bir sunucuyu ayarla kurtaramaz.

Nubitro Minecraft sunucuları

Yukarıdaki ayarların hepsini doğru yapsanız bile TPS'in tavanını donanım belirler. Nubitro Minecraft sunucuları AMD Ryzen 9 9950X işlemciler üzerinde, Türkiye / İstanbul lokasyonunda, NVMe M.2 SSD disk ve 1 Gbps sınırsız trafik ile çalışır.

Kaynaklar fiziksel bölümlendirme ile tanımlandığı için komşu yoğunluğu tick sürenize yansımaz — yani ölçtüğünüz TPS gerçekten sizin sunucunuzun performansıdır. Paketler 2 çekirdek / 4 GB RAM seviyesinden 6 CPU / 32 GB RAM'e kadar ölçeklenir.

Paketleri Minecraft sunucu kiralama sayfamızdan inceleyebilir, kendi yapılandırmanızı kurmak isterseniz Ryzen VDS paketlerine bakabilirsiniz. Tüm hizmetler için nubitro.com ana sayfamızı ziyaret edebilirsiniz.

Sıkça Sorulan Sorular

TPS 20 ama oyuncular lag diyor, neden?

TPS sunucu tarafını ölçer, oyuncunun yaşadığı gecikmeyi değil. Sunucu 20 TPS'te çalışırken oyuncu lag hissediyorsa sorun ağdadır: ping, paket kaybı ya da lokasyon uzaklığı. Oyuncu kitleniz Türkiye'deyse yurt dışı lokasyon tek başına 40–60 ms ekler.

RAM'i artırdım, TPS düzelmedi. Normal mi?

Evet, çok yaygın. RAM eklemek yalnızca gerçekten bellek darboğazındaysanız işe yarar. Düzenli aralıklı düşüşler görüyorsanız sorun GC ayarlarındadır; sürekli ve dalgasız düşüklük görüyorsanız tek çekirdek doygunluğudur. İkisi de RAM ile çözülmez.

view-distance'ı kaça düşürmeliyim?

Yoğun sunucularda 6–8 aralığı makul bir başlangıçtır ve simülasyon mesafesini bunun altında tutun. Ancak önce mevcut değerinizle bir ölçüm alın; bazı sunucularda darboğaz mesafede değil, entity yükünde olur ve mesafeyi düşürmek yalnızca oyun deneyimini kötüleştirir.

spark raporunda bir plugin geniş görünüyor, onu silmeli miyim?

Hemen değil. Geniş bir dal, örneklenen zamanın orada geçtiğini gösterir — o kodun bozuk olduğunu değil. Plugin asıl işi yapıyor da olabilir. Raporu o sıradaki oyuncu aktivitesiyle birlikte değerlendirin ve mümkünse test ortamında plugin'i devre dışı bırakıp ölçümü tekrarlayın.

Hazır optimizasyon ayar paketlerini kullanabilir miyim?

Başlangıç noktası olarak bakabilirsiniz ama olduğu gibi yapıştırmayın. Bu paketler genellikle belirli bir sunucu tipi için hazırlanır ve aşırı agresif değerler içerebilir; sonuç, TPS kazanırken oyun hissini bozmak olur. Her ayarı ne yaptığını bilerek ve tek tek uygulayın.

Dünya boyutu TPS'i etkiler mi?

Doğrudan dosya boyutu değil, üretilmemiş alana yapılan keşif etkiler. Oyuncular sürekli yeni bölgelere açılıyorsa chunk üretimi MSPT'yi sıçratır. Dünya sınırı (world border) tanımlamak bu yükü öngörülebilir hale getirir.

Özet

• Hedef 20.0 TPS ve 50 ms altı MSPT'dir; asıl izlenecek rakam MSPT'dir.
• Optimizasyona spark ile ölçerek başlayın, tahminle değil.
• Profillemeyi sunucu boşken değil, lag yaşanırken yapın.
• Alev grafiğinde geniş dal, suçlu olduğunun kanıtı değildir.
• ServerLevel#tickEntities %40 üzerindeyse sorun mob, köylü ve hopper yükündedir.
• Keşif sırasında yaşanan sıçramalar chunk üretimini işaret eder.
• Düzenli aralıklı TPS düşüşleri çöp toplama duraklamasıdır.
• Paper artık paper-global.yml, paper-world-defaults.yml ve dünya bazlı paper-world.yml kullanır.
• En yüksek getiri görüş/simülasyon mesafesi, entity aktivasyon menzili ve hopper ayarlarındadır.
• -Xms ile -Xmx eşit olmalı; aşırı heap GC donmalarını artırır.
• Plugin'leri sayıya göre değil, ürettikleri tick yüküne göre değerlendirin.
• Canlı sunucuda /reload kullanmayın.
• Tek çekirdek performansı TPS'in tavanını belirler; ayarla aşılamaz.
• Paylaşımlı kaynakta %st sürekli %10 üstündeyse TPS sizin kontrolünüzde değildir.