Minecraft Sunucusu İçin Kaç GB RAM Gerekir?

Oyuncu sayısına göre Minecraft sunucusu için kaç GB RAM gerekir?

Bir Minecraft sunucusunun ihtiyaç duyduğu RAM'i üç şey belirler: aynı anda kaç oyuncunun çevrimiçi olduğu, bu oyuncuların haritada ne kadar dağınık oynadığı ve sunucunun ne çalıştırdığı. Vanilla ya da birkaç eklentili bir Paper sunucusu hafiftir; veri önbelleğe alan her eklenti biraz daha ekler. Mod paketleri ise belleği katlarca artırabilir, çünkü her mod daha tek bir oyuncu girmeden kendi bloklarını, eşyalarını, tariflerini ve dünya üretim verilerini belleğe yükler. Aşağıdaki tablo, görüş mesafesi 8 civarında olan ve dünyası önceden oluşturulmuş bir Java Edition sunucusu için gerçekçi başlangıç noktaları verir.

Bu değerleri hedef değil, alt sınır olarak düşün. Paper'ın kendi dokümantasyonu, Aikar'ın uzun süredir verdiği tavsiyeyi izleyerek, oyuncu sayısı ne kadar az olursa olsun en az 6–10 GB öneriyor; çünkü çöp toplayıcı (garbage collector) boş alan olduğunda çok daha akıcı çalışır. Bu tavsiye akıcılıkla ilgili, sunucunun ayakta kalmasıyla değil: 4 GB'lık bir arkadaş sunucusu sorunsuz döner, ama çöp toplamadan kaynaklanan düzenli takılmalar görürsen bir üst kademeye geçmek en ucuz çözümdür. Toplam üye sayısını değil, en yoğun saatteki eşzamanlı oyuncu sayısını hesapla: 200 üyeli ama akşamları 25 kişinin çevrimiçi olduğu bir topluluk, 25 oyunculuk bir sunucudur.

Neden daha fazla RAM her zaman daha hızlı sunucu demek değil?

Ek RAM yalnızca sunucu gerçekten bellek sıkıntısı çekiyorsa işe yarar; yüklü chunk'lar, entity'ler ve eklenti verileri rahatça sığdıktan sonra geri kalanı boşta bekler. Minecraft dünya simülasyonunu tek bir ana thread üzerinde yürütür ve saniyede 20 tick tutturmak için her tick'i 50 milisaniyede bitirmesi gerekir. Bu thread çok fazla mob, hopper ya da redstone yüzünden süreyi aşıyorsa çözüm, tick başına işi azaltmak ya da daha hızlı bir işlemci çekirdeğidir. Belleği iki katına çıkarmak hiçbir şeyi değiştirmez; 16 GB'lık ama sürekli takılan sunucuların bu kadar yaygın olmasının sebebi budur.

Gereğinden büyük ayar ters de tepebilir. Java, Xmx ile belirlediğin heap'in dışında kendi kodu, thread'leri ve ağ tamponları için de bellek kullanır; bu yüzden Aikar, Xmx değerini makinenin ya da konteynerin verebileceği miktarın yaklaşık 1000–1500 MB altında tutmayı önerir. Bu payı bırakmazsan işletim sistemi diske takas (swap) yapmaya başlar ya da süreci doğrudan sonlandırır. Çok büyük bir heap bellek sızıntılarını da gizler: kötü yazılmış bir eklenti günlerce sızdırabilir ve çöp toplayıcı bir gün tam toplamaya (full GC) düşerse bu duraklama heap büyüdükçe uzar.

Madalyonun öbür yüzü de aynı derecede önemli: az RAM, fazla RAM'den daha kötüdür. Heap neredeyse dolduğunda çöp toplayıcı art arda çalışır, her turda daha az yer açar ve oyuncular bunu ritmik takılmalar olarak hisseder; sonunda OutOfMemoryError ile çökme gelir. Hedef, toplamaları kısa ve seyrek tutacak kadar boşluk bırakmaktır; ölçümlerde karşılığını görmediğin ek belleğin sunucuna bir faydası yoktur.

Aikar bayrakları (Aikar's flags) nedir, kullanmalı mısın?

Aikar bayrakları, Paper projesinin dokümantasyonunda yayımlanan ve G1 çöp toplayıcısını Minecraft'ın bellek kullanım biçimine göre ayarlayan bir Java başlatma parametreleri setidir. Sunucu çok kısa ömürlü muazzam sayıda nesne üretir; Paper dokümantasyonu bunu 30 oyunculu bir sunucuda saniyede en az 800 MB olarak verir. Varsayılan ayarlarda bu nesnelerin bir kısmı eski nesile (old generation) taşınır ve sonradan daha ağır toplamalarla temizlenir. Bayraklar genç nesli (young generation) büyüterek çöpün büyük kısmının genç ölmesini ve hızlı, ucuz turlarda toplanmasını sağlar.

Tam liste göz korkutsa da temel fikirler basittir. Xms ve Xmx aynı değere ayarlanır, böylece heap hiç yeniden boyutlanmaz; AlwaysPreTouch da belleğin tamamını açılışta ayırır. En fazla dört tick'e denk gelen 200 milisaniyelik duraklama hedefi, G1'e her duraklamayı kısa tutmasını söyler. DisableExplicitGC, eklentilerin gereksiz tam toplamaları zorlamasını engeller; birkaç G1 bölge ve eşik ayarı da toplama yükünü azaltır. Aikar'ın özgün yazısı, 12 GB'ın üzerindeki heap'ler için bu değerlerden birkaçını ayrıca değiştirir.

Bunlar eklenti ayarı değil JVM parametresi olduğu için Paper, Purpur, Fabric, NeoForge ve Forge'da aynı şekilde kullanılır. Listeyi eski bir forum gönderisinden değil, Paper dokümantasyonundaki güncel halinden al ve bellek değerini paketinle uyumlu tut. Ne yaptıklarını da unutma: çöp toplama kaynaklı takılmaları yumuşatırlar, aşırı yüklenmiş bir ana thread'i hızlandırmazlar. Büyük heap'i ve boşta çekirdeği olan bazı yöneticiler, duraklamaları çok kısa tutan ama ek işlemci ve bellek harcayan ZGC'yi dener; yine de belgelenmiş varsayılan, Aikar bayraklı G1'dir.

Görüş mesafesi ve simülasyon mesafesi RAM'i nasıl etkiler?

Görüş mesafesi (view-distance), kontrolündeki en büyük RAM ayarıdır. Sunucu her oyuncunun çevresinde kare şeklinde bir chunk alanını yüklü tutar: varsayılan 10 değerinde bu kabaca 21'e 21, yani oyuncu başına yaklaşık 441 chunk demektir; 8'de yaklaşık 289'a, 6'da yaklaşık 169'a düşer. Aynı bölgede birlikte oynayan oyuncular aynı chunk'ları paylaşır, ama haritaya dağılmış her oyuncu kendi karesini taşır. On kâşifin, aynı kasabadaki on kişiden çok daha fazla bellek harcamasının nedeni budur.

Simülasyon mesafesi (simulation-distance), her oyuncudan ne kadar uzaktaki mobların hareket edeceğini, ekinlerin büyüyeceğini ve redstone'un çalışacağını belirler. Asıl olarak işlemci ayarıdır, ama aynı anda bellekte aktif olan entity sayısını da etkiler. Kalabalık sunucular genellikle görüş mesafesini 7–8'e, simülasyon mesafesini 4–6'ya çeker: oyuncular hâlâ uzağı görür, ağır tick işleri ise yalnızca yakınlarında yapılır. Spigot ve Paper bu değerleri spigot.yml içinde dünya bazında ayarlamana da izin verir; böylece kaynak dünyası ana dünyadan daha düşük değerlerle çalışabilir.

Dünyayı neden Chunky ile önceden oluşturmalısın?

Ön üretim (pre-generation), araziyi oyuncular gelmeden oluşturur; böylece sunucu oyun sırasında yeni chunk üretmek zorunda kalmaz. Bir chunk'ı üretmek araziyi şekillendirmek, yapıları ve mağaraları yerleştirmek ve ışığı hesaplamak demektir ve sunucunun yaptığı en ağır işlerden biridir. Elytra ile uçan ya da buz üzerinde tekneyle giden tek bir oyuncu saniyede onlarca yeni chunk isteyebilir; bu da çevrimiçi olan herkes için işlemci ve bellek kullanımını yukarı iter.

Bu iş için standart araç Chunky'dir ve Paper, Spigot, Folia, Fabric, NeoForge, Forge ve Sponge'da çalışır. Bir merkez ve yarıçap belirle, örneğin chunky radius 5000 ve ardından chunky start yaz, sonra sunucu sakinken çalışmasına izin ver; büyük bir yarıçap saatler sürebilir, gerekirse duraklatıp kaldığı yerden devam ettirebilirsin. Bitince vanilla worldborder set komutuyla oluşturulan alanın hemen içine bir dünya sınırı koy; komut çap aldığı için 5000 bloklük yarıçapa 10000 yazarsın. Önceden oluşturulmuş dünyanın daha fazla disk kapladığını da hesaba kat ve depolama alanını kontrol et.

Mod paketleri ne kadar RAM ister?

Mod paketleri daha fazla RAM ister, çünkü her mod içeriğini daha tek bir oyuncu girmeden açılışta belleğe yükler; teknoloji ve otomasyon modları da dünya büyüdükçe makine, boru ve depolanan eşya ekleyerek belleği büyütür. Mod sayısı en hızlı göstergedir, ama içerik de önemlidir: elli dünya üretimi ve boyut modu, yüz küçük kolaylık modundan daha ağırdır. Çoğu paket, indirme sayfasında ya da sunucu dosyalarında önerilen sunucu belleğini belirtir; oradan başla, gerçek kullanımı izledikten sonra ayarla.

Sunucunun yanı sıra her oyuncunun da paketi kurması gerekir, yani oyuncuların kendi bilgisayarlarında da boş bellek olmalı. Paketin önerdiği en düşük miktarla başla, oyuncuları kademeli ekle ve heap çöp toplamadan sonra bile yüksek kalıyorsa yükselt. TheCrewHost'ta NeoForge sunucuları en az 6 GB RAM ile başlar, Minecraft paketleri 4 GB ile 32 GB arasında değişir ve istediğin an daha büyük bir pakete geçebilirsin.

RAM yerine işlemcinin tek çekirdek hızı ne zaman daha önemlidir?

Bellek yeterli olduğu anda işlemci hızı RAM'den daha önemli hale gelir ve doğru boyutlandırılmış bir sunucuda bu neredeyse her zaman geçerlidir. Ana thread entity'leri, blok güncellemelerini, redstone'u, ekin büyümesini ve her eklenti olayını sırayla işler ve bunun için tick başına 50 milisaniyesi vardır. Paper chunk yükleme ve üretimini ve ağ işlerinin bir kısmını başka thread'lere taşır, bu yüzden ek çekirdekler kenarlarda yardımcı olur; ama ne kadar dünyayı gecikmeden simüle edebileceğini hâlâ tek bir çekirdeğin hızı belirler.

Bunun en net işareti, bellek iyi durumdayken yaşanan gecikmelerdir: MSPT 50'nin üzerine çıkar, TPS 20'nin altına düşer, ama çöp toplamadan sonraki heap kullanımı sınırın epey altındadır. Böyle bir sunucunun ihtiyacı daha fazla RAM değil, tick başına daha az iş ya da daha hızlı bir çekirdektir. Tick işini çekirdeklere dağıtan tek tasarım Folia'dır ve yalnızca oyuncuları dağınık, çok büyük ve eklentileri Folia'ya uygun sunucularda karşılığını verir. TheCrewHost'un oyun sunucuları, çekirdek başına yüksek saat hızı sunan güncel bir masaüstü sınıfı işlemci olan AMD Ryzen 9 9950X ile DDR5 bellek ve NVMe SSD üzerinde çalışır.

Sunucunun RAM'i yetmiyor mu, nasıl anlarsın?

Kontrol panelindeki bellek grafiğine tek başına güvenme: Xms, Xmx'e eşit ve AlwaysPreTouch açıkken Java tüm heap'i açılışta ayırır, yani süreç ilk dakikadan dolu görünür, gerçekte dolu olmasa bile. Önemli olan, bir çöp toplamanın hemen ardından heap'in ne kadarının hâlâ kullanımda olduğudur. Sağlıklı bir sunucu testere dişi bir grafik çizer: toplamalar arasında yükselir ve her seferinde benzer bir taban seviyeye geri düşer.

Paper'da 1.21'den beri dahili olarak gelen, Fabric, NeoForge ve Forge için mod olarak da bulunan spark profilleyici bunu doğrudan gösterir. spark health --memory JVM'in bellek kullanımını ayrıntılı raporlar, spark gc toplamaların ne sıklıkla çalıştığını ve ne kadar sürdüğünü gösterir, spark heapsummary ise heap'i hangi nesne türlerinin doldurduğunu listeler; sızıntı yapan bir eklentiyi böyle yakalarsın. Gerçek uyarı işaretleri, saatler geçtikçe sürekli yükselen bir taban seviye, birkaç saniyede bir çalışan toplamalar ya da loglarda görülen OutOfMemoryError'dır.

Sunucun için doğru RAM miktarını 7 adımda belirle

1. 1

   Zirve oyuncu sayısını tahmin et

   Toplam üyeyi değil, en yoğun saatte aynı anda çevrimiçi olan oyuncu sayısını say ve vanilla, eklentili ya da mod paketli bir sunucu çalıştıracağını netleştir.

2. 2

   Başlangıç miktarını seç

   Bu rehberdeki tabloyu ya da mod paketinin kendi önerisini kullan; birkaç hafta içinde büyümeyi planlıyorsan bir üst kademeden başla.

3. 3

   Java bellek ayarlarını yap

   Xms ve Xmx'i Aikar bayraklarıyla aynı değere ayarla; Java'nın kendi ek yükü için makine ya da konteyner sınırının 1000–1500 MB kadar altında kal.

4. 4

   Dünyayı önceden oluştur ve sınır koy

   Oyuncuların kullanacağı alanı Chunky ile oluştur, ardından keşif sırasında canlı chunk üretimi tetiklenmesin diye bir dünya sınırı belirle.

5. 5

   Mesafeleri ayarla

   Sunucu kalabalıklaşıyorsa view-distance değerini 7–8'e, simulation-distance değerini 4–6'ya çek ve değişikliğin geçerli olması için yeniden başlat.

6. 6

   Yoğun saatte ölç

   En kalabalık saatte spark health --memory ve spark gc çıktılarına bak, birkaç gün boyunca toplamalardan sonraki heap taban seviyesini izle.

7. 7

   Yalnızca veriye dayanarak yükselt

   Taban seviye yüksek kalıyorsa ya da OutOfMemoryError alıyorsan RAM ekle; bellek boştayken MSPT yüksekse yükseltmek yerine optimize et.

Sık Sorulan Sorular