Minecraft sunucusu kasıyor: “Can't keep up” ve Watchdog zaman aşımını doğru çöz

Minecraft logundaki en yaygın üç lag mesajı aynı anlama gelmez: Can't keep up! Is the server overloaded? sunucunun çalışmaya devam ettiğini, ama yetişemediğini gösterir. A single server tick took 60.00 seconds yerleşik acil frenin sunucuyu sert şekilde kapattığı anlamına gelir. Exception in server tick loop ise belirli bir program hatasının oyun döngüsünü bozduğu anlamına gelir. Üçünü de aynı şekilde ele alan kişi çoğu zaman yanlış şeyi düzeltir.

Üç mesajı birbirinden ayırmak

Minecraft oyun dünyasını saniyede 20 kez hesaplar. Böyle bir döngüye tick denir ve en fazla 50 milisaniye sürmelidir. Yaşadığın her lag, bu tek sayıdan sapmadır.

Son satır sık sık kafa karıştırır: Paper dışarıdan gelen her sorguyu uyarı olarak bildirir. Bu, yaklaşık beş dakikada bir yaptığımız planlı performans ölçümüdür; hata değildir ve oyununa müdahale etmez.

En önemli hamle: Watchdog mesajlarında yukarıyı oku

Watchdog kill bir belirtidir, neden değildir. Sadece şunu söyler: bir şey sunucu thread'ini izin verilenden daha uzun süre bloke etti. Onu neyin bloke ettiği başka yerde yazar.

İki durum vardır ve tamamen farklı önlemlere götürür:

Durum 1 — Watchdog önce geldi. Watchdog satırından önce normal oyun çalışması vardır. O zaman tick süresi gerçekten mesajın kendisidir: bir şey sunucuyu çalışma sırasında dondurmuştur.

Durum 2 — Watchdog sonradan geldi. Watchdog satırından önce zaten Stopping server veya Preparing crash report yazar. O zaman sunucu daha önce ölmüş ya da kapanma sürecindedir ve Watchdog sadece takılı kalan kapanışı temizlemiştir.

Bu ikinci durum kenarda köşede rastlanan bir şey değildir. 22 Ağustos 2026 tarihli bir destek vakasında sunucu thread'i 13:20:15'te çöktü, temiz bir Stopping server başlattı ve ancak 60 saniye sonra Watchdog devreye girdi. Orada tick süresini neden ilan eden kişi, işletmeciyi bir dakika yukarıda duran gerçek hata mesajından uzaklaştırır. Konsol analizimizin Watchdog eşleşmesini bilinçli olarak en son değerlendirmesinin nedeni tam olarak budur: Aynı log bölümünde daha özel bir imza varsa, sana “bir tick yavaştı” değil, o açıklama gösterilir.

Nedene adım adım ulaşmak

1. Panelde TPS geçmişini kontrol et

Sunucunu panelde aç. “Performance (letzte 24h)” altında TPS geçmişini görürsün; sunucu çalıştığı sürece yaklaşık her beş dakikada bir ölçülür. Eğrinin şekli bile çok şey söyler:

• Belirli bir saatte keskin bir düşüş → bir olay. Saati logla karşılaştır: dünya oluşturma, backup, keşfedilmemiş arazide bir oyuncu, bir plugin görevi.
• Sürekli düşük değerler → yapısal aşırı yük. Burada restart değil, yükü azaltmak yardımcı olur.
• Testere dişi deseni → bellek baskısı için tipiktir: Sunucu çalışır, Garbage Collection araya girer, bu tekrar eder.

Değerler daha uzun bir zaman penceresinde düşük kalırsa panel kendiliğinden “TPS dauerhaft niedrig” uyarısıyla haber verir.

2. MSPT ölç — tek başına TPS yetmez

Konsola /spark tps yaz. Komut iki sayı verir ve ikincisi daha önemlidir:

• TPS — saniyedeki tick sayısı, maksimum 20.
• MSPT — tick başına milisaniye. 50 ms'ye kadar her şey sağlıklıdır.

Neden MSPT? Bukkit, Spigot ve Paper çöküşü önlemek için sunucu süreçlerini yavaşlatır. Bu yüzden gösterge düz 20 TPS gösterebilir, ama sunucu gerçekte çoktan limite dayanmış olabilir. 45 ms MSPT değeri şunu gösterir: Görünür şekilde lag yaşamak için bir Mob farm uzağındasın, TPS göstergesi hâlâ kusursuz görünse bile.

Paper 1.21 ve sonrasında spark zaten dahildir, hiçbir şey kurmana gerek yoktur.

3. Nedeni profiler ile bul

Hangi plugin suçlu diye tahmin yürütme, ölç:

/spark profiler start --timeout 120

Bu iki dakika içinde lag yapan durumu oyunda tekrar oluştur. Sonra sunucunun verdiği sonuç bağlantısını aç. Rapor, tick süresinin nereye gittiğini süre payına göre sıralı gösterir: belirli bir Mod, bir plugin görevi, chunk yükleme, entity işleme veya Garbage Collection.

Bu rehberin “daha fazla RAM satın al” yaklaşımından ayrıldığı nokta burasıdır. Profiler, bir öneri tablosunun cevaplayamayacağı soruyu cevaplar: Sunucunda zamanı tam olarak ne harcıyor?

4. Hedefli şekilde yükü azalt

Profiler'ın gösterdiği şey, uygulanacak önlemi belirler:

Son nokta önemlidir: RAM sadece bellek sorununu çözer. Bir Redstone saati tick süresini yiyorsa daha büyük bir paket sunucuyu hızlandırmaz. Oyuncu sayına ve Modpack boyutuna ne kadar RAM uyduğunu Minecraft RAM hesaplayıcımız hesaplar.

5. max-tick-time — çözüm değil, istisna

Bu değer server.properties içinde yer alır ve Watchdog'un hangi tick süresinden sonra devreye gireceğini belirler. Standart değer 60000 milisaniyedir, yani 60 saniye. Değer aşılırsa sunucu kendini kapatır.

İnternetteki birçok rehber bu noktada Watchdog'u -1 ile kapatmayı önerir. Bunu standart çözüm olarak yapma. Watchdog, gerçek bir deadlock'u überhaupt fark eden tek yerleşik mekanizmadır. -1 ile ölü bir sunucu saatlerce portta asılı kalır: Oyuncular giremez, logda nedenini açıklayan hiçbir şey yoktur ve kimse uyarılmaz. Göstergeyi kaldırmış olursun, sorunu değil.

Artırmak için tam olarak bir iyi gerekçe vardır: bilinen bir işlem meşru şekilde uzun sürüyordur. Klasik örnek, büyük bir Modpack'in ilk başlatılmasıdır; dünya oluşturma ve Mod başlatma birlikte tek bir tick içinde bir dakikayı aşabilir. O zaman örneğin 180000 (üç dakika) gibi bir değer kabul edilebilir — geçici olarak ve ilk başarılı başlatmadan sonra geri alma niyetiyle.

Logda Exception in server tick loop yazıyorsa

Bu mesaj üçü içinde en basitidir, çünkü nedenini yanında getirir. Hemen altında veya birkaç satır sonra bir Caused by: satırı bulunur — asıl hata orada yazar, çoğunlukla sorumlu Mod'un veya plugin'in adıyla birlikte.

İzlenecek yol:

1. Caused by: ara ve sınıf adını not et.
2. İçinde bir Mod veya plugin adı varsa, neden olan bileşen bellidir.
3. Hata bir değişiklikten sonra ortaya çıktıysa (yeni Mod, update, yeni dünya), önce bu değişikliği geri al.
4. Hata belirsiz kalırsa, ilgili bölümün tamamını saat bilgisiyle birlikte desteğe gönder.

Sunucunun konsol analizi bu satırları otomatik olarak tanır ve tespit edilen her mesajı sıklığı dahil olmak üzere açık dille açıklar. Başka yerden sadece bir log parçası aldıysan, bunu Crash Report Analyzer aracımıza yapıştırabilirsin — bizde sunucun olmasa bile.

Senin için otomatik olarak üstlendiklerimiz

• Uğraşmadan performans ölçümü. TPS yaklaşık her beş dakikada bir kaydedilir ve panelde 24 saat boyunca gösterilir — bunun için plugin kurmana gerek yoktur.
• Kalıcı zayıflıkta uyarı. Performans güvenilir bir zaman penceresi boyunca düşük kalırsa, bunu kendin fark etmek zorunda kalmadan uyarılırsın.
• Açıklanan log satırları. Tanınan mesajlar, neden ve çözümle birlikte açık dille, senin dilinde gösterilir — uygun bir rehber varsa oraya bağlantıyla birlikte.
• Belirti-neden önceliği kuralı. Aynı log bölümünde Watchdog kill'den daha anlamlı bir hata mesajı varsa, sana onu gösteririz.

Troubleshooting: Belirti, kontrol, çözüm

FAQ

Oyuncular hangi TPS değerinden itibaren bir şey fark eder?

Yaklaşık 18 TPS'ye kadar oyunda pek bir şey fark edilmez. 15'in altında belirgin şekilde ağırlaşır. Ama sadece buna güvenme: Ek olarak MSPT'yi kontrol et, çünkü TPS limiter sunucu zaten limite dayanmışken sağlıklı bir sayı gösterebilir.

Daha fazla RAM lag sorununa iyi gelir mi?

Sadece gerçekten darboğaz bellekse. Profiler ana kalem olarak Garbage Collection gösteriyorsa evet. Bir Redstone saati veya Mob farm gösteriyorsa daha fazla RAM hiçbir şeyi değiştirmez. Önce ölç, sonra satın al.

Watchdog'u kapatmalı mıyım?

Hayır, kalıcı olarak değil. -1 gerçek bir donmayı otomatik algılayan tek mekanizmayı elinden alır. Büyük bir Modpack'in ilk başlangıcı gibi bilinen yavaş bir işlem için max-tick-time değerini geçici olarak artırmak kabul edilebilir — sonra geri al.

Watchdog mesajı neden “Stopping server” sonrasında görünüyor?

Çünkü sunucu zaten kapanma sürecindeydi ve bu sırada takılı kaldı. Watchdog o zaman takılı kalan kapanışı temizledi, çalışan bir sunucuyu öldürmedi. Neden Stopping server satırından önce yazar.

Restart yardımcı olur mu?

Akut bir birikmeye karşı evet, nedene karşı hayır. Lag her restarttan kısa süre sonra geri geliyorsa yapısaldır — o zaman ancak ölçüm ilerletir.

view-distance ile simulation-distance arasındaki fark nedir?

view-distance oyuncuların ne kadar uzağı gördüğünü belirler; simulation-distance dünyanın gerçekten ne kadar uzağının hesaplandığını belirler. İkisi de varsayılan olarak 10 chunk'tır. Sadece simüle edilen chunk'lar hesaplama süresi tükettiği için simulation-distance değerini düşürmek daha az görünür kayıpla daha fazla rahatlama sağlar.

Lag devam ederse

Destek talebinden önce üç şeyi topla: son olayın tam saati, spark Profiler raporunun bağlantısı ve sonradan hangi Mod'ların veya plugin'lerin eklendiği bilgisi. Böylece genel bir optimizasyon turu yerine logdaki doğru bölüm hedefli şekilde kontrol edilebilir.

Tüm oyunlar için genel ayarlar — restart planları, paket seçimi, ağ — Gameserver performansını iyileştirme rehberinde bulunur. Mod'ları ve plugin'leri temiz şekilde nasıl kurup kaldıracağını Minecraft Mod'ları ve plugin'leri kurma içinde anlattık.

TPS ölçümü, log açıklaması ve uyarıların ek uğraş olmadan dahil olduğu bir sunucu mu istiyorsun? Minecraft sunucusu kirala sayfasında uygun paketleri bulabilirsin.

Kaynaklar ve test ortamı

• max-tick-time, tickrate ve mesafeler: PaperMC — server.properties. 60000 milisaniyelik standart değeri, aşımda zorunlu kapatmayı, -1 ile devre dışı bırakmayı ve view-distance ile simulation-distance için 10 standart değerlerini belgeler.
• spark Paper içinde dahildir: PaperMC — Profiling. Paper 1.21 ve sonrasında ayrı indirme gerekmez.
• TPS'ten önce MSPT: spark — TPS and MSPT. TPS limiter'ın, sunucu gerçekte daha yavaş çalışırken neden düz 20 gösterebildiğini açıklar.
• Profiler komutları: spark — Command Usage. /spark profiler start --timeout <sekunden> ve /spark profiler stop için kaynak.

Test ortamı: 24 Ağustos 2026. Standart değerler ve komutlar yeni sunucu sürümleriyle değişebilir; şüphede kalırsan bağlantısı verilen üretici dokümantasyonunu kontrol et.