Windows’ta Minecraft sunucusuna RAM vermek tek bir satırlık iştir: sunucu klasöründeki start.bat dosyasında -Xms ve -Xmx bayraklarını yazarsınız, sunucuyu yeniden başlatırsınız, biter. Panelde bir kaydırıcı, server.properties içinde bir ayar aramayın; RAM tahsisi Minecraft’ın değil Java’nın işidir.
Zor olan kısım sayıyı seçmek. Çok az verirseniz sunucu bellek hatasıyla düşer, çok fazla verirseniz Windows nefes alamaz ve makine takılır. Bu sayfa doğru değeri paketinize göre seçmeyi, dosyaya yazmayı, Görev Yöneticisi ile doğrulamayı ve “RAM artırdım ama hiçbir şey değişmedi” durumunu anlatıyor. Baştan sona Windows üzerinden ilerliyoruz.
-Xms ve -Xmx Tam Olarak Ne Yapar?#
Java uygulamaları nesnelerini heap denen bir bellek bölgesinde tutar. Minecraft sunucusunda yüklü chunk’lar, entity’ler, oyuncu envanterleri ve eklenti verileri hep oradadır.
-Xms- JVM açılırken işletim sisteminden isteyeceği başlangıç heap boyutu. “Initial memory size” yani ilk tahsis.
-Xmx- Heap’in büyüyebileceği tavan. Bu sınıra dayanıp da yer açamazsa sunucu
OutOfMemoryErrorile çöker. - Birim harfleri
Ggigabayt,Mmegabayt.-Xms6Gile-Xms6144Maynı şeydir.- Yazım kuralı
- Bayrak, sayı ve birim bitişik yazılır.
-Xmx6 GBveya-Xmx 6GyazımıInvalid maximum heap sizehatası verir.
Önemli bir ayrım var: -Xmx java.exe sürecinin toplam bellek kullanımını sınırlamaz, yalnızca heap’i sınırlar. Süreç ayrıca metaspace, JIT kod önbelleği, iş parçacığı yığınları ve ağ katmanının kullandığı doğrudan bellek arabelleklerini de tutar. Bu yüzden 6 GB heap veren bir sunucu Görev Yöneticisi’nde 7 GB civarı görünebilir. Şaşırmayın, bu normaldir.
Neden Xms ve Xmx Eşit Verilir?#
Masaüstü Java uygulamalarında küçük bir -Xms, büyük bir -Xmx vermek mantıklıdır: uygulama az bellekle açılır, gerektikçe büyür. Minecraft sunucusunda bu davranış tam tersine çalışır.
Heap her büyütüldüğünde ya da küçültüldüğünde JVM dünyayı durdurur, belleği yeniden düzenler ve sonra devam eder. Bu duraklamalar milisaniyelerle ölçülür ama tick döngüsünün ortasına denk geldiğinde oyuncu ekranda ani bir donma görür. Sunucu üstelik bunu tekrar tekrar yapar, çünkü chunk yükleme ve boşaltma heap kullanımını sürekli dalgalandırır.
Eşit verdiğinizde heap ilk anda tam boyutta ayrılır ve bir daha yeniden boyutlandırılmaz. Aikar’s Flags setindeki -XX:+AlwaysPreTouch bayrağı bir adım daha ileri gider ve o belleğin tamamına açılışta dokunur; böylece ilk çalışma dakikalarındaki sayfa hatası birikimi de ortadan kalkar. Açılış birkaç saniye uzar, karşılığında sunucu ilk andan itibaren düzgün çalışır.
İşletim Sistemine Pay Bırakma#
En sık yapılan hata, makinenin toplam RAM’ini olduğu gibi Java’ya vermek. 8 GB’lık bir makinede -Xmx8G yazmak iki şeyden birini yapar: ya JVM hiç açılmaz ve Could not reserve enough space for object heap der, ya da açılır ve Windows sayfa dosyasına düşer. İkinci durum daha kötüdür çünkü sunucu çalışıyor gibi görünür, sadece korkunç yavaştır.
Pay bırakılacak kalemler şunlar:
- Windows çekirdeği ve arka plan hizmetleri: yaklaşık 1–1,5 GB
- java.exe’nin heap dışı belleği (metaspace, iş parçacıkları, doğrudan arabellekler): 0,5–1,5 GB
- Uzak Masaüstü oturumu, Dosya Gezgini, açık düzenleyiciler
- Disk önbelleği — chunk okuma/yazma hızını doğrudan etkiler
Pratikte 2 GB’lık bir pay her senaryoda yeterlidir. Aynı makinede birden fazla sunucu çalıştırıyorsanız payı toplam üzerinden değil, tüm heap değerlerinin toplamı üzerinden hesaplayın.
Pakete Göre Doğru Değerler#
| Sunucu paketi | start.bat değeri | Uygun senaryo | Disk |
|---|---|---|---|
| 8 GB | -Xms6G -Xmx6G | 2–10 oyuncu, vanilla veya hafif eklentili Paper | 50 GB NVMe |
| 12 GB | -Xms10G -Xmx10G | 10–30 oyuncu, eklentili Paper sunucu | 50 GB NVMe |
| 16 GB | -Xms14G -Xmx14G | 30–60 oyuncu, minigame veya çok dünyalı; Forge/Fabric modpack | 100 GB NVMe |
| 32 GB | -Xms28G -Xmx28G | 60+ oyuncu, büyük modpack veya proxy’li sunucu ağı | 100 GB+ NVMe |
Tabloya bakarken oyuncu sayısının tek ölçüt olmadığını unutmayın. Eklenti sayısı, dünya boyutu, view distance ayarı ve özellikle modpack’in ağırlığı heap tüketimini oyuncu sayısından çok daha fazla etkiler. Daha ayrıntılı bir planlama için Minecraft sunucusu kaç GB RAM ister sayfasındaki tabloya, modlu kurulumlar için modlu sunucu RAM rehberine bakın.
Aynı makinede birden fazla sunucu#
Tek bir Windows makinesinde iki ya da üç sunucu çalıştırmak yaygın bir düzendir: bir survival, bir skyblock, bir de test sunucusu. Burada hesap toplam üzerinden yapılır, çünkü her sunucu kendi java.exe sürecini açar ve kendi heap’ini ayrı ayrı ayırır.
| Sunucu | Klasör | Port | Heap |
|---|---|---|---|
| Survival | C:\minecraft\survival | 25565/TCP | -Xms14G -Xmx14G |
| Skyblock | C:\minecraft\skyblock | 25566/TCP | -Xms10G -Xmx10G |
| Test | C:\minecraft\test | 25567/TCP | -Xms6G -Xmx6G |
Yukarıdaki üç sunucu 30 GB heap ister. Windows’a ve heap dışı bellek kullanımına pay bıraktığınızda bu düzen için en az 40 GB’lık bir makine gerekir; 32 GB’lık bir makinede bu üçü birlikte ayakta kalmaz. Toplamı hesaplarken her java.exe sürecinin heap dışında da birkaç yüz megabayt tuttuğunu ekleyin.
start.bat’ta RAM Ayarını Yazma#
Sunucu klasöründeki start.bat dosyasını Not Defteri ile açın. En sade hâli şudur:
@echo off
title Minecraft Server - Paper 26.2
cd /d C:\minecraft\server
java -Xms6G -Xmx6G -jar paper.jar nogui
pauseDeğerleri bir değişkene alırsanız ileride tek yerden değiştirirsiniz. Java’yı da tam yoluyla çağırmak, makinede birden fazla sürüm varsa yanlış Java ile açılma riskini bitirir:
@echo off
title Minecraft Server - Paper 26.2
cd /d C:\minecraft\server
set JAVA="C:\Program Files\Eclipse Adoptium\jdk-25.0.4.7-hotspot\bin\java.exe"
set MEM=-Xms14G -Xmx14G
set FLAGS=-XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=40 -XX:G1MaxNewSizePercent=50 -XX:G1HeapRegionSize=16M -XX:G1ReservePercent=15 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=20 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1
%JAVA% %MEM% %FLAGS% -jar paper.jar nogui
pauseYukarıdaki bayrak seti 12 GB üzeri heap için uyarlanmış Aikar’s Flags sürümüdür; 8–12 GB heap kullanıyorsanız G1NewSizePercent=30, G1MaxNewSizePercent=40, G1HeapRegionSize=8M, G1ReservePercent=20 ve InitiatingHeapOccupancyPercent=15 değerlerine dönün. Dosyanın tam anlatımı start.bat oluşturma sayfasında.
Bayrak yazımında tek bir sıralama kuralı vardır: Java bayrakları -jar ifadesinden önce, sunucu parametreleri jar adından sonra gelir. Bu sırayı bozmak “Unrecognized option” hatasının en yaygın sebebidir.
-XX:+ZGenerational bayrağını yazmayın. Java 25’te ZGC’nin nesil ayrımı yapmayan modu kaldırıldığı için bu bayrak geçersizdir ve her açılışta uyarı basar. ZGC kullanacaksanız doğru yazım yalnızca -XX:+UseZGC şeklindedir ve G1 bayraklarının tamamı kaldırılmalıdır. ZGC’yi 16 GB ve üzeri heap ya da ağır modpack dışında denemeye değmez.Görev Yöneticisi ile Doğrulama#
Ayarın gerçekten uygulandığını görmek için sunucuyu çalıştırın ve Ctrl + Shift + Esc ile Görev Yöneticisi’ni açın.
-
Ayrıntılar sekmesine geçin#
Ayrıntılar sekmesinde
java.exesatırını bulun. Bellek (etkin çalışma kümesi) sütunu sürecin o an fiziksel bellekte tuttuğu miktarı gösterir.-XX:+AlwaysPreTouchkullanıyorsanız bu değer daha ilk dakikada heap boyutuna yakın olur; kullanmıyorsanız zamanla yükselir. -
Rakamı doğru okuyun#
6 GB heap verdiyseniz java.exe’nin 6,5–7,5 GB arasında görünmesi beklenen davranıştır. Aradaki fark metaspace, iş parçacığı yığınları ve ağ arabelleklerinden gelir. Değer
-Xmxile hiç ilgisi olmayan bir yerdeyse (örneğin 1,5 GB) start.bat değişikliğiniz uygulanmamış demektir. -
Performans sekmesinden makineye bakın#
Performans > Bellek ekranında Kullanımda ve Kullanılabilir değerlerini kontrol edin. Kullanılabilir bellek 1 GB’ın altına iniyorsa heap değerini bir kademe düşürün. Sayfalanmış havuz ve sayfa dosyası kullanımı sürekli artıyorsa makine belleği yetmiyor demektir.
Java tarafından kesin doğrulama isterseniz JDK ile gelen jcmd aracını kullanın. Komut İstemi’nde:
jcmd
jcmd 12345 VM.flags
jcmd 12345 GC.heap_infoİlk komut çalışan Java süreçlerini numaralarıyla listeler. Numarayı ikinci ve üçüncü komuta yazdığınızda -XX:InitialHeapSize ve -XX:MaxHeapSize değerleri bayt cinsinden, ayrıca heap’in o anki gerçek doluluğu görünür. jcmd komutu tanınmıyorsa JDK değil JRE kurulu olabilir ya da Path ayarı eksiktir; java komutu tanınmıyor sayfasına bakın.
/spark heapsummary komutu, heap’i hangi nesne türlerinin doldurduğunu listeler. Bellek sürekli doluyorsa suçlunun hangi eklenti veya entity türü olduğunu bu çıktı gösterir. Ölçmeden RAM artırmak, sızıntıyı sadece birkaç saat erteler.-
spark profilerÜcretsizİndir
Bağlantı resmî spark indirme sayfasına gider. Rapor okuma yöntemi spark ve timings analizi sayfasında anlatılıyor.
“RAM’i Artırdım Ama TPS Düzelmedi”#
Destek taleplerinde en sık gördüğümüz senaryo bu. Sunucu takılıyor, sahibi heap’i 6 GB’dan 14 GB’a çıkarıyor ve hiçbir şey değişmiyor. Sebep basit: RAM ile TPS farklı şeylerdir.
TPS, sunucunun saniyede kaç tick işleyebildiğidir ve bu işi tek bir çekirdek yapar. Heap zaten yeterliyse fazladan bellek o çekirdeği hızlandırmaz. Bellek yetersizliğinin TPS’i düşürdüğü tek durum, çöp toplayıcının sürekli tam GC yapmak zorunda kalmasıdır; bunu da konsolda uzun duraklamalar ve Can’t keep up! uyarılarıyla fark edersiniz.
Sorunun gerçekten çöp toplayıcıdan gelip gelmediğini ölçmek isterseniz sunucuyu geçici olarak GC günlüğüyle başlatın. Java 25’te doğru yazım şudur:
%JAVA% %MEM% -Xlog:gc*:file=C:\minecraft\server\logs\gc.log:time,uptime:filecount=5,filesize=10M -jar paper.jar noguiOluşan gc.log dosyasında Pause Full satırlarını arayın. Bunlar saatte birkaç kez görünüyor ve süreleri saniyelerle ölçülüyorsa heap gerçekten dardır; bir kademe yukarı çıkın. Yalnızca Pause Young satırları varsa ve süreler 200 ms altındaysa bellek tarafı sağlıklıdır, sorunu başka yerde aramanız gerekir. Ölçüm bitince bu bayrağı kaldırın; sürekli GC günlüğü tutmak diske gereksiz yazma yükü bindirir.
| Belirti | Gerçek sebep | Doğru müdahale |
|---|---|---|
| Sunucu düzenli aralıklarla 2–3 saniye donuyor | Tam GC duraklaması, heap gerçekten yetersiz | Heap’i bir kademe artırın, Aikar’s Flags ekleyin |
| TPS sürekli 15–18 arası, donma yok | Tick yükü fazla; entity, hopper veya redstone | TPS düşüklüğü çözümlerine bakın, RAM’e dokunmayın |
| Oyuncu sayısı arttıkça TPS düşüyor | View distance ve simulation distance yüksek | Mesafe ayarlarını düşürün |
| Sunucu birkaç saat sonra çöküyor | Bellek sızıntısı yapan bir eklenti | spark heapsummary alın, eklentiyi tespit edip güncelleyin |
OutOfMemoryError: Java heap space |
Heap tavana dayandı | Out of Memory çözümünü uygulayın |
| Her şey yavaş, disk sürekli meşgul | Makine sayfa dosyasına düşmüş, heap çok büyük | Heap’i düşürüp işletim sistemine pay bırakın |
Kısaca: heap değeri bir tavandır, bir hızlandırıcı değil. Tick, MSPT ve TPS kavramlarının ne anlama geldiğini tick ve TPS sayfasında, Windows tarafındaki diğer performans ayarlarını da Windows Server optimizasyonu sayfasında bulacaksınız.
Donanım Tarafı: RAM Tek Başına Yetmez#
Doğru heap değeri sunucunun çökmemesini sağlar; akıcı olmasını sağlayan şey işlemcidir. Minecraft’ın ana tick döngüsü tek çekirdekte koştuğu için çekirdek sayısı değil saat hızı belirleyicidir. Bu yüzden düşük frekanslı çok çekirdekli sunucu işlemcileri, paylaşımlı vCPU’lar ve eski nesil Xeon sistemleri Minecraft için kötü tercihlerdir.
Disk tarafında da benzer bir durum var: chunk okuma ve yazma sürekli küçük I/O işlemleri üretir, gecikme doğrudan TPS’e yansır. NVMe SSD dışında birşey önermiyoruz.
Batihost’ta Minecraft sunucuları AMD Ryzen 9 7900X / 7950X sınıfı yüksek frekanslı işlemciler ve NVMe SSD üzerinde çalışır; en düşük paket 8 GB RAM ile başlar ve 156 TL’den başlayan fiyatlarla sunulur. Hazır yapılandırılmış bir ortam için Minecraft sunucu paketlerine, modpack çalıştıracaksanız modlu sunucu paketlerine bakabilirsiniz.
Özetle#
RAM tahsisi start.bat dosyasındaki tek bir satırla yapılır ve kuralı sabittir: -Xms ile -Xmx daima eşit, işletim sistemine daima 2 GB pay. 8 GB pakette -Xms6G -Xmx6G, 12 GB’da 10G, 16 GB’da 14G, 32 GB’da 28G yazın.
Değişikliği yaptıktan sonra sunucuyu yeniden başlatın ve Görev Yöneticisi’nin Ayrıntılar sekmesinden java.exe’nin bellek kullanımını kontrol edin; heap boyutunun biraz üstünde bir rakam görmeniz beklenen davranıştır. Kesin doğrulama için jcmd <pid> VM.flags komutunu kullanın.
Son olarak şunu aklınızda tutun: RAM artırmak TPS problemini çözmez. Sunucu takılıyorsa önce ölçün, sonra müdahale edin. Bayrakların tek tek ne yaptığını RAM ayarları, ZGC ve JVM flag’leri sayfasında bulabilir, çözemediğiniz bir durumda spark raporunuzla birlikte destek talebi açabilirsiniz.