Minecraft’ta Hopper Lag’i ve Optimizasyonu

Minecraft hopper lag sorunu, TPS düşüklüğünün en sinsi kaynaklarından biridir. Ekranda kalabalık bir mob sürüsü ya da yüzlerce yerde duran eşya görmezsiniz; sunucu sessizce yavaşlar ve sebebi ilk bakışta anlaşılmaz. Oysa suçlu genellikle bir oyuncunun deposundaki yüzlerce huni ve çiftlikten depoya uzanan metrelerce huni hattıdır.

Huninin pahalı olmasının sebebi kapasitesi değil, sürekli çalışıyor olması. İçi boş bir huni bile üstünde ne olduğunu düzenli olarak kontrol eder. Yani hiçbir işe yaramadan tick harcar, ve bu maliyet huni sayısıyla doğrudan çarpılır.

Bu sayfada önce huninin ne yaptığını, sonra hangi ayarların yükü azalttığını, en sonunda da ayardan çok daha etkili olan tasarım değişikliklerini anlatıyoruz.

Huni Her Tick’te Ne Yapar?#

Huni, sandık veya fırın gibi bir block entity’dir; yani dünyada duran pasif bir blok değil, sunucunun düzenli olarak işlediği bir nesnedir. Bir huninin iş listesi şudur:

• Üstündeki kabı kontrol eder. Üstünde sandık, fırın, başka bir huni varsa oradan eşya çekmeyi dener.
• Üstündeki alanda eşya arar. Huninin üzerindeki bölgeye düşmüş item entity’leri toplamaya çalışır.
• Hedefine göndermeyi dener. Baktığı yöndeki kaba eşya itmeye çalışır.
• Sayacını işletir. Vanilla’da iki aktarım arasında 8 tick’lik bir bekleme vardır, yani saniyede 2,5 eşya.

Kritik nokta şu: bu işlerin çoğu başarısız olsa bile yapılır. Boş bir huni de üstüne bakar, dolu bir huni de göndermeyi dener. Tick süresi açısından “çalışan huni” ile “boşta duran huni” arasındaki fark, sandığınız kadar büyük değildir. Tick ve MSPT kavramlarına yabancıysanız tick, TPS ve MSPT sayfamız iyi bir başlangıç olur.

Neden Çok Sayıda Huni Sunucuyu Yorar?#

Rakama dökelim. Orta ölçekli bir survival sunucusunda tek bir oyuncunun deposunda 150-250 huni bulunması hiç sıra dışı değil. Varsayılan ayarlarla her huni saniyede 20 kez eşya kontrolü yapar:

200 huni x 20 tick/saniye = saniyede 4.000 kontrol
20 oyuncu benzer depo kurarsa  = saniyede 80.000 kontrol

Bu kontrollerin her biri tek başına mikrosaniyeler sürer. Toplandığında ise tick bütçesinin (50 ms) fark edilir bir kısmını yer. Üstelik huni yükü mob yükünün aksine oyuncu sayısıyla azalmaz: oyuncular çıkış yapsa bile chunk yüklü kaldığı sürece huniler çalışmaya devam eder. Sabah dördünde kimse yokken TPS’in 19’da takılı kalmasının klasik sebebi budur.

İkinci bir çarpan daha var: huniler nadiren tek başına bulunur. Hunili bir depo odası genellikle şu üçlüyle birlikte gelir — yüzlerce sandık, sıralama devresini süren redstone ve çiftlikten gelen sürekli eşya akışı. Yani huni sayısı arttıkça yalnızca huni maliyeti değil, aynı chunk’taki blok güncellemesi ve item entity maliyeti de artar. Bu yüzden depo odaları profil raporlarında beklenenden daha ağır görünür.

Bir de eşya birikmesi meselesi var. Hedefi dolan bir huni eşyayı gönderemez, huninin üstündeki eşyalar yerde birikmeye başlar ve her biri ayrı bir entity olur. Depoları dolmuş çiftlikler bu yüzden iki kat maliyet üretir: hem çalışan huniler hem yerde bekleyen eşya yığını. Entity tarafını da sıkılaştırmak istiyorsanız entity limit ve mob yoğunluğu ayarları sayfası bu sayfanın doğal devamıdır.

spigot.yml: Aktarım ve Kontrol Aralıkları#

Huni davranışını yöneten ayarların çoğu spigot.yml içindedir. Dosyanın tamamı için paper.yml, spigot.yml ve bukkit.yml optimizasyon rehberimize bakabilirsiniz.

world-settings:
  default:
    hopper-amount: 1
    hopper-can-load-chunks: false
    ticks-per:
      hopper-transfer: 8
      hopper-check: 8

Üç ayarın anlamı birbirine karışıyor, ayıralım:

ticks-per.hopper-transfer

İki aktarım arasındaki bekleme. Varsayılan 8 tick, yani saniyede 2,5 eşya. Büyütmek eşya akışını yavaşlatır ve oyuncular bunu fark eder.

ticks-per.hopper-check

Huninin üstünde eşya var mı diye kaç tick’te bir bakacağı. Varsayılan 1’dir; her tick bakar. 8 yapmak aktarım aralığıyla hizalar ve taramayı sekizde bire indirir.

hopper-amount

Tek aktarımda taşınan eşya sayısı. Varsayılan 1. Artırmak akışı hızlandırır ama eşya ayırıcı devrelerini bozar.

hopper-can-load-chunks

Huninin, hedefi yüklü olmayan bir chunk’taysa o chunk’ı yüklemesine izin verir. false yapın.

Önceliğiniz hopper-check olmalı. 1’den 8’e çıkarmak, oyun deneyimine neredeyse hiç dokunmadan huni taramalarının büyük kısmını siler. hopper-transfer değerine ise dikkatli yaklaşın; 8’den 16’ya çıkarmak eşya akışını yarıya indirir ve otomatik tarlası olan oyuncular bunu hemen görür.

Paper Tarafındaki Huni Ayarları#

Paper, config/paper-world-defaults.yml içinde vanilla’da bulunmayan üç anahtar sunar.

hopper:
  cooldown-when-full: true
  disable-move-event: false
  ignore-occluding-blocks: true

cooldown-when-full

Hedefi dolu olan huniyi bekletir; sürekli “gönderebiliyor muyum” diye denemesini engeller. Açık bırakın.

ignore-occluding-blocks

Üstünde katı blok olan huninin eşya taramasını atlar. Aşağıdaki “üstü kapalı huni” tekniğinin sunucu tarafındaki karşılığıdır.

disable-move-event

Her huni aktarımında eklentilere gönderilen olayı kapatır. Ciddi kazanç sağlar, ama riskli bir ayardır.

Üstü Kapalı Huni: En Ucuz Kazanç#

Aktarım zincirindeki bir huninin dünyadan eşya toplaması gerekmez; onun işi üstündeki huniden aldığını bir sonrakine iletmektir. Buna rağmen varsayılan davranışta üstündeki alanı düzenli olarak tarar.

Çözüm basit: o hunilerin üstünü katı bir blokla kapatın. Taş, toprak, ne olursa. Kapalı üst kısma eşya düşemez, dolayısıyla tarama zaten anlamsızdır; Paper’ın ignore-occluding-blocks ayarı açıkken sunucu bu hunilerde aramayı tamamen atlar.

Yanlış tasarım              Doğru tasarım
-----------------           -----------------
[ hava   ]                  [ taş    ]   <- tarama yok
[ huni   ]  <- tarar        [ huni   ]
[ huni   ]  <- tarar        [ huni   ]  (üstü zaten huni, sorun yok)
[ sandık ]                  [ sandık ]

Yalnızca gerçekten eşya toplayan huninin üstü açık kalmalı: su akıntısının bittiği toplama noktası veya çiftliğin düşüş tüpünün altındaki huni. Diğer herşey kapatılabilir.

Huni Yerine Su Akıntısı ve Tek Toplama Noktası#

Ayar değişikliği yükü azaltır; tasarım değişikliği yükü ortadan kaldırır. Yatay eşya taşımada suyun huniye karşı tek bir dezavantajı yoktur: sunucuya block entity maliyeti bindirmez.

Klasik hatalı tasarım, çiftliğin altına baştan sona huni hattı döşemektir. 9x9’luk bir toplama zemininde bu 81 huni demektir. Doğrusu şudur:

1. Zemini su kanallarına bölün#

   Su kaynak bloğu 8 blok akar. Toplama alanının kenarlarına kaynak koyup akıntıyı merkeze doğru yönlendirin. 16 bloktan geniş alanlarda ara kaynaklarla akıntıyı yenileyin.

2. Tek bir toplama noktası bırakın#

   Bütün akıntılar tek bir bloğa çıksın. Oraya bir huni, altına sandık koyun. 81 huni yerine 1 huni.

3. Dikey taşımayı kabarcık sütunuyla yapın#

   Soul sand üzerine kurulan su sütunu eşyaları yukarı taşır; huni asansörüne gerek kalmaz. Aşağı taşımada magma bloğu aynı işi ters yönde görür.

4. Depo girişinde tek zincir kullanın#

   Sandık odasına giren tek bir huni hattı yeterlidir. Her sandığın altına ayrı huni koymayın.

Huni Zincirini Kısaltmak#

Huni hattı yalnızca pahalı değil, aynı zamanda yavaştır: her huni 8 tick bekler, yani eşya blok başına 0,4 saniye kaybeder. 30 blokluk bir hat 12 saniye demektir. Su akıntısı aynı mesafeyi saniyeler içinde alır.

Pratik kural: huniyi taşıma aracı değil, arayüz olarak kullanın. Huni yalnızca eşyanın dünyadan kaba, kaptan kaba geçtiği noktalarda bulunsun; aradaki yolu su alsın. Aynı mantık çiftlikler için de geçerlidir; otomatik tarla tasarımlarında ürünü tek kanalda toplamak hem daha hızlı hem daha ucuzdur.

Dropper tabanlı taşıma da bir seçenektir: dropper redstone darbesi almadıkça iş yapmaz, yani boşta maliyeti yoktur. Ancak onu süren redstone saatinin kendi maliyeti vardır; sürekli çalışan bir saat kurup “hunilerden kurtuldum” demek kendinizi kandırmak olur.

Hopper minecart gerçekten daha mı ucuz?#

Depo tasarımlarında sık başvurulan bir alternatif hopper minecart’tır. Katı bloğun altından bile eşya toplayabildiği için zemin altına gizlenmiş bir ray hattı, üstteki bütün eşyaları çeker; görünürde hiç huni yoktur ve tasarım temiz durur.

Ama maliyet ortadan kalkmaz, sadece yer değiştirir. Hopper minecart bir block entity değil entity’dir; sürekli hareket ettiği için raydaki her tick’te konum, çarpışma ve toplama hesabı yapar. Onlarca minecart’ın döndüğü bir sistem, aynı işi yapan hunili sistemden ucuz olmayabilir. Üstelik entity olduğu için entity-activation-range altındaki misc değerinden etkilenir ve oyuncu uzaklaştığında beklenmedik biçimde durabilir.

Pratik kural: tek bir toplama hattı için hopper minecart makul, onlarca minecart’lı döngüler için değil. Sunucu genelinde bu tasarımı teşvik edecekseniz sayısına bir sınır koyun.

Ölçüm: Huni Yükü Nasıl Tespit Edilir?#

Tahminle iş yapmayın. Huni yükü spark raporunda çok net görünür ve 26.1 ile birlikte sunucu jar’ı unobfuscated hâle geldiği için rapordaki sınıf adları artık doğrudan okunabilir; huni tick fonksiyonunu aramak için gizli isim tablolarıyla uğraşmanıza gerek yok.

spark health
spark tps
spark profiler --timeout 300 --thread server
spark tickmonitor --threshold 100

Raporda block entity tick bölümüne bakın. Huni ilgili çağrılar toplam sunucu tick süresinin yüzde 5’ini geçiyorsa müdahale zamanı gelmiştir. Rapor okumayı bilmiyorsanız spark ve timings analizi sayfamız adım adım anlatıyor.

Suçlu bölgeyi bulmak için iki pratik yöntem var. Birincisi, WorldEdit ile bir bölge seçip saymak:

//pos1
//pos2
//count hopper

İkincisi, tickmonitor açıkken oyuncu üslerinin arasında dolaşmak. Bir chunk’a girdiğinizde MSPT fırlıyorsa sorun oradadır. WorldEdit ve bölge araçları için WorldEdit ve WorldGuard rehberine bakabilirsiniz.

Sunucu Genelinde Huni Sayısını Sınırlama#

Ayarlar ve tasarım önerileri sizin kontrolünüzdedir, ama oyuncuların üsleri değil. Bir noktadan sonra sınır koymak gerekir.

Uygulama tarafında en çok hata yapılan yer burası. Limiti bir gecede koyup mevcut depoları bozmak, oyuncu kaybetmenin garantili yoludur. Doğru sıra şudur: önce ölçün, sonra makul bir limit belirleyin, sonra duyurun, en az bir hafta geçiş süresi verin, ondan sonra uygulayın. BentoBox tabanlı skyblock sunucularında zaten hazır bir limit altyapısı var, kullanın.

Ada limiti, blok limiti ve benzeri sistemlerin hepsi eklenti işidir ve hepsi bir yönetim maliyeti getirir; limiti koymadan önce mevcut depoların sayımını alın ki eşiği körlemesine belirlemeyin. Yerdeki eşya birikmesini ayrıca temizlemek istiyorsanız entity temizleme sayfası tamamlayıcı olur.

Özetle#

Huni lag’i, sunucunun sessiz gider kalemidir: görünmez, sürekli çalışır ve oyuncu sayısıyla azalmaz. Yükü azaltmanın sırası şudur.

Önce ayarlar: ticks-per.hopper-check değerini 8 yapın, hopper-can-load-chunks ayarını kapatın, Paper tarafında cooldown-when-full ve ignore-occluding-blocks açık olsun. hopper-amount ve disable-move-event ayarlarına dokunmadan önce iki kez düşünün.

Sonra tasarım: aktarım zincirindeki hunilerin üstünü katı blokla kapatın, uzun huni hatlarını su akıntısıyla değiştirin, dikey taşımada kabarcık sütunu kullanın, boşta duran hatları redstone ile kilitleyin. Bir hattı 30 huniden 1 huniye indirmek, hiçbir config ayarının veremeyeceği kazançtır.

En sonda ölçüm var: spark raporu olmadan ne kazandığınızı bilemezsiniz. Bütün bunları yaptığınız hâlde tick süreniz hala yüksekse sorun huni değildir; TPS düşüklüğü teşhis rehberine ve genel strateji için optimizasyon ana rehberine geçin. Tek çekirdek performansı yetersiz kalıyorsa yüksek frekanslı Ryzen tabanlı Minecraft sunucu paketleri config’in çözemeyeceği kısmı çözer.