Minecraft “Out of Memory” (OutOfMemoryError) Hatası Çözümü

Minecraft sunucusunda Out of Memory hatası, JVM’in -Xmx ile belirlenen bellek üst sınırına ulaşıp yeni nesne oluşturamamasıdır. Hata düştüğü anda sunucu ya tamamen çöker ya da saniyeler süren garbage collection döngülerine girip pratikte kullanılamaz hâle gelir. İlk refleks genelde “RAM artıralım” olur; oysa vakaların önemli bir kısmında sorun bellek miktarında değil, belleği bırakmayan bir eklenti ya da modda saklıdır.

Bu sayfada hatanın birebir metnini, yetersiz bellek ile bellek sızıntısını ayırt etme yöntemini, doğru heap değerlerini ve sızıntı avlama adımlarını bulacaksınız. Değerler Minecraft 26.2 ve Java 25 LTS temel alınarak verildi.

Hatanın Birebir Metni#

[04:18:33] [Server thread/ERROR]: Encountered an unexpected exception
java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Arrays.copyOf(Arrays.java:3537)
	at net.minecraft.world.level.chunk.LevelChunkSection.<init>(LevelChunkSection.java:41)

java.lang.OutOfMemoryError: Metaspace

java.lang.OutOfMemoryError: GC overhead limit exceeded

io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory

Bazı durumlarda sunucu hiç hata basmadan aniden kaybolur. Bu, işletim sisteminin OOM killer mekanizmasının Java sürecini sonlandırdığını gösterir:

sudo dmesg | grep -i "killed process"
# Out of memory: Killed process 3241 (java) total-vm:18234112kB

Neden Olur? Belirti, Neden ve Çözüm Tablosu#

Birinci Ayrım: Yetersiz Bellek mi, Sızıntı mı?#

Bu ayrımı bellek kullanım eğrisine bakarak yaparsınız. Konsolda spark kuruluysa:

/spark health
/spark heapsummary

İki tipik desen vardır:

Grafik sürekli tırmanıyor ve GC sonrası taban seviye her seferinde yükseliyorsa sızıntı vardır ve RAM artırmak çözüm değildir.

Doğru Heap Değerleri#

Tam başlatma komutu 12 GB’lık bir paket için şöyle görünür:

java -Xms10G -Xmx10G \
 -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 \
 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch \
 -XX:G1NewSizePercent=30 -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M \
 -XX:G1ReservePercent=20 -XX:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 \
 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 \
 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 \
 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 \
 -XX:MaxDirectMemorySize=2G \
 -jar paper.jar nogui

Windows tarafında aynı komut start.bat içine yazılır:

@echo off
java -Xms10G -Xmx10G -XX:+UseG1GC -XX:+ParallelRefProcEnabled ^
 -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions ^
 -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:MaxDirectMemorySize=2G ^
 -jar paper.jar nogui
pause

Betik oluşturma ayrıntıları start.bat dosyası oluşturma sayfasında, tüm JVM bayraklarının anlamı RAM ayarları ve JVM flag rehberinde var.

Çöp Toplayıcı Seçimi: G1GC mi ZGC mi?#

Bu konuda dolaşan yanlış bilgiler nedeniyle netleştirelim. 26.1 ile duyurulan “G1GC yerine ZGC” değişikliği istemci tarafı bir düzenlemedir ve Minecraft Launcher’ın JVM varsayılanını değiştirir. Sunucu jar’ının launcher’ı yoktur; çöp toplayıcıyı tamamen sizin verdiğiniz bayraklar belirler. Java 25’te G1 hâlâ JVM’in genel varsayılanıdır, dolayısıyla bayraksız çalıştırılan bir 26.x sunucusu ZGC değil G1GC kullanır.

8–12 GB heap

G1GC + Aikar’s Flags. Bu doküman geri çekilmemiştir ve 26.x sunucularında hâlâ geçerlidir.

16 GB ve üzeri heap

ZGC değerlendirilebilir. Doğru kullanım yalnızca -XX:+UseZGC biçimindedir.

Ağır modlu sunucu

Büyük heap ile ZGC duraklama sürelerini kısaltabilir; ancak toplam verim biraz düşer.

Bellek Sızıntısını Bulma#

1. Heap dump alın#

   JVM’i hata anında otomatik dump alacak biçimde başlatın:

   -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/minecraft/dumps

   Sunucu çalışırken elle dump almak için:

   jcmd $(pgrep -f paper.jar) GC.heap_dump /opt/minecraft/dumps/heap.hprof

   jcmd (Get-Process java).Id GC.heap_dump C:\minecraft\dumps\heap.hprof

2. spark ile hızlı özet çıkarın#

   Tam bir dump analizi yapmadan önce spark’ın özeti çoğu zaman yeterlidir:

   /spark heapsummary
   /spark health --memory

   Çıktıda en çok yer kaplayan sınıflar listelenir. Bir eklentinin paket adına ait sınıflar listenin üstündeyse suçlu bulunmuş demektir.

3. Şüpheli eklentileri eleyin#

   Bellek sızıntısı en sık şu tiplerde görülür: sürekli veri toplayan log/istatistik eklentileri, harita render eklentileri, çok sayıda entity yöneten eklentiler ve düzgün kapanmayan veritabanı bağlantıları. Eklentileri yarıya bölerek deneyin.

4. /reload komutunu bırakın#

   /reload, eklentileri yeniden yükler ama eski sınıf yükleyicileri her zaman serbest bırakılmaz. Bu doğrudan Metaspace dolmasına ve sızıntıya yol açar. Yapılandırma değiştirdiğinizde sunucuyu tamamen yeniden başlatın.

5. Entity ve chunk yığılmalarını temizleyin#

   Binlerce item entity, aşırı büyük hayvan çiftlikleri ve sürekli yüklü tutulan chunk’lar heap’i doldurur. Paper tarafında sınırlar:

   # config/paper-world-defaults.yml
   entities:
     spawning:
       despawn-ranges:
         monster: { hard: 96, soft: 32 }
       per-player-mob-spawns: true
   chunks:
     max-auto-save-chunks-per-tick: 8
     prevent-moving-into-unloaded-chunks: true

   Ayrıntılı optimizasyon için paper.yml optimizasyon rehberine bakın.

Modlu Sunucularda Durum#

Forge ve Fabric modpackleri vanilla sunucudan kat kat fazla bellek tüketir. Her mod kendi kayıt tablolarını, blok ve eşya tanımlarını, tarif listelerini belleğe yükler. Bu yüzden modlu sunucularda alt sınır 16 GB’dır; 200 modun üzerindeki paketlerde 24–32 GB gerekir.

FerriteCore, blok durumu ve NBT verilerini daha verimli saklayarak modlu sunucularda kayda değer bellek tasarrufu sağlar. Modpack kurulum ve seçim önerileri modpack rehberinde ve modlu sunucu paketleri modlu sunucu sayfasında yer alıyor.

Bellek Kullanımını İzlemek#

Sorunu çözdükten sonra tekrar etmediğinden emin olmak için izleme kurun. Basit bir kontrol:

jcmd $(pgrep -f paper.jar) GC.heap_info
free -h
top -b -n 1 -p $(pgrep -f paper.jar)

Get-Process java | Select-Object Id,@{n='RAM_MB';e={[math]::Round($_.WorkingSet64/1MB)}}
Get-Counter '\Memory\Available MBytes'

Uzun vadeli izleme için Prometheus, Grafana ya da panelin kendi grafiklerini kullanabilirsiniz. Yöntemler sunucu izleme rehberinde anlatıldı.

Çökme Sonrası Yapılacaklar#

1. Dünya bütünlüğünü kontrol edin#

   OOM sırasında yazılmakta olan bölge dosyaları yarım kalmış olabilir. Sunucuyu açtıktan sonra konsolda Region file … is corrupted uyarısı arayın.

2. Crash report ve heap dump saklayın#

   crash-reports/ klasöründeki dosyayı ve varsa .hprof dump’ı silmeyin; nedeni bulmanın en somut kanıtlarıdır. Okuma yöntemi crash report rehberinde anlatıldı.

3. Yedekten geri dönmeyi değerlendirin#

   Dünyada bozulma varsa son sağlam yedeğe dönmek, kırık chunk’larla devam etmekten daha güvenlidir. Otomatik yedek kurulumu için yedekleme rehberine bakın.

İlgili Hata Sayfaları#

• Can’t keep up uyarısı — GC duraklamaları tick’i geciktiriyorsa.
• Crash report okuma — çökme kaydını çözümlemek için.
• io.netty hataları — OutOfDirectMemoryError için.
• Tüm Minecraft sunucu hataları ve çözümleri — pillar rehber.

Özetle#

OutOfMemoryError, heap sınırının dolduğunu söyler ama nedeni söylemez. İlk iş bellek eğrisine bakıp yetersiz heap ile sızıntıyı ayırmaktır: dalgalanan ama GC sonrası düşen grafik yetersizliği, sürekli tırmanan grafik sızıntıyı gösterir. Heap değerlerini paketinize göre verin, Xms ile Xmx’i her zaman eşitleyin ve sistem tarafına pay bırakın. 8–12 GB heap aralığında G1GC ve Aikar’s Flags kullanın; 16 GB üzerinde ZGC değerlendirilebilir, ama yalnızca -XX:+UseZGC biçiminde. Sızıntı şüphesinde heap dump alıp spark ile inceleyin ve /reload kullanmayı tamamen bırakın.