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.
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ür | Oyuncuların fark ettiği | Nasıl doğrulanır | Kim 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 komutu | Sen, sunucuda |
| Ağ lag'ı | Bazı oyuncularda geri sekme (rubber-banding) ve geç işleyen vuruşlar, diğerleri sorunsuzken | Oyuncu 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 etkiler | F3 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ç
- 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.
/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/msptkomutu kısa versiyonu verir./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.- Konsolu oku. Vanilla'nın
Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behinduyarı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. - 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.
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 100yalnı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 100bir 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üzeltme | Neye yardım eder | Oyunculara 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ın | Her oyuncunun çevresindeki varlık ve blok tick'leri | Oyuncular uzaklaştığında çiftlikler ve ekinler daha erken çalışmayı bırakır |
| Dünyayı önceden üret ve bir sınır koy | Chunk üretimi sıçramaları | Bir dünya sınırı |
| Chunk başına varlıkları sınırla ya da çiftlik kuralları koy | Varlık tick'leri | Daha küçük çiftlikler |
ALTERNATE_CURRENT redstone | Redstone ağırlıklı yapılar | Redstone zamanlamasında nadir farklar |
spigot.yml içindeki entity-activation-range değerini düşür | Oyunculardan uzaktaki moblar | Uzaktaki moblar daha yavaş davranır |
| Spark'ın adını verdiği eklentiyi düzelt, yeniden yapılandır ya da değiştir | Eklenti yükü | Eklentiye bağlı |
| Sunucu yazılımının en son sürümüne güncelle | Düzeltilen hatalar ve yeni optimizasyonlar | Bir 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çü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:
- 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ç.
- Sohbette geri sayımla duyur ve kısa tut.
- 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.
- Sızıntıyı saklamak yerine bul. Bellek yeniden başlatmaya kadar tırmanıyorsa
/spark heapsummaryonu 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.
Sıradaki okuma
Okumaya devam et.
Paper, Purpur, Folia ya da Velocity: sunucular gerçekte ne kullanıyor
Pinglediğimiz sunucular ne kullanıyor, Paper, Purpur, Leaf, Folia ve Velocity ne işe yarıyor ve Minecraft sunucu yazılımı güvenle nasıl değiştirilir.
Minecraft sunucu hosting'i nasıl seçilir: gerçekten önemli olanlar
Hızlı CPU çekirdekleri ve iyi konum RAM'den daha önemli. Ping aracımızın ücretsiz hostlarda gördükleri, RAM aralıkları ve ödemeden önce hosta sorulacaklar.