2026: Wie verteilen Sie CPU und Arbeitsspeicher auf mehrere Pterodactyl-Spieleserver?

Geeignet: Weisen Sie jedem Pterodactyl-Spieleserver zunächst anhand seiner gemessenen Spitzenlast anpassbare CPU-, Arbeitsspeicher- und Datenträgergrenzen zu; lassen Sie zusätzlich Reserve für das Betriebssystem und gleichzeitige Lastspitzen.
Nicht geeignet: Teilen Sie die gesamte Maschinenleistung vorab gleichmäßig auf Instanzen auf oder behandeln Sie ein Container-Limit als Garantie für flüssiges Gameplay.

Dieser Leitfaden ist für Sie gedacht, wenn Sie mehrere Spieleserver mit Pterodactyl verwalten und verhindern möchten, dass eine Instanz andere ausbremst.
Er hilft auch, wenn Sie Server von mehreren VPS-Instanzen auf eine eigene Maschine konsolidieren oder für ein kleines Studio belastbare Grenzwerte und Messverfahren benötigen.

Zuletzt aktualisiert am 25.10.2026. Versions- und Funktionsangaben wurden anhand der Pterodactyl-Dokumentation und der Dokumentation zu Nodes und Containern geprüft.

Ressourcengrenzen statt pauschaler Serverzahlen

Ein Pterodactyl-Node kann mehrere Server verwalten. Daraus folgt jedoch keine feste Zahl, wie viele Spieleserver eine Maschine verkraftet: Die Containergrenzen steuern Ressourcen, aber Spielversion, Plugins, Spielverhalten, Hintergrunddienste und gleichzeitige Spitzen unterscheiden sich je Instanz. Die offizielle Dokumentation beschreibt Nodes, Serverinstanzen und Begrenzungen für CPU, Arbeitsspeicher und Datenträger, nennt aber keine universelle Zuteilung für alle Spiele. Die Erklärung des Pterodactyl-Ressourcenmodells ist deshalb eine technische Grundlage, kein Beleg für eine bestimmte Kapazität.

Auch die Panel-Version gehört zur Betriebsplanung: Laut offizieller Dokumentation befindet sich Pterodactyl 2.0 in einer offenen Beta, während 1.x als stabile Linie geführt wird. Prüfen Sie die Dokumentation für genau die Version, die auf Ihrem Node läuft, bevor Sie Einstellungen oder API-Felder übernehmen. Der Versionsstatus kann sich ändern; übernehmen Sie daher keine Anleitung ungeprüft aus einem anderen Release. Die aktuelle Projekt- und Versionsdokumentation ist hierfür die maßgebliche Referenz.

Starten Sie mit einer Baseline pro Instanz. Erfassen Sie im Leerlauf, im normalen Betrieb und bei einer repräsentativen Spitzenlast:

• CPU-Auslastung und auffällige Schwankungen;
• belegten Arbeitsspeicher sowie den Abstand zum Container-Limit;
• Speicherbedarf von Welt, Spielständen, Logs und temporären Dateien;
• Datenträgeraktivität und Reaktionszeiten während gemeinsamer Schreib- oder Ladephasen;
• Netzwerkdurchsatz in den Situationen, in denen tatsächlich viele Spieler verbunden sind.

Dokumentieren Sie neben Messwerten auch die Bedingungen: Spielversion, Plugins oder Mods, Startparameter, verwendete Welt und Art des Tests. Ohne diesen Kontext ist ein Vergleich vor und nach einer Änderung kaum aussagekräftig. Eine Messung in einer ruhigen Welt beantwortet nicht, wie sich derselbe Server bei hoher Aktivität oder beim Speichern verhält.

CPU-Limits nach Lastprofil statt nach Instanzzahl

Ein CPU-Limit ist eine Begrenzung des Containers, keine Zuweisung exklusiver Prozessorkerne und keine Zusage, dass ein Spiel bei hoher Last flüssig läuft. Die von Pterodactyl angebotenen Ressourcenfelder sollten Sie mit der Dokumentation der verwendeten Panel-Version abgleichen; die API-Referenz zu Server-Ressourcen beschreibt die entsprechenden Felder. Welche Einstellung für Ihr Spiel angemessen ist, muss sich aus dessen beobachtetem Verhalten ergeben.

Ein Server, der empfindlich auf die Leistung einzelner Threads reagiert, kann trotz geringer Gesamt-CPU-Auslastung stocken: Ein einzelner stark belasteter Thread lässt sich im Durchschnitt über die gesamte Maschine leicht übersehen. Andere Anwendungen können Arbeit auf mehrere Threads verteilen. Wenn Sie beiden Servertypen einfach gleiche Grenzen setzen, riskieren Sie entweder, den empfindlichen Server zu knapp zu begrenzen oder weniger parallelisierbare Dienste unnötig großzügig auszustatten.

Achten Sie beim Prüfen auf mehrere Signale statt auf einen einzelnen Prozentwert:

• Meldet das Spiel selbst wiederholte Verzögerungen oder auffällige Ticks?
• Steigt die CPU-Auslastung der betroffenen Instanz zeitgleich mit den Meldungen?
• Zeigen andere Container zur selben Zeit erhöhte Last?
• Tritt der Effekt nur bei einem bestimmten Spielereignis, Speicherzugriff oder Plugin auf?

Ermitteln Sie zuerst, ob die Ursache innerhalb einer Instanz oder durch Konkurrenz auf dem Host liegt. Ändern Sie danach eine CPU-Grenze, wiederholen Sie dasselbe Szenario und vergleichen Sie Messwerte und Logs. Wenn Sie mehrere Limits gleichzeitig verschieben, wird es schwieriger festzustellen, welche Änderung geholfen oder einen anderen Server beeinträchtigt hat.

Für die laufende Beobachtung kann Docker die Container-Auslastung ausgeben. Das folgende Beispiel zeigt die Felder, nicht die Messwerte eines bestimmten Servers:

docker stats --no-stream \
  --format 'table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.BlockIO}}'

NAME       CPU %     MEM USAGE / LIMIT     BLOCK I/O
<Container> <Messwert> <belegt / Grenze>    <Lesen / Schreiben>

Die Docker-Referenz zu docker stats erläutert die verfügbaren Statistiken. Sie ersetzt keine Spiel-Logs: Container-Metriken zeigen Ressourcenverbrauch, aber nicht allein, ob eine wahrnehmbare Verzögerung aus einem überlasteten Spielthread, einem Plugin oder einem anderen Engpass entsteht.

Arbeitsspeichergrenzen mit Reserve planen

Verteilen Sie den gesamten physischen Arbeitsspeicher nicht auf die Spielcontainer. Das Betriebssystem, Panel- und Node-Dienste sowie weitere Prozesse brauchen ebenfalls Ressourcen. Darüber hinaus können mehrere Instanzen gleichzeitig ihre Spitzen erreichen. Eine Zuteilung, die nur dann aufgeht, wenn alle Server unter ihrem Durchschnitt bleiben, ist keine belastbare Planung.

Wählen Sie die Obergrenze pro Instanz anhand ihrer gemessenen Kurve und prüfen Sie, ob Startparameter die tatsächliche Nutzung beeinflussen. Ein gesetztes Limit ist weder ein sinnvoller Startwert noch ein Hinweis darauf, dass die Anwendung diese Menge benötigt. Prüfen Sie außerdem, wie Ihr Container- und System-Setup mit Speicherbegrenzungen und Swap umgeht. Die Docker-Dokumentation zu Speichergrenzen beschreibt die Wirkung von Container-Limits; die Linux-Dokumentation zu cgroup v2 erläutert die zugrunde liegenden Steuermechanismen.

Wenn Sie die Speicher- und Datenträgerplanung für den Host zusätzlich prüfen möchten, ordnen Sie Ihre Messwerte den Entscheidungspunkten für Arbeitsspeicher und Datenträger zu. Diese Betrachtung ersetzt keine Messung pro Spielinstanz, hilft aber, bei einer Neuplanung auch Speicherbedarf und Ablage der Weltdaten einzubeziehen.

Behandeln Sie diese Beobachtungen als Anlass zur Diagnose:

• Ein Server bleibt über längere Zeit nahe seiner Speichergrenze.
• Ein Prozess wird beendet oder der Spielserver meldet Speicherprobleme.
• Swap-Aktivität fällt mit Verzögerungen oder Lastspitzen zusammen.
• Die Summe der beobachteten Spitzenwerte lässt zu wenig Platz für Systemdienste und gleichzeitige Schwankungen.

Erhöhen Sie ein Limit nicht automatisch, nur weil ein Server es erreicht. Prüfen Sie zuerst Startparameter, Erweiterungen, Logs und das konkrete Lastszenario. Wenn mehrere Instanzen gleichzeitig unter Druck stehen, kann eine größere Grenze für nur einen Container die Gesamtsituation verschärfen. Entscheiden Sie anhand der Host-Messung, ob ein einzelner Server falsch dimensioniert ist oder die Summe der Grenzen die vorhandenen Ressourcen übersteigt.

Datenträger, Ports und Netzwerk in die Planung aufnehmen

Eine Ressourcenliste, die nur CPU und Arbeitsspeicher enthält, lässt wichtige Ausfallursachen außer Acht. Spielwelten wachsen, Updates benötigen Platz, Logs können sich ansammeln, und mehrere Instanzen können gleichzeitig Dateien lesen oder schreiben. Erfassen Sie deshalb den Platzbedarf getrennt nach Spielständen, Logs, temporären Dateien und Updates. Prüfen Sie außerdem, ob Lade- oder Speicherphasen zeitlich mit Verzögerungen zusammenfallen.

Planen Sie pro Instanz eindeutige Ports und halten Sie die Zuordnung zu Spiel, Node und gegebenenfalls zusätzlicher Adresse nachvollziehbar fest. Ein Portkonflikt ist kein CPU-Problem; eine unklare Adressplanung kann jedoch dazu führen, dass eine ansonsten korrekt gestartete Instanz nicht erreichbar ist. Dokumentieren Sie Änderungen so, dass andere Administratoren die Zuordnung prüfen können.

Für die Bandbreite gibt es keine verlässliche Pauschalzahl pro Spiel oder Spielerzahl. Erfassen Sie den Durchsatz unter Ihren tatsächlichen Betriebsbedingungen und prüfen Sie dabei auch Spitzen, Updates und andere Dienste auf derselben Maschine. Ein Rechenmodell kann die Planung strukturieren:

Benötigte Netzwerkreserve ≈ gemessener Durchsatz je Verbindungsszenario × gleichzeitig aktive Verbindungen × eigener Sicherheitsfaktor

Der Sicherheitsfaktor ist hier eine Planungsentscheidung, keine allgemeine Leistungsangabe. Verifizieren Sie das Ergebnis durch Messung; die Formel sagt nicht voraus, wie viele Spieler ein Server tragen kann.

Vergleich: feste Zuteilung oder messwertgestützte Grenzen?

Die Tabelle ist ein Auswahlrahmen, keine Konfigurationsempfehlung mit festen Zahlen. In der Praxis beginnen Sie mit Einzelmessungen, prüfen danach die Kombination und passen nur die nachweislich betroffenen Grenzen an.

Schritt für Schritt: vom Einzeltest zur Ressourcenmatrix

Gehen Sie für jede Instanz nach demselben Verfahren vor. Halten Sie Ergebnisse in einer Tabelle oder einem Betriebsprotokoll fest; die Felder lassen sich ohne vorgegebene Zuteilungswerte führen:

Instanz | Spielversion und Testszene | CPU-Spitze | Arbeitsspeicher-Spitze | Datenträgerbelegung | Ports | Beobachtung | nächster Prüftermin

1. Node und Version erfassen. Notieren Sie die Pterodactyl-Version, den Node, die Container-Zuordnung und die aktuellen Ressourcenlimits. Übernehmen Sie keine Versionsannahmen aus einer Anleitung für einen anderen Installationsstand.
2. Ausgangszustand messen. Erfassen Sie Leerlauf und normalen Betrieb. Notieren Sie zugleich Spielversion, Startparameter, Erweiterungen und den Zustand der Welt, damit spätere Tests vergleichbar bleiben.
3. Repräsentative Spitzenlast auslösen. Verwenden Sie ein Szenario, das Ihre tatsächliche Nutzung abbildet. Behaupten Sie keine allgemeine Spieler-Kapazität aus einem Test, der nur Ihre konkrete Konfiguration betrifft.
4. Instanzen einzeln beobachten. Prüfen Sie CPU, Arbeitsspeicher, Block-I/O, Logs und Datenträgerwachstum. Halten Sie fest, wann eine Auffälligkeit auftritt und ob sie reproduzierbar ist.
5. Server gemeinsam starten. Führen Sie danach dieselben oder vergleichbare Szenarien mit den parallel betriebenen Instanzen aus. Achten Sie auf zeitgleich steigende Werte und auf Auswirkungen auf zuvor unauffällige Server.
6. Nur die belegte Grenze ändern. Passen Sie CPU- oder Speicherlimit beziehungsweise Startparameter an, wenn Messwerte und Logs die Diagnose stützen. Ändern Sie möglichst nicht mehrere unabhängige Faktoren zugleich.
7. Vorher und nachher vergleichen. Wiederholen Sie den Test und notieren Sie den Unterschied in derselben Matrix. Setzen Sie ein Datum für die nächste Prüfung, insbesondere nach Änderungen an Spielversion, Plugins oder Welt.

Die Matrix verhindert, dass eine Momentaufnahme als dauerhafte Wahrheit behandelt wird. Ein Update, eine neue Erweiterung oder ein verändertes Nutzerverhalten kann das Lastprofil verändern; wiederholen Sie daher die Prüfung, sobald sich die Betriebsbedingungen erkennbar ändern.

Engpass lokalisieren, bevor Sie Instanzen verschieben

Ordnen Sie Probleme zunächst einer von drei Ebenen zu. Ist nur ein Spielserver auffällig, während die übrigen Container und das Host-System unauffällig bleiben, prüfen Sie dessen Startparameter, Erweiterungen und Spiel-Logs. Ändern Sie eine Grenze erst, wenn die Messung dafür spricht. Ein Server kann auch durch seine eigene Konfiguration oder einen einzelnen belastenden Vorgang ausgebremst werden.

Steigen die Werte mehrerer Container gleichzeitig, vergleichen Sie deren Zeitverlauf und die Host-Auslastung. Das spricht eher für Konkurrenz um gemeinsam genutzte Ressourcen. Prüfen Sie dann, ob einzelne Limits unnötig großzügig gesetzt sind, ob Hintergrundarbeiten zusammenfallen oder ob Speicher- und Datenträgerzugriffe zeitgleich auftreten. Verschieben Sie nicht sofort alle Instanzen auf andere Maschinen: Erst eine Wiederholung unter vergleichbaren Bedingungen zeigt, ob der Engpass reproduzierbar ist.

Nähert sich die gesamte Maschine wiederholt ihrer verfügbaren Kapazität, planen Sie die Ressourcenverteilung neu oder prüfen Sie eine Migration. Eine einzelne kurzzeitige Spitze ist nicht automatisch ein Grund für einen Hardwarewechsel; wiederkehrende Engpässe bei dauerhaft betriebenen Instanzen sind dagegen ein nachvollziehbarer Anlass, Kapazität und Kosten erneut zu vergleichen. Bei einer Migration zählen nicht nur CPU und Arbeitsspeicher, sondern auch Datenträgerbedarf, Ports, Netzwerk, Betriebssystem und die Sicherung der Spielstände.

Für Backups gilt: Spielstände, Konfigurationen und Logs sollten nicht nur im selben Ausfallbereich wie die laufenden Instanzen liegen. Legen Sie Aufbewahrung und Wiederherstellung so fest, dass Sie ein Backup tatsächlich prüfen und zurückspielen können. Berücksichtigen Sie außerdem, welche personenbezogenen Daten in Logs oder Spielerkonten auftauchen, und begrenzen Sie Zugriff und Aufbewahrung entsprechend Ihrer Datenschutzpflichten.

Häufige Fragen zur Planung mehrerer Instanzen

Wie viele Spieleserver kann ich mit Pterodactyl auf einer Maschine betreiben?

Eine feste Zahl ist ohne Messung nicht belastbar. Ermitteln Sie die Spitzenwerte jeder Instanz und testen Sie anschließend die Server gemeinsam. Erst dann sehen Sie, ob weitere Instanzen möglich sind, ohne die Reserve für Host-Dienste und gleichzeitige Lastspitzen aufzubrauchen.

Wie setzen Sie CPU-Limits für mehrere Pterodactyl-Server?

Verteilen Sie CPU nicht einfach gleichmäßig. Beobachten Sie pro Instanz Auslastung und Logs, prüfen Sie die gemeinsame Host-Last und ändern Sie anschließend nur die Grenze, für die es einen belegbaren Engpass gibt. Ein Container-Limit ist keine Zusage exklusiver Rechenleistung.

Soll der Arbeitsspeicher fest pro Instanz vergeben werden?

Setzen Sie für jede Instanz eine begründete Obergrenze, halten Sie jedoch einen Teil der Ressourcen für Betriebssystem und weitere Dienste frei. Dauerhafte Annäherung an das Limit, beendete Prozesse oder Swap-Aktivität verlangen eine Prüfung der Anwendung und der gesamten Ressourcenplanung.

Woran erkennen Sie, ob sich Spieleserver Ressourcen miteinander streitig machen?

Vergleichen Sie Container-Statistiken und Logs über denselben Zeitraum. Treten die Probleme nur in einer Instanz auf, prüfen Sie diese zuerst intern. Steigen mehrere Werte gleichzeitig oder erscheinen Speicherengpässe zusammen mit Swap-Aktivität, testen Sie die Gesamtplanung und wiederholen Sie die Messung im gemeinsamen Betrieb.

Wenn VPS-Grenzen die gemeinsame Planung erschweren

Mehrere VPS-Instanzen können für kleine, wenig ausgelastete oder nur vorübergehend benötigte Spieleserver die sinnvollere Lösung bleiben. Bei dauerhaftem Parallelbetrieb sind jedoch gemeinsam genutzte Ressourcen, mögliche Konkurrenz durch andere Mandanten und getrennte Verwaltungs- und Abrechnungsgrenzen Faktoren, die Sie in Ihre Planung einbeziehen sollten. Für die Abwägung können Sie auch die Hinweise zu Leistungsgrenzen und Zuständigkeiten heranziehen. Eine eigene Maschine erleichtert es, mehrere Instanzen unter einer Ressourcen- und Betriebssystemplanung zu beobachten; sie beseitigt aber weder Fehlkonfigurationen noch die Notwendigkeit, Grenzen und Sicherungen selbst zu verwalten.

Wenn Ihre Messmatrix wiederkehrende Konkurrenz zwischen mehreren dauerhaft betriebenen Servern zeigt, vergleichen Sie Ihre Ist-Last mit den tatsächlich verfügbaren Optionen für einen AMD-Bare-Metal-Server von OSFP Cloud. Prüfen Sie die Produktangaben auf CPU, Arbeitsspeicher, Datenträger, Betriebssystem und Bandbreite, statt aus einer Beispielkonfiguration eine feste Spieler- oder Instanzzahl abzuleiten. Informationen zu AMD-Serveroptionen bei OSFP Cloud sollten Sie mit Ihren eigenen Messwerten abgleichen; wenn die Last dagegen nur sporadisch anfällt oder sehr gering ist, kann Ihre bestehende VPS-Lösung wirtschaftlich und betrieblich passender bleiben.

Häufige Fragen

Wie viele Spieleserver kann ich mit Pterodactyl auf einer Maschine betreiben?

Eine allgemeingültige Anzahl lässt sich nicht seriös nennen. Entscheidend sind unter anderem Spielversion, Plugins, Spieleraktivität, Speicherbedarf, Datenträgerzugriffe und die übrige Last. Ermitteln Sie für jeden Server die Spitzenwerte unter repräsentativen Bedingungen und starten Sie die Instanzen anschließend gemeinsam. Erst diese Messung zeigt, ob weitere Instanzen mit ausreichender Reserve betrieben werden können.

Wie setze ich CPU-Limits für mehrere Pterodactyl-Server?

Setzen Sie Limits nicht durch gleichmäßiges Teilen der Prozessorkapazität, sondern ausgehend von den Messwerten des jeweiligen Servers. Beobachten Sie CPU-Auslastung und Spiel- beziehungsweise Serverlogs während typischer und hoher Last. Steigen gleichzeitig die CPU-Werte anderer Instanzen, prüfen Sie Konkurrenz auf dem Host. Ändern Sie jeweils nur eine Grenze und vergleichen Sie die Messungen vor und nach der Anpassung.

Soll ich den Arbeitsspeicher fest pro Spieleserver verteilen oder gemeinsam vorhalten?

Legen Sie für jeden Container eine begründete Obergrenze fest, aber verteilen Sie nicht den gesamten physischen Arbeitsspeicher. Das Betriebssystem und weitere Dienste benötigen ebenfalls Platz; außerdem können mehrere Instanzen gleichzeitig ihre Spitzen erreichen. Wenn ein Server seinem Limit dauerhaft nahekommt oder Prozesse beendet werden, prüfen Sie dessen Startparameter und die Gesamtplanung, bevor Sie die Grenze erhöhen.

Woran erkenne ich, ob sich mehrere Spieleserver CPU oder Arbeitsspeicher streitig machen?

Vergleichen Sie Container-Messwerte mit Spiel- und Systemlogs und betrachten Sie die Instanzen sowohl einzeln als auch im gemeinsamen Betrieb. Ein einzelner hoher CPU-Wert bei unauffälligen Nachbarn deutet eher auf eine serverinterne Lastspitze. Gleichzeitige Engpässe, Speichergrenzen oder Swap-Aktivität sprechen eher für Konkurrenz oder zu knappe Host-Reserven. Wiederholen Sie den Test mit demselben Szenario.