Giriş yap Sunucunu ekle

RehberSunucu sahipleri için

Minecraft sunucu lag sorunu: düzeltmeden önce nedenini bul

Tick, ağ ve FPS lag'ını ayırt et, spark profilini oku, varlıkları, chunk'ları ve redstone'u düzelt, yeniden başlatmaları kesinti verilerimizle planla.

ServerList editör ekibi Yayın: 9 dk okuma
MSPT, spark profil aracı50 ms bütçe50 MSSıçrama

Tek bir ayarı değiştirmeden önce üç lag türünden hangisine sahip olduğunu bul: sunucunun tick döngüsünün geride kalması, oyuncularla sunucu arasındaki ağ ya da bir oyuncunun kendi bilgisayarının oyunu çizmekte zorlanması. En yoğun saatinde /spark tps çalıştır. Tick süreleri 50 ms'nin altında kalıyorsa sunucu yetişiyor demektir ve oyuncuların hissettiği lag başka bir yerden geliyor.

Çoğu "optimizasyon rehberi" bu adımı atlar ve sana bir ayar listesi verir. O ayarların bir kısmı işe yarar, birkaçı oyunu kötüleştirir ve hiçbiri henüz bulmadığın bir sorunu çözmez. Bu rehber teşhisle başlıyor.

Üç tür lag (sunucu tick'i, ağ, istemci)

TürOyuncuların fark ettiğiNasıl doğrulanırKim düzeltebilir
Sunucu tick lag'ıKırılan bloklar geri gelir, moblar donup sonra sıçrar, kapılar geç açılır ve herkes bunu aynı anda görür/spark tps, Paper'da /mspt ya da vanilla'nın /tick query komutuSen, sunucuda
Ağ lag'ıBazı oyuncularda geri sekme (rubber-banding) ve geç işleyen vuruşlar, diğerleri sorunsuzkenOyuncu listesindeki bağlantı çubukları, bir eklenti ekliyorsa /ping komutu, ilanının istatistik sayfasıSen (konum, host, koruma) ya da oyuncunun rotası
İstemci lag'ıDüşük kare hızı, dönerken takılma, yalnızca tek bir oyuncuyu etkilerF3 ekranındaki FPS sayacıOyuncu (görüş mesafesi, video ayarları, bir performans modu)

Sayılar üzerine meraklısına kısa bir not, çünkü TPS'in neden yalan söylediğini açıklıyor. Sunucu saniyede 20 tick hedefler, yani her tick'in 50 ms'lik bir bütçesi var. TPS asla 20'nin üstüne çıkamaz, bu da tick başına 10 ms gereken bir sunucu ile 48 ms gereken bir sunucunun ikisinin de 20,0 TPS göstermesi demek. Birincisi şimdiki yükünün birkaç katını kaldırabilir, ikincisi ise lag'a bir huni çiftliği kadar uzakta. MSPT (tick başına milisaniye) bu boşluğu gösterir, o yüzden TPS'e değil MSPT'ye bak.

Bir şeyi değiştirmeden önce ölç

  1. Doğru saati seç. Zirvede olan lag sabah beşte ölçülemez. Listemizdeki tüm sunucuların en yoğun dört saati senin saat diliminde ile arası, ilanının herkese açık istatistik sayfası da kendi en yoğun saatlerini gösterir.
  2. /spark tps çalıştır. Son 5 saniyeden 15 dakikaya kadar TPS'i ve tick sürelerini minimum, medyan, 95. yüzdelik ve maksimum olarak gösterir. 50 ms'nin epey altında bir medyan ile bunun üstünde bir 95. yüzdelik, sürekli aşırı yük değil ani sıçramalar demektir. Paper'ın /mspt komutu kısa versiyonu verir.
  3. /spark health çalıştır. CPU kullanımını, belleği ve diski ekler, böylece makinenin kendisinde bir şeyin tükenip tükenmediğini bir bakışta görürsün.
  4. Konsolu oku. Vanilla'nın Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind uyarısı (sunucu konsolu her zaman İngilizce yazar), sunucunun geride kaldığı ve yetişmek için ileri atladığı anlamına gelir. Günde bir tane gürültüdür. Dakikada bir tane sorundur.
  5. Başlangıç değerini not et: saat, çevrimiçi oyuncular, MSPT medyanı ve 95. yüzdeliği ve oyuncuların nerede olduğu (yeni bir bölge, büyük bir çiftlik, bir etkinlik). Her değişiklikten sonra bununla karşılaştıracaksın.

Spark olmayan bir sunucuda vanilla'nın /tick query komutu (Java Edition 1.20.3 ve sonrası, izin seviyesi 3) tick başına ortalama süreyi ve yüzdeliklerini verir.

Listedeki tüm sunuculardaki oyuncular, günün saatine göreSon 28 gün
Zirve

En yoğun saat , yaklaşık 17.845 oyuncuyla, en sakin saat . En yoğun saatte, en sakin saate göre 2,6 kat daha fazla oyuncu var.

Ölçüm: 19 Eki 2026, 23:15 UTCNasıl ölçüyoruz

Bir spark profilini okumak

Sayılar sunucunun yavaş olduğunu söylediğinde nedenini profiler söyler. PaperMC'nin belgeleri şunu öneriyor:

/spark profiler start --timeout 600

Bu, on dakika boyunca her thread'den örnek alır ve sana rapora bir bağlantı verir. İki varyasyon belirli sorunlarda yardımcı olur:

  • /spark profiler start --only-ticks-over 100 yalnızca 100 ms'den yavaş tick'leri kaydeder, bu da kısa lag sıçramalarını normal arka plandan ayırır.
  • /spark tickmonitor --threshold-tick 100 bir tick 100 ms'den uzun sürdüğü her seferde bir satır yazdırır, böylece sıçramaları oyunda olanlarla eşleştirebilirsin.

Profil, lag yaşanırken çalışmalıdır. Sessiz bir sunucunun 05:00'teki profili, 18:00'deki lag hakkında hiçbir şey söylemez.

Görüntüleyicide sunucu thread'ini aç ve en büyük yüzdeyi aşağı doğru takip et. Zamanın harcandığı dalı arıyorsun:

  • Varlık tick'leri (entity ticking), çoğu zaman altında mob yapay zekâsı ya da köylü yol bulma ile, mobları işaret eder (sonraki bölüm).
  • Blok varlıkları (block entities), listede yüksekte huniler varsa, huni zincirlerini ve depolama sistemlerini işaret eder.
  • Chunk işleri (üretme, yükleme, kaydetme) yeni araziyi keşfeden oyuncuları işaret eder.
  • Çağrı ağacında ya da görüntüleyicinin eklentiye göre dökümünde yüksekte görünen bir eklentinin adı o eklentiyi işaret eder. Suçlamadan önce ne yaptığını (bir olay işleyicisi, zamanlanmış bir görev, bir veritabanı çağrısı) not et, çünkü aynı eklenti farklı bir ayarla sorunsuz olabilir.

Spark çöp toplamayı (garbage collection) da kaydeder. Yüzlerce milisaniyelik sık duraklamalar bellek baskısını işaret eder, /spark gc bunu zaman içinde gösterir. Senin kurulumunda normalin neye benzediğini bilmek için sunucu iyiyken de bir kez profil çıkar.

Her zamanki şüpheliler (varlıklar, chunk üretimi, redstone, eklentiler, çöp toplama)

Varlıklar

Mob çiftlikleri, köylü ticaret salonları, yerdeki eşya yığınları, vagon sistemleri ve zırh askısı süslemelerinin hepsi tick'lenir. Paper'da /paper entity list tick'lenen varlıkları türe göre gösterir, /paper entity list minecraft:villager gibi bir filtre de listeyi daraltır, böylece nerede yığıldıklarını bulabilirsin. /paper mobcaps mob sınırlarının ne kadar dolu olduğunu, /paper chunkinfo kaç chunk'ın yüklü ve tick'lenir durumda olduğunu gösterir. Çözümler yasaklar değil sınırlardır: chunk başına varlık üst sınırı, oyuncularının kabul ettiği çiftlik kuralları ve 400 köylülük salonu kuranla bir konuşma.

Chunk üretimi

Yeni bir chunk üretmek bir sunucunun yaptığı en pahalı işlerden biridir ve elitralı oyuncular dakikada onlarcasını talep edebilir. Dünyayı bir kez, Chunky gibi bir eklentiyle (/chunky radius 5000, sonra /chunky start) sessiz saatlerde önceden üret ve uyan bir dünya sınırını /worldborder set 10000 ile belirle. Sınır çap alır, Chunky yarıçapı ise onun yarısıdır, yani bu iki sayı aynı kareyi anlatır. Bundan sonra keşif yalnızca chunk'ları diskten yükler ve bu çok daha ucuzdur.

Redstone ve huniler

Hızlı redstone saatleri ve uzun huni zincirleri birikir. Paper, config/paper-world-defaults.yml içinde iki ayar sunar. misc.redstone-implementation: ALTERNATE_CURRENT redstone tozu için daha hızlı bir hesaplama yöntemine geçer. hopper.disable-move-event: true hunileri ucuzlatır ama bu olaya dayanan eklentileri, örneğin bazı koruma ve huni filtresi eklentilerini bozar, o yüzden önce test et. hopper.cooldown-when-full varsayılan olarak zaten açıktır.

Eklentiler

Ağır bir eklenti profilde adıyla görünür. Yaygın örnekler her tick'te yeniden oluşturulan scoreboard'lar, hologramlar ya da tab listeleri, ana thread'de yapılan veritabanı ya da web istekleri, büyük bir dünyayı işleyen dünya haritası oluşturucular ve yük altındaki hile koruma kontrolleridir. Çözüm genellikle önce yapılandırma (güncelleme aralıkları, işleme sınırları), sonra güncelleme, sonra değiştirmedir.

Çöp toplama

Spark uzun ya da sık toplama duraklamaları gösteriyorsa başka her şeyden önce belleğe bak: -Xmx dünya ve eklentiler için fazla küçük mü ve -Xms aynı değere ayarlı mı? PaperMC'nin önerdiği bayraklar sağlam bir varsayılandır. Daha fazla bellek yalnızca sorun çöp toplamaysa işe yarar, paylaşımlı bir hostta ise hepsini ayırmak işletim sistemini aç bırakır.

İşe yarayan düzeltmeler

Nedeni bildikten sonra, kabaca deneyeceğimiz sırayla, genellikle karşılığını veren değişiklikler şunlar:

DüzeltmeNeye yardım ederOyunculara maliyeti
server.properties içindeki simulation-distance değerini (varsayılan 10) 6 ya da 8'e düşür, view-distance daha yüksek kalsınHer oyuncunun çevresindeki varlık ve blok tick'leriOyuncular uzaklaştığında çiftlikler ve ekinler daha erken çalışmayı bırakır
Dünyayı önceden üret ve bir sınır koyChunk üretimi sıçramalarıBir dünya sınırı
Chunk başına varlıkları sınırla ya da çiftlik kuralları koyVarlık tick'leriDaha küçük çiftlikler
ALTERNATE_CURRENT redstoneRedstone ağırlıklı yapılarRedstone zamanlamasında nadir farklar
spigot.yml içindeki entity-activation-range değerini düşürOyunculardan uzaktaki moblarUzaktaki moblar daha yavaş davranır
Spark'ın adını verdiği eklentiyi düzelt, yeniden yapılandır ya da değiştirEklenti yüküEklentiye bağlı
Sunucu yazılımının en son sürümüne güncelleDüzeltilen hatalar ve yeni optimizasyonlarBir yeniden başlatma

simulation-distance değişikliği göründüğünden büyüktür. Sunucu her oyuncunun çevresinde kabaca bir chunk karesini tick'ler, bu yüzden 10'dan 6'ya inmek bu kareyi yaklaşık 21'e 21 chunk'tan 13'e 13'e, yani yaklaşık 441 chunk'tan yaklaşık 169'a küçültür, oyuncular ise view-distance'ın izin verdiği kadar uzağı görmeye devam eder.

Popüler tavsiyelerden bazıları işe yaramaz. Birkaç dakikada bir yerdeki tüm eşyaları silen eklentiler bir belirtiyi tedavi eder ve oyuncuları kızdırır. Neyi değiştirdiğini söylemeden daha yüksek TPS vaat eden "optimizasyon" eklentilerinin öncesinde ve sonrasında profil çıkarmaya değer. İki saatte bir yeniden başlatmak da sorunları bulmak yerine saklar.

Dışarıdan görülen ağ lag'ı

Bir ayrıntı birçok sahibi şaşırtıyor. Sunucu listelerinin kullandığı durum pingine sunucunun ağ thread'leri yanıt verir, tick döngüsü değil. Bu yüzden bir sunucu oyunda ciddi şekilde lag yaşayıp yine de ping aracımıza birkaç milisaniyede cevap verebilir. Tick lag'ını dışarıdan göremiyoruz, spark tam da bu yüzden var. Velocity'nin arkasında ping aracı yalnızca proxy ile konuşur.

Ping aracımızın görebildiği şey ağdır. İlanının herkese açık istatistik sayfası (/server/your-server/stats) okumaya değer üç şey gösterir:

  • Yanıt süresi, yani sunucunun ping aracımıza ne kadar sürede cevap verdiği, medyanı, olağan aralığı ve bir grafikle birlikte. Seviyeyi çoğunlukla batı Avrupa'daki ping aracımıza olan mesafe belirler, bu yüzden Amerika Birleşik Devletleri'ndeki bir sunucu, yakın bir uç noktadan yanıt veren bir koruma ağı olmadıkça orada 10 ms göstermez. Değerine değil, zaman içindeki şekline bak.
  • Olağan aralığın üstündeki sıçramalar. Yanıtlar olağan aralığın çok üstüne yalnızca yoğun saatlerinde çıkıyorsa makine ya da ağ bağlantısı o saatlerde doymuştur. Aralık her saatte genişse rotadan ya da hostun ağından şüphelen.
  • Kesinti günlüğü. Kısa boşluklar yeniden başlatmalar ya da çökmelerdir. Uzun boşluklar hostunun durum sayfasına ve çökme raporlarına bir bakmayı hak eder.

Oyuncu tarafında, etkilenen oyunculardan adresine bir traceroute (Windows'ta tracert, macOS ve Linux'ta traceroute) ve bölgelerini iste. Bir ülkedeki herkes lag yaşıyor, başka kimse yaşamıyorsa sorun rotadır ve sunucuyu taşımak ya da yakın bir uç noktası olan bir koruma ağı eklemek herhangi bir ayardan daha çok yardımcı olabilir. Hiç bağlanamayan oyuncuların sorunları farklıdır, onları bağlantı hataları rehberimiz anlatıyor.

Ne zaman yeniden başlatmalı, ne zaman başlatmamalı

Yeniden başlatmalar bedava değildir. Çevrimiçi herkes atılır ve bir pazar akşamı dövüşün ortasında atılan oyuncu bunu hatırlar. Kesinti verilerimiz sahiplerin bunları gerçekte nasıl zamanladığını gösteriyor.

16 Ekim 2026'ya kadar olan 30 günde listemizdeki 90 ilan zamanın en az %90'ında oynanabilirdi. Bunlardan 58'inin en az bir kesintisi vardı (art arda üç ya da daha fazla pingin oynanabilir bir yanıt almamasını kesinti sayıyoruz) ve toplamda 515 kesinti yaşandı. İlk başarısız pingden sonuncuya kadar ölçüldüğünde kesintilerin yarısı beş dakikadan kısa sürede bitti, en uzun onda biri ise iki saati geçti. 515 kesintinin 375'i (%73) 15 dakika ya da daha kısa sürdü, yani bir yeniden başlatmanın ya da bir çökme ve yeniden açılışın süresi kadar.

Bu kısa kesintiler ne zaman başladı? Bir saat öne çıkıyor: 04:00 UTC, 375'in 39'u, zamanlanmış gece yeniden başlatmalarının şekli. Bu saatin dışında gün içine oldukça eşit dağılıyorlar. 375'in 64'ü (%17), listemizin en yoğun dört saati olan 14:00 ile 18:00 UTC arasında başladı ve bu, yeniden başlatma saatleri rastgele seçilseydi beklenecek payın kabaca kendisi.

Ölçülen
%19Listenin en yoğun dört saatinde başlayan kısa kesintiler, son 30 gün

Ölçüm: 19 Eki 2026, 21:52 UTCNasıl ölçüyoruz

Canlı olarak, son 30 gün: %90 ya da üstü olan 83 ilanda 472 kesinti, medyan 5 dakika dakika, bunların %70 kadarı 15 dakika ya da daha kısa. Kısa olanlar için en yaygın başlangıç saati senin saat diliminde , listenin en sessiz saati ise .

Bundan çıkarılacaklar:

  1. Yuvarlak bir saatte değil, kendi sessiz saatinde yeniden başlat. Bunu istatistik sayfandaki ısı haritası gösterir, sunucuların en yoğun olduğu zamanlar raporu da bölgeye göre nasıl değiştiğini gösterir. Oyuncuların saat dilimlerine yayılmışsa gece yarısını değil, eğrinin en düşük noktasını seç.
  2. Sohbette geri sayımla duyur ve kısa tut.
  3. Bir sebeple yeniden başlat. Güncellemeler, izlediğin bir bellek sızıntısı, bunu gerektiren bir yapılandırma değişikliği. Hiçbir şeyi düzeltmeyen günlük bir yeniden başlatma yine de günlük bir atılmaya mal olur.
  4. Sızıntıyı saklamak yerine bul. Bellek yeniden başlatmaya kadar tırmanıyorsa /spark heapsummary onu neyin doldurduğunu gösterir.

Yeniden başlatmalar tick lag'ını düzeltmez. Tick başına 30 ms'ye mal olan bir çiftlik, yeniden başlatmadan beş dakika sonra da tick başına 30 ms'ye mal olur. Listedeki kesinti rakamlarının tamamı çalışma süresi raporumuzda.

Donanım ne zaman yükseltilmeli

Profil öyle dediğinde yükselt. İşaretler:

  • Yukarıdaki şüphelilerle uğraştıktan sonra bile zirvede MSPT yaklaşık 40 ms'nin üstünde kalıyor.
  • Profil, zamanın sıradan vanilla işlerine (varlıklar, chunk'lar, blok güncellemeleri) yayıldığını gösteriyor ve tek bir suçlu kalmamış.
  • Bir VPS'te top, yoğun saatlerde CPU steal değerinin (st) tırmandığını gösteriyor, bu da komşularının parasını senin ödediğin çekirdekleri kullandığı anlamına gelir.

Sonra önce tek çekirdek hızı satın al, çünkü tick döngüsü tek çekirdekte çalışır. Daha fazla RAM yalnızca bellek sorunlarını çözer. Bundan sonrası için cevap yükü bölmektir: bir Velocity proxy'sinin arkasında birkaç sunucu ya da çok büyük bir dünya için Folia. İkisi de sunucu yazılımı rehberimizde anlatılıyor. Yeni makine için ödeme yapmadan önce sorulacak soruları hosting seçimi rehberinde bulabilirsin.