Modlu Minecraft sunucusu optimizasyonu, dört adımlık bir sıradır: ölç, performans modlarını kur, JVM bayraklarını düzelt, server.properties ayarlarını sıkılaştır. Bu sırayı bozup doğrudan “sunucuya RAM ekleyelim” demek çoğu zaman işe yaramaz — modlu sunucuda düşük TPS’in en yaygın nedeni yetersiz RAM değil, tek bir modun ana thread’i (iş parçacığı) meşgul etmesidir.
TPS (tick per second — saniyedeki tick sayısı) sunucunun kalp atışıdır. Minecraft saniyede 20 tick çalışır; bu değer 20’nin altına düştüğünde oyun ağır çeker, bloklar geç kırılır, yaratıklar takılarak hareket eder. Modlu sunucularda 200 mod aynı tick içinde iş yaptığı için 20 TPS’i korumak vanilla’dakinden çok daha zordur.
Bu sayfadaki her öneri Minecraft 26.2 için doğrulanmış sürümlere dayanır. Sunucunuz 1.21.x hattındaysa mod sürümleri farklı olacaktır ama yöntem aynıdır.
Modlu sunucuda lag nereden gelir?#
Şikayet hep aynıdır — “sunucu lag yapıyor” — ama nedenler farklıdır. Doğru müdahaleyi seçebilmek için üçünü ayırt etmeniz gerekir:
- TPS düşüklüğü (sunucu kaynaklı)
- Sunucu tick’i zamanında bitiremiyor. Ağır modlar, çok fazla yaratık, ışık hesaplamaları veya anlık chunk üretimi kaynaklıdır. Herkes aynı anda ağırlık hisseder.
- Ping yüksekliği (ağ kaynaklı)
- TPS 20’de olmasına rağmen tek oyuncuda gecikme vardır. Sunucu tarafında yapılacak optimizasyon bunu düzeltmez.
- Bellek baskısı (GC kaynaklı)
- Çöp toplayıcı sık ve uzun duraklamalar yapıyor. Belirtisi düzenli aralıklarla gelen donmalardır.
Bu üçünün ayrımını TPS düşüklüğü ve çözüm yolları sayfasında daha ayrıntılı bulabilirsiniz.
Önce ölçün: spark ile teşhis#
Optimizasyona mod kurarak değil ölçerek başlayın. spark, sunucunun hangi modun hangi metodunda ne kadar zaman harcadığını gösteren profil aracıdır ve 26.2’de üç loader’da da çalışır. Jar dosyasını mods/ klasörüne atıp sunucuyu yeniden başlatmanız yeterlidir.
/spark tps # anlık TPS ve tick süreleri
/spark profiler start --timeout 300 --only-ticks-over 100
/spark profiler stop # rapor bağlantısı üretir
/spark health --memory # bellek ve GC durumu
/spark heapsummary --run-gc-before # hangi mod kaç MB tutuyor
/spark gc # çöp toplayıcı duraklama geçmişi
--only-ticks-over 100 parametresi yalnızca 100 milisaniyeden uzun süren tick’leri kaydeder; böylece raporda gürültü olmaz, sadece gerçekten yavaşlatan işler görünür. heapsummary çıktısı ise “RAM’i hangi mod yiyor” sorusunun doğrudan cevabıdır. Rapor okumayı öğrenmek için spark ve Timings raporu analizi sayfasına bakın.
/spark yerine /sparkc olabilir. Komut bulunamıyorsa önce /sparkc tps deneyin.Minecraft 26.2 için performans modları#
Aşağıdaki liste, 26.2 uyumluluğu doğrulanmış modlardan oluşur. Hepsini birden kurmanız gerekmez; ilk üçü neredeyse her sunucuda kazanç sağlar.
| Mod | Ne yapar? | Fabric | NeoForge |
|---|---|---|---|
| Lithium 0.25.3 | Genel oyun mantığı optimizasyonu (yapay zekâ, yol bulma, çarpışma) | ✓ | ✓ |
| FerriteCore 9.0.0 | Bellek kullanımını düşürür, en büyük RAM kazancı | ✓ | ✓ |
| Krypton 0.3.1 | Ağ yığını optimizasyonu | ✓ | — |
| Krypton Reno | Krypton’un NeoForge karşılığı | — | ✓ |
| ServerCore 1.5.19 | Yüke göre dinamik ayar yapar | ✓ | ✓ |
| VMP 0.2.0 | Yüksek oyuncu sayısı için ağ ve chunk yönetimi | ✓ | — |
| Alternate Current | Redstone hesaplamasını hızlandırır | ✓ | ✓ |
| spark 1.10.173 | Teşhis ve profil aracı | ✓ | ✓ |
| Chunky 1.5.x | Chunk ön üretimi | ✓ | ✓ |
FerriteCore’un kazancı ölçülmüştür: All of Fabric 3 paketinde bellek kullanımı 1.792 MB’den 984 MB’ye düşmüştür. Kazanç blockstate komşu tablosunun daha verimli bir veri yapısıyla değiştirilmesinden gelir — tek başına bu değişiklik yaklaşık 600 MB’lık bir tabloyu 7 MB’ye indirir. RAM sıkıntısı yaşayan her modlu sunucuda ilk kurulacak mod budur.
-
LithiumÖnerilenİndir
-
FerriteCoreÖnerilenİndir
-
Krypton (ağ optimizasyonu)İndir
-
spark profilerİndir
-
Eclipse Temurin JDK 25LTSİndir
Bağlantılar resmî kaynaklara gider. Mod jar’larını üçüncü taraf aynalardan indirmeyin.
26.2’de artık kullanamayacağınız performans modları#
Eski rehberlerde sık geçen bazı modların 26.2 sürümü henüz yok. Bunları aramakla vakit kaybetmeyin:
- ModernFix — resmî sürüm en fazla 26.1.2’yi destekliyor. Topluluk çatallaması olan ModernFix-mVUS 26.2 için mevcut, dilerseniz onu deneyebilirsiniz.
- Canary — Lithium’un Forge portuydu; 26.2 için sürümü yok. Lithium artık NeoForge’u resmen desteklediği için zaten gereksizleşti.
- Radium ve Saturn — 26.2 için sürümleri yok.
NoSuchMethodError hatasıyla açılmaz. Her modun 26.2 için ayrı yapısını indirin.Java heap ve çöp toplayıcı ayarı#
Modlu sunucuda JVM bayrakları TPS’i doğrudan etkiler. İki temel kural: -Xms ile -Xmx daima eşit verilir ve işletim sistemine pay bırakılır. 16 GB’lık bir sunucuda heap 14 GB’tır, 16 GB değil.
8-12 GB heap: G1GC ve Aikar’s Flags#
Bu aralıkta PaperMC’nin resmî Aikar’s Flags seti hâlâ en güvenli tercihtir ve 26.x sunucularında geçerliliğini korur:
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 \
-jar server.jar nogui
16 GB ve üzeri heap: ZGC#
Büyük heap’lerde G1GC’nin duraklamaları uzar. ZGC duraklamayı heap boyutundan bağımsız olarak 1 milisaniyenin altında tutar; karşılığında yaklaşık yüzde 10-15 daha fazla CPU ve yüzde 3-5 daha fazla bellek ister. Yüksek frekanslı bir Ryzen 9 işlemcide bu bedel rahatlıkla karşılanır.
java -Xms14G -Xmx14G -XX:+UseZGC -XX:+UseStringDeduplication \
-XX:+UseCompactObjectHeaders -XX:+AlwaysPreTouch \
-XX:TrimNativeHeapInterval=5000 \
-jar server.jar nogui
-XX:+ZGenerational bayrağı obsolete’tir; yazarsanız yalnızca uyarı basar. İnternetteki birçok 2026 rehberi hâlâ -XX:+UseZGC -XX:+ZGenerational yazıyor, bu yanlıştır. Doğru kullanım sadece -XX:+UseZGC şeklindedir. Ayrıca G1GC bayraklarıyla ZGC bayraklarını birlikte kullanmayın; ZGC’ye geçerken tüm -XX:G1* bayraklarını silin.-XX:+UseCompactObjectHeaders Java 25’te deneysel olmaktan çıkıp kararlı özelliğe terfi etti. Her Java nesnesinin başlığını 12 bayttan 8 bayta indirir; milyonlarca küçük nesne tutan modlu sunucularda gözle görülür bir bellek kazancı sağlar. JVM ayarlarının tamamı için Minecraft sunucu RAM ayarları ve JVM flag’leri sayfasına bakabilirsiniz.
server.properties’te en çok işe yarayan ayarlar#
Tek satırla en büyük kazancı view-distance verir ve bunun matematiği bellidir. Yüklenen chunk sayısı yarıçapın karesiyle büyür: view-distance=16 iken oyuncu başına (2×16+1)² = 1089 chunk yüklenirken, view-distance=10 iken (2×10+1)² = 441 chunk yüklenir. Yani 16’dan 10’a inmek yükü yaklaşık 2,5 kat azaltır.
view-distance=10
simulation-distance=8
entity-broadcast-range-percentage=75
max-tick-time=60000
sync-chunk-writes=false
simulation-distance gerçekten tick’lenen chunk sayısını belirler; yani yaratıkların hareket ettiği, bitkilerin büyüdüğü alan budur. Görüş mesafesini korurken bu değeri 8’e çekmek oyuncu deneyimini bozmadan CPU yükünü düşürür. entity-broadcast-range-percentage ise varlıkların oyunculara ne kadar uzaktan gönderileceğini ayarlar; kalabalık modlu sunucularda 100’den 75’e çekmek ağ trafiğini azaltır.
Bu iki ayarın ayrıntılı anlatımı view distance ve simulation distance ayarları sayfasında.
Chunk ön üretimi ile açılış lag’ini bitirme#
Bir oyuncu daha önce gidilmemiş bir bölgeye yürüdüğünde sunucu o chunk’ları anında üretmek zorundadır. Modlu dünyalarda maden, yapı ve biyom ekleyen onlarca mod bu üretime katıldığı için işlem çok pahalıdır ve TPS anında dibe vurur. Çözüm dünyayı önceden üretmektir.
Chunky bu işi yapan moddur ve 26.2’de hem Fabric hem NeoForge/Forge tarafında çalışır. Tipik akış şudur:
/chunky world minecraft:overworld
/chunky center 0 0
/chunky radius 5000
/chunky start
/chunky progress # ilerlemeyi izle
/chunky pause # duraklat (kayıtlıdır)
/chunky continue # kaldığı yerden devam et
5000 bloklık bir yarıçap küçük ve orta ölçekli sunucular için fazlasıyla yeterlidir. Ön üretim sırasında sunucu ağır çalışır; bu işlemi oyuncular yokken, tercihen kurulumun hemen ardından yapın. İşlem bittikten sonra dünya sınırını (/worldborder set) ön üretilen alanla aynı yapmak, oyuncuların üretilmemiş bölgeye çıkmasını engeller.
Bellek hataları: heap mi Metaspace mi?#
Modlu sunucularda en çok yanlış teşhis edilen konu budur. İki hata birbirine benzer ama çözümleri farklıdır:
| Hata metni | Anlamı | Doğru çözüm |
|---|---|---|
OutOfMemoryError: Java heap space | Heap doldu | -Xmx değerini artırın |
OutOfMemoryError: Metaspace | Sınıf metadata alanı doldu (heap dışı) | -XX:MaxMetaspaceSize=1g ekleyin |
GC overhead limit exceeded | GC sürekli çalışıyor, iş yapamıyor | Heap’i artırın, ağır modu bulun |
Metaspace heap’in dışındadır, yani -Xmx değerine dâhil değildir. Bu yüzden Metaspace hatasında -Xmx’i artırmak sorunu çözmez, konteynerli sunucuda daha da kötüleştirir. Ağır modpack’lerde -XX:MaxMetaspaceSize=1g, orta paketlerde 512m uygun bir başlangıçtır. Hata çözümünün tamamı için Out of Memory hatası sayfasına bakın.
Panelde çalışan sunucularda dikkat edilecekler#
Sunucunuz Pterodactyl veya Pelican gibi bir panelde konteyner içinde çalışıyorsa iki ek kural devreye girer.
Birincisi: konteyner bellek limiti heap + Metaspace + native bellek + thread yığınlarının toplamını sayar, ama -Xmx yalnızca heap’i sınırlar. -Xmx’i konteyner limitine eşitlerseniz JVM heap’i doldurduğunda konteyner OOM-kill ile öldürülür. 12 GB limitli bir konteynerde güvenli ayar şudur:
-Xms10G -Xmx10G -XX:+UseZGC -XX:+UseStringDeduplication \
-XX:+UseCompactObjectHeaders -XX:MaxMetaspaceSize=1g
İkincisi: panelde -XX:+AlwaysPreTouch kullanmayın. Bu bayrak başlangıçta tüm heap sayfalarına dokunarak belleği baştan ayırır; konteyner ortamında bu davranış limit aşımına yol açabilir. Panel tarafındaki ayarların tamamı için Pterodactyl’de modlu sunucu kurma sayfasına bakın.
Ağır modu bulmak ve devre dışı bırakmak#
spark raporu size suçluyu gösterdiğinde üç seçeneğiniz vardır: modu güncelleyin, modun ayarını kısın, ya da modu tamamen kaldırın. Kaldırmadan önce mutlaka yedek alın — bir modun eklediği bloklar dünyada duruyorsa mod kaldırıldığında o bloklar kaybolur.
save-all
save-off
# ... sunucuyu durdurun, world/ + mods/ + config/ klasörlerini birlikte yedekleyin ...
save-on
Lithium ile başka bir mod çakışıyorsa modu tamamen kaldırmak yerine tek tek optimizasyonlarını kapatabilirsiniz. config/lithium.properties dosyasına ilgili satırı ekleyip sunucuyu yeniden başlatmanız yeterlidir:
mixin.ai.pathing=false
mixin.entity.collisions=false
mixin.world.block_entity_ticking=false
Mod ekleme ve çıkarmanın güvenli sırası için sunucuya sonradan mod ekleme ve çıkarma sayfasına, çökme raporlarını okumak içinse crash report nasıl okunur sayfasına bakabilirsiniz.
Donanım ne zaman sınır olur?#
Yukarıdaki adımların hepsini uyguladığınız hâlde TPS 20’ye çıkmıyorsa sorun yazılımda değil donanımdadır. Modlu sunucuda tick döngüsü tek çekirdekte çalıştığı için çekirdek sayısı değil saat hızı belirleyicidir; düşük frekanslı çok çekirdekli sunucu işlemcileri modlu Minecraft için uygun değildir.
Batihost’ta modlu sunucular yüksek frekanslı Ryzen 9 7900X / 7950X işlemciler ve NVMe SSD disklerle çalışır. Paketleri modlu Minecraft sunucuları sayfasından, kendi kurulumunuzu yapmak isterseniz yüksek frekanslı Ryzen VDS tarafından inceleyebilirsiniz. Ne kadar RAM gerektiğini hesaplamak için modlu sunucu kaç GB RAM ister sayfasındaki tabloyu kullanın.
Özetle#
Modlu sunucu optimizasyonu tahminle değil ölçümle yapılır. spark ile başlayın, Lithium ve FerriteCore’u kurun, view-distance ve simulation-distance değerlerini 10 ve 8’e çekin, Chunky ile dünyayı ön üretin. JVM tarafında heap 8-12 GB ise G1GC ve Aikar’s Flags, 16 GB üzeriyse -XX:+UseZGC kullanın — -XX:+ZGenerational yazmayın.
Bu adımlar çoğu modlu sunucuda TPS’i 20’ye yaklaştırır. Vanilla ve eklentili sunucular için genel yaklaşımı Minecraft sunucu optimizasyonu sayfasında, kurulumun tamamını ise modlu Minecraft sunucusu kurma rehberinde bulabilirsiniz.