Für Cobblemon Official stehen im geprüften mcfreehost-Katalog 6 GB RAM, für Optimised 4 GB und für COBBLEVERSE 8 GB. Das sind Angebotsstufen, keine nachgewiesenen Mindestwerte und keine Zusage für eine feste Spielerzahl. Entscheidend ist die Last eurer eigenen Welt: erkunden, kämpfen, fangen, Weiden betreiben oder zusätzliche Mods nutzen.

Dieser Guide hilft dir, einen Cobblemon-Speicherengpass von langen Ticks und Client-FPS zu unterscheiden. Die historische Botmessung vom 23. September 2026 ist dafür ein begrenztes Beispiel. Die Daten wurden am 7. Oktober 2026 erneut geprüft; es wurde kein neuer Lasttest durchgeführt.

Erst das Problem benennen

Was eure Runde bemerkt Was du zuerst vergleichst
Nur ein Client zeigt wenig Bilder pro Sekunde Client-Einstellungen und GPU; nicht automatisch den Server-RAM
Blöcke reagieren verspätet und mehrere Spieler ruckeln Server-Tickzeiten, Aktivitäten und gleichzeitig geladene Weltbereiche
Server beendet sich mit Java heap space Konkrete Fehlermeldung, Heapgrenze und Speicherverlauf
Ein Server stoppt ohne diese Java-Meldung Exit-/OOM-Hinweise und wirksame Containergrenze; Ursache noch offen
Problem beginnt direkt nach Packänderung Versionssatz und letzte Änderung, bevor du Ressourcen buchst

Eine hohe Prozentzahl in der RAM-Anzeige beantwortet diese Fragen nicht allein. Java-Heap, vom Prozess belegter Speicher und die tatsächliche Containerobergrenze sind unterschiedliche Größen. Der Java-Heap enthält nicht den gesamten Speicher der JVM.

Ressourcenanzeige einer Cobblemon-Testinstanz vom 23. September 2026; die Panelbeschriftung ist ein historisches Beispiel
Ressourcenanzeige einer Cobblemon-Testinstanz vom 23. September 2026; die Panelbeschriftung ist ein historisches Beispiel

Die Oracle-Dokumentation zu Speicherfehlern trennt Java heap space, andere Speicherbereiche und mögliche Lecks. Eine einzelne OutOfMemory-Meldung beweist noch kein Speicherleck. Eine lediglich steigende Kurve beweist auch nicht, dass Java grundsätzlich keinen Speicher zurückgeben kann.

Was der Cobblemon-Botlauf tatsächlich maß

Der Aufbau war Cobblemon Official 1.8.1, Minecraft 1.21.1 und Fabric mit einer Produktzuweisung von 6.144 MiB. Der Java-Heap war auf 6.144 MiB begrenzt. Die Ressourcen-Schnittstelle meldete eine darüberliegende Containergrenze von rund 7.373 MiB. Der Lauf ist deshalb kein Versuch unter einer harten Gesamtgrenze von 6 GiB und erst recht kein Nachweis für Official mit 4 GiB.

Die Bots liefen und erkundeten neue Gebiete. Sicht- und Simulationsweite lagen bei 10, wilde Pokémon waren eingeschaltet, Vanilla-Mobspawns ausgeschaltet. Die Werte der folgenden Tabelle wurden aus den erhaltenen Stichproben neu nachgerechnet und stimmen mit der damaligen Zusammenfassung überein.

Beobachtete Bots Ressourcen-RAM Ø / Maximum (MiB) Heap belegt Ø / Maximum (MiB) Abfrage-MSPT Ø / Maximum (ms) Höchstes abgefragtes MSPT-P95 (ms)
0 2.140 / 2.142 614 / 617 0,3 / 0,3 0,4
5 2.329 / 2.378 1.173 / 1.441 13,8 / 20,7 77,4
9–10 2.494 / 2.883 1.438 / 1.869 21,1 / 37,0 91,1

Einheiten: Der damalige Sampler rechnete Bytes durch 1.048.576 und beschriftete das Ergebnis als MB. Die richtige Einheit dieser Werte ist MiB. Die Tabelle korrigiert die Bezeichnung, ohne zusätzliche Messgenauigkeit zu erfinden. Der Ressourcenwert stammt aus memory_bytes der Server-Schnittstelle; er ist nicht der vollständige cgroup-Wert einschließlich Seitencache.

Historischer Cobblemon-Botlauf: Ressourcen-RAM, durchschnittliche Tickzeit und abgefragte P95-Tickzeiten für 0, 5 und 9 bis 10 Bots
Historischer Cobblemon-Botlauf: Ressourcen-RAM, durchschnittliche Tickzeit und abgefragte P95-Tickzeiten für 0, 5 und 9 bis 10 Bots

Der Punkt zeigt den Mittelwert der Stichproben, der graue Bereich ihr Minimum bis Maximum. Die gelbe Linie markiert 50 ms. Bei MSPT-P95 ist das die Verteilung der abgefragten P95-Werte, kein neu berechnetes P95 über alle Ticks. Die Grafik zeigt einen einzelnen historischen Botlauf und keine Spielerkapazität.

Messfenster und ausgeschlossene Stufe

Stufe Ausgewertetes Fenster (UTC) Ressourcenproben Tick-Abfragen
Leerlauf 16:27:15–16:31:15 16 4
5 Bots 16:33:15–16:41:30 33 9
9–10 Bots 16:43:50–16:52:00 27 7

Für die Botstufen wurde der Beginn nach etwa zwei Minuten Aufwärmen ausgewertet; die Fenster sind rechts offen. Die geplante 20-Bot-Stufe wurde nicht erreicht. Mehrere Bots wurden getrennt, und die beobachtete Zahl fiel von zeitweise 11–15 auf 2. Ein Mittelwert über diese gemischte Phase ist kein 20-Spieler-Ergebnis. Sie fehlt deshalb im Diagramm und in der vergleichbaren Stufentabelle.

Die Konsolenabfragen meldeten den normalen 20-TPS-Betrieb. Daraus folgt keine lückenlose Garantie flüssiger Einzelbilder oder sämtlicher Ticks: Einzelne abgefragte P95-Tickwerte lagen bereits über 50 ms. Durchschnittswerte können solche Spitzen verdecken.

Grenzen, die für deine Entscheidung zählen

  • Keine echten Spielsituationen: Die Bots fingen nicht, kämpften nicht, öffneten keine Menüs und bauten keine Farmen. Sie erzeugten vor allem Erkundungs- und Spawnlast.
  • Vanilla-Mobs waren aus: In einer normalen Survivalwelt kommt deren Aktivität hinzu.
  • Kurze Beobachtung: Die Botstufen dauerten ungefähr acht Minuten. Ein Abend mit wachsender Welt oder ein mehrtägiger Heapverlauf ist nicht geprüft.
  • Stichproben: Tickzeiten wurden etwa einmal pro Minute abgefragt; nicht jede Spitze zwischen den Abfragen ist erfasst.
  • Ein Pack und ein Aufbau: Optimised, COBBLEVERSE, NeoForge und zusätzliche Addons sind hier nicht unter vergleichbarer Last gemessen.
  • Kein RAM-Vergleich: Der Botlauf enthält keine kleinere Official-Zuweisung unter denselben Bedingungen.

Zusammenfassung, Stichprobenzahlen und Messbedingungen als JSON. Die Angaben sind historische Messdaten; der Katalog und die Laufzeit deiner eigenen Instanz können sich unterscheiden.

Was du bei Cobblemon gezielt beobachten kannst

Notiere Pack-Ausgabe, aktive Spieler, Aufenthalt in alten oder neuen Gebieten und sichtbares Problem. Vergleiche anschließend denselben Ablauf, statt einen leeren Server nach einem Neustart mit einer großen Erkundungsrunde zu vergleichen.

Cobblemon erzeugt Spawnversuche im Umfeld der Spieler. Die folgende Einordnung stammt für 1.8.1 aus der Konfiguration und den damaligen Untersuchungen. Sie erklärt mögliche Hebel, aber keine gemessene Prozentersparnis für jede Welt.

Einstellung oder Aktivität Gezielter Versuch Möglicher Preis der Änderung
pokemonPerChunk Dichte in einem gesicherten Test schrittweise senken Weniger wilde Pokémon; nach Senkung müssen verbundene Spieler neu verbinden
ticksBetweenSpawnAttempts Spawnversuche seltener planen Langsamerer Spawnaufbau; Reload allein übernimmt nicht jede gespeicherte Spawner-Einstellung
Sicht-/Simulationsweite Mit denselben Spielern eine kleinere Distanz vergleichen Weniger sichtbare beziehungsweise simulierte Welt
Viele Weiden an einem Ort Verhalten in einem weniger belasteten Gebiet vergleichen Spielaufbau oder Aufenthaltsort ändern
Gleichzeitiges Erkunden neuer Chunks Vorhandene Gebiete gegen neue Gebiete vergleichen Kein Beweis, dass ausschließlich Worldgen verantwortlich ist
Zusätzliche Mods oder Chunkloader Letzte Änderung auf einer Kopie einzeln prüfen Inhalte dürfen beim Test nicht aus der einzigen produktiven Welt verschwinden

Bei pokemonPerChunk wurde 1.8.1 gegen 1.7.3 mit gleicher Welt und einem stehenden Testspieler untersucht. Der Standard 1.0 ergab am Prüfstand ungefähr 63 statt 23 Pokémon im Umkreis von 96 Blöcken. Das ist ein lokaler Versionsvergleich, kein allgemeiner Faktor für jede Welt. Wer pokemonPerChunk mit Cobblemon 1.7 (beispielsweise 1.7.3) erhöht hatte, sollte nach einem Update seine tatsächliche Dichte erneut prüfen; siehe Spawnrate einstellen.

Verändere Speicherintervalle oder das Speichern wilder Pokémon nicht allein wegen eines hohen RAM-Balkens. Das kann die Wiederherstellung oder das Spielverhalten ändern. Die Config-Referenz beschreibt Bedeutung und Versionsbindung der Werte. Für eine vorbereitete begrenzte Welt hilft der Chunky-Guide; vorhandene Chunks beseitigen jedoch nicht die gesamte Entity- und Modlast.

Ändern, vergleichen und bei Bedarf zurückkehren

  1. Sichere Welt, Konfiguration und Cobblemon-Spielerdaten vollständig. Notiere den aktuellen Versionssatz und das beobachtete Problem.
  2. Wähle einen einzelnen begründeten Hebel. Teste datenverändernde Versuche mit einer Kopie und halte die funktionierenden Dateien bereit.
  3. Stoppe den Server vor manuellen Dateiänderungen. Bei main.json kann ein JSON-Syntaxfehler den Inhalt beim Laden mit Standardwerten überschreiben.
  4. Prüfe nach der Änderung dieselbe Aktivität, dieselben Orte und möglichst dieselbe aktive Gruppe. Kontrolliere Tickverlauf, Speicherhinweise und einen echten Beitritt.
  5. Stelle bei Nebenwirkungen den gesicherten Stand wieder her. Eine neue Softwarefassung und ihr Datenstand müssen zusammenpassen.

Falls spark für eure Kombination installiert ist, erklärt dessen Befehlsreferenz TPS-, GC- und Speicherdiagnosen. Ein Paper-Tutorial ist nicht automatisch ein Fabric-Befehl. Im historischen Botlauf wurde spark nicht eingesetzt; dessen Funktionen sind deshalb kein Teil dieser Messung.

Ältere 1.7.3-Werte getrennt einordnen

Die vorhandene historische Messzusammenfassung vom August 2026 betrifft Cobblemon Official 1.7.3, einen anderen Weltaufbau und eine andere Speichermessung. Sie enthält drei aggregierte Profilläufe mit 4.096 MiB Zuweisung sowie einen separaten Lauf mit 6.144 MiB. Die wirksamen Containergrenzen lagen jeweils darüber. Die Originalzusammenfassung übernimmt historische MB-Bezeichnungen; für diese älteren Werte wird hier keine nachträgliche Präzision behauptet.

Ältere Kennzahl Drei Profilläufe, größter aggregierter Wert Separater 6-GB-Lauf
Speicher-P95, historische MB 2.847 2.807
Speicherspitze, historische MB 2.937 3.033
Swap, historische MB 0 0
OOM-Ereignisse 0 0

Der größte P95-Wert mehrerer Läufe ist kein gepooltes P95 aller Stichproben. TPS und MSPT fehlen in dieser August-Zusammenfassung. Vergleiche die Zahlen nicht als Geschwindigkeitsrang mit dem späteren Botlauf; Version, Welt und Messweise unterscheiden sich.

FAQ

Wie viel RAM sollte ich für Cobblemon auswählen?

Prüfe das konkrete angebotene Pack. Im am 7. Oktober geprüften Katalog stehen Official mit 6 GB, Optimised mit 4 GB und COBBLEVERSE mit 8 GB. Nutze diese Zuordnung als Einstieg und beurteile danach die tatsächliche Weltlast. Sie ersetzt keinen Lasttest deiner Gruppe.

Beweist der Botlauf, dass Official mit 4 GB reicht?

Nein. Er wurde mit 6.144 MiB Heap und rund 7.373 MiB wirksamer Containergrenze durchgeführt. Ein niedriger beobachteter Heap in diesem Aufbau beweist nicht das Verhalten einer kleineren Zuweisung.

Wie viele echte Spieler schafft ein 6-GB-Server?

Diese Daten beantworten das nicht. Es gab erkundende Bots, keine vergleichbare Runde mit Fangen, Kämpfen, Weiden und Farmen. Auch die geplante 20-Bot-Stufe war ungültig. Teste eure üblichen Aktivitäten, statt eine Tabellenzeile als Spielerlimit zu verwenden.

Hilft mehr RAM gegen jeden Cobblemon-Lag?

Nein. Zusätzlicher Speicher kann einen belegten Speicherengpass entschärfen. Langsame Ticks durch Modlogik oder Weltaktivität werden dadurch nicht automatisch behoben. Prüfe Fehlermeldung, Heap-/Containergrenze und Tickverlauf zusammen.

Warum ist der Server nach einem Update langsamer?

Vergleiche zuerst Version und letzte Änderung. Für den geprüften Sprung von 1.7.3 auf 1.8.1 nahm die lokale Pokémon-Dichte bei gleichem Wert zu. Das ist eine mögliche Ursache, keine Diagnose für jedes spätere Update oder jede eigene Modkombination.

Läuft Cobblemon im kostenlosen Tarif?

Der kostenlose mcfreehost-Tarif hat 2 GB und bietet diesen Cobblemon-Packweg nicht. Der Einstiegsartikel für Cobblemon erklärt die bezahlten Packangebote und den ersten passenden Java-Beitritt.

Quellen und Prüfstand

Nachweisprüfung: 7. Oktober 2026. Die erneute Auswertung vorhandener Daten ist kein neuer Test. Dieser Artikel nennt weder ein gemessenes RAM-Minimum noch ein garantiertes Spielerlimit.