← Blog

Palworld-Server richtig dimensionieren: RAM, CPU und Einstellungen verstehen

Par Benjamin D. · PDG

· Mis à jour le 3. September 2026 · Lecture 8 min

Inhaltsverzeichnis

Palworld Server RAM ist der Faktor, an dem die meisten Welten früher oder später scheitern: Die Speicherlast wächst mit jeder Basis, jedem gefangenen Pal und jeder gespielten Stunde. Wer versteht, wie viel Arbeitsspeicher eine Welt real belegt, welche CPU-Eigenschaften zählen und welche Parameter in der PalWorldSettings.ini zusätzliche Last erzeugen, hält seine Runde dauerhaft flüssig und ruckelfrei.



Palworld Server RAM: Wie viel Arbeitsspeicher eine Welt wirklich belegt

Palworld läuft auf der Unreal Engine 5. Die Serveranwendung hält die komplette Welt im Arbeitsspeicher: aktive Pals, alle Basen mit ihren Arbeitern, gelagerte Items, Truhen, Bauteile und den Zustand jedes Spielercharakters. Anders als bei einer Minecraft-Welt, die in Chunks nachgeladen wird, bleibt in Palworld ein großer Teil der Simulation permanent aktiv. Das erklärt, warum der Speicherverbrauch nach dem Start moderat wirkt und nach zwei Wochen Spielzeit deutlich höher liegt.

Richtwerte nach Spielerzahl

Die folgenden Werte sind Praxisrichtwerte für eine Welt, die bereits einige Wochen bespielt wird. Bei einer frischen Welt liegt der Verbrauch spürbar niedriger – plane trotzdem mit dem Zielwert, sonst kippt die Runde genau dann, wenn die Community wächst.

SlotsArbeitsspeicher (Richtwert)Bemerkung
2–48 GBAbsolutes Minimum, funktioniert nur bei wenigen Basen
4–812–16 GBSolider Standard für eine private Gruppe
8–1616–24 GBMehrere Gilden mit ausgebauten Basen
16–3232 GB und mehrNur sinnvoll mit reduzierten Basis-Limits

Warum der Verbrauch mit der Zeit steigt

Drei Effekte treiben den Palworld Server RAM nach oben:

  • Wachsende Speicherdatei: Die Level.sav nimmt jede platzierte Struktur, jeden Pal und jede Gilde auf. Sie wird beim Start vollständig geladen.
  • Verwaiste Daten: Spieler, die nach zwei Stunden nicht wiederkommen, hinterlassen Gilden, Basen und Pals. Diese Objekte werden weiter simuliert.
  • Speicherfragmentierung: Die Serveranwendung gibt Speicher über lange Laufzeiten nicht sauber zurück. Ein geplanter Neustart alle 12 bis 24 Stunden ist die einfachste Gegenmaßnahme.

Prüfe die reale Belegung direkt auf der Maschine, statt zu raten:

free -h
ps -o pid,rss,etime,comm -C PalServer-Linux-Shipping
du -sh ~/Pal/Saved/SaveGames/0/*/

Der rss-Wert zeigt den tatsächlich belegten physischen Speicher in Kilobyte. Liegt er dauerhaft über 85 Prozent des verfügbaren Arbeitsspeichers, beginnt das System zu swappen – und genau dann entstehen die typischen Sekunden-Freezes beim Betreten einer fremden Basis.

Wenn du dir die Dimensionierung nicht selbst aufhalsen willst, sondern eine fertige Instanz mit Ryzen-CPU, NVMe-Storage und Pterodactyl-Panel bevorzugst: die Details dazu findest du unter Palworld Server mieten.



Single-Core-Leistung: der unterschätzte Flaschenhals

Arbeitsspeicher entscheidet darüber, ob die Welt läuft. Die CPU entscheidet darüber, wie flüssig sie läuft. Die Simulationsschleife von Palworld ist stark auf einen Hauptthread konzentriert. Zusätzliche Kerne helfen bei Netzwerk-Replikation, Speichervorgängen und Asset-Streaming, aber der Tick der Welt selbst hängt an der Taktfrequenz eines einzelnen Kerns.

Was das praktisch bedeutet

  • Eine CPU mit hoher Taktrate und starkem Single-Thread-Durchsatz (Ryzen-Klasse) liefert bei Palworld messbar ruhigere Ticks als ein Prozessor mit vielen, aber langsamen Kernen.
  • Geteilte, überbuchte CPU-Zeit ist bei Palworld besonders schmerzhaft: Steal Time auf dem Host äußert sich direkt als Rubberbanding im Spiel.
  • NVMe-Storage verkürzt die Autosave-Spitzen. Bei einer großen Level.sav auf klassischen Platten friert die Welt beim Speichern spürbar ein.

Startparameter, die die Threadverteilung beeinflussen

Die Serveranwendung akzeptiert mehrere Flags, die das Verhalten unter Last ändern:

./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS \
  -port=8211 -queryport=27015 -players=16 -publiclobby
  • -useperfthreads: aktiviert zusätzliche Performance-Threads der Engine.
  • -NoAsyncLoadingThread: verlagert das Laden von Assets in den Hauptthread – auf Maschinen mit schnellem Single-Core-Durchsatz oft die stabilere Variante.
  • -UseMultithreadForDS: verteilt Aufgaben der Serveranwendung auf mehrere Kerne.

Diese drei Flags werden in der Community meist zusammen gesetzt. Teste sie trotzdem einzeln und beobachte die Tickrate, denn das Ergebnis hängt vom konkreten Kern-Layout ab. Die offizielle technische Dokumentation zu Parametern und Ports findest du bei Pocketpair.

Netzwerk und Latenz

Palworld repliziert Positionsdaten von Spielern und Pals sehr häufig. Bei 16 aktiven Spielern mit je 15 arbeitenden Pals in Sichtweite steigt die ausgehende Bandbreite deutlich. Ein Standort in der Nähe deiner Community und ein Anti-DDoS-Filter, der Volumenangriffe bereits auf Infrastrukturebene abfängt, sind hier wichtiger als jedes zusätzliche GB Arbeitsspeicher. Wie andere Survival-Titel damit umgehen, siehst du beim Blick auf Alle unsere Gameserver.



PalWorldSettings.ini: Parameter mit direktem Lasteinfluss

Die Konfigurationsdatei liegt unter Pal/Saved/Config/LinuxServer/PalWorldSettings.ini (unter Windows entsprechend WindowsServer). Beim ersten Start ist sie leer – kopiere zuerst die Standardwerte:

cp DefaultPalWorldSettings.ini \
   Pal/Saved/Config/LinuxServer/PalWorldSettings.ini
nano Pal/Saved/Config/LinuxServer/PalWorldSettings.ini

Wichtig: Alle Werte stehen in einer einzigen Zeile innerhalb von OptionSettings=(...). Ein fehlendes Komma oder ein Zeilenumbruch führt dazu, dass die komplette Datei ignoriert wird und die Welt mit Standardwerten startet.

Die Parameter, die den Speicherbedarf treiben

ParameterStandardWirkung auf die Last
ServerPlayerMaxNum32Direkter Multiplikator für RAM und CPU
BaseCampMaxNumInGuild4Basen pro Gilde – jede Basis wird dauerhaft simuliert
BaseCampWorkerMaxNum15Arbeitende Pals pro Basis, sehr CPU-intensiv
GuildPlayerMaxNum20Indirekt: mehr Mitglieder, mehr Strukturen
PalSpawnNumRate1.0Anzahl wilder Pals in der Welt
AutoSaveSpan30Speicherintervall – kürzere Werte erzeugen häufigere Freezes
ServerReplicatePawnCullDistance15000Entfernung, bis zu der Pals repliziert werden

Konkrete Stellschrauben bei knappem Arbeitsspeicher

Wenn die Welt an ihre Grenzen kommt, wirken diese Anpassungen am schnellsten:

  1. BaseCampMaxNumInGuild auf 3 reduzieren. Die vierte Basis wird in den meisten Runden ohnehin nur als Lager genutzt, kostet aber volle Simulationszeit.
  2. BaseCampWorkerMaxNum auf 12 setzen. Weniger Pathfinding pro Basis, spürbar ruhigere Ticks bei vielen aktiven Gilden.
  3. PalSpawnNumRate auf 0.8 senken. Reduziert die Zahl gleichzeitig aktiver Wesen in der offenen Welt.
  4. ServerReplicatePawnCullDistance auf 12000 verringern. Entlastet Netzwerk und CPU, ohne dass es im Spiel auffällt.
  5. AutoSaveSpan erhöhen, wenn die Speicherdatei groß ist. Weniger Speichervorgänge bedeuten weniger Mikroruckler – im Gegenzug steigt der mögliche Fortschrittsverlust bei einem Absturz.

Beispielhafter Ausschnitt einer angepassten Zeile

OptionSettings=(Difficulty=None,ServerPlayerMaxNum=16,
BaseCampMaxNumInGuild=3,BaseCampWorkerMaxNum=12,
PalSpawnNumRate=0.800000,AutoSaveSpan=60.000000,
ServerReplicatePawnCullDistance=12000.000000,
bIsUseBackupSaveData=True,RCONEnabled=True,RCONPort=25575,
AdminPassword="langes-zufaelliges-passwort",
ServerName="Meine Welt",ServerDescription="")

Hinweis: Der Block ist hier zur Lesbarkeit umbrochen – in der Datei muss er in einer Zeile stehen. Nach jeder Änderung ist ein vollständiger Neustart der Instanz nötig, ein Reload reicht nicht.

Multiplayer-Einstellungen, die oft übersehen werden

  • bIsMultiplay und bIsPvP ändern die Menge der Zustandsdaten, die pro Tick geprüft werden. PvP erhöht die Netzwerklast messbar.
  • DeathPenalty auf None reduziert herumliegende Item-Drops – jeder Drop ist ein persistentes Objekt in der Speicherdatei.
  • bEnableInvaderEnemy=False schaltet Raid-Wellen ab. Das spart Spawn-Spitzen, nimmt aber Spielinhalt weg.
  • DropItemMaxNum begrenzt liegengebliebene Items global und hält die Level.sav kleiner.


Betrieb im Alltag: Monitoring, Sicherung und Wartung

Speicherdatei im Blick behalten

Die Größe der Level.sav ist der beste Frühindikator. Wächst sie in wenigen Wochen von 30 MB auf über 150 MB, steigen Ladezeit beim Start und Speicherbedarf parallel mit. Prüfe sie regelmäßig:

ls -lh ~/Pal/Saved/SaveGames/0/*/Level.sav
watch -n 60 'free -m | grep Mem'

Verwaiste Gilden und Pals inaktiver Spieler sind die häufigste Ursache für unnötiges Wachstum. Bereinigungen dieser Art gehören immer nach einem vollständigen Backup – im Pterodactyl-Panel legst du dafür vor jedem Eingriff eine Sicherung an und lädst sie zusätzlich lokal herunter.

Geplante Neustarts

Ein Neustart im Tagesrhythmus gibt fragmentierten Speicher frei. Vorher immer sauber speichern und die Spieler warnen. Über RCON:

Broadcast Neustart_in_5_Minuten
Save
Shutdown 300 Neustart_zur_Wartung

Beachte, dass Broadcast keine Leerzeichen akzeptiert – Unterstriche sind die übliche Lösung. Im Panel lässt sich derselbe Ablauf als geplanter Task hinterlegen, inklusive vorgeschaltetem Backup.

Wenn du die Maschine selbst verwaltest

Betreibst du die Instanz auf einer eigenen Linux-Maschine, gelten die üblichen Grundregeln: SSH ausschließlich mit Schlüsseln, Passwort-Login deaktiviert, fail2ban aktiv, ufw so restriktiv wie möglich.

ssh-keygen -t ed25519 -C "palworld-admin"
sudo apt update && sudo apt install -y fail2ban ufw
sudo ufw allow 8211/udp
sudo ufw allow 27015/udp
sudo ufw enable
sudo systemctl enable --now fail2ban

Der RCON-Port gehört nicht offen ins Internet. Binde ihn an localhost und greife über einen SSH-Tunnel darauf zu. Ein Admin-Passwort von 24 Zeichen oder mehr ist Pflicht, ebenso ein Backup-Ziel außerhalb der Maschine. Volumetrische Angriffe fängt die Infrastruktur von Fly-Serv bereits vor der Instanz ab – gegen ein schwaches RCON-Passwort hilft das allerdings nicht.

Ähnliche Muster in anderen Survival-Welten

Das Grundprinzip – persistente Objekte treiben den Speicherbedarf, Single-Core-Leistung bestimmt die Tickrate – gilt für viele Titel dieser Kategorie. Wer parallel eine Welt in Valheim Server betreibt, kennt den Effekt von zu vielen platzierten Bauteilen. Weitere Konfigurationsleitfäden sammeln wir im Fly-Serv Blog.



Fazit

Arbeitsspeicher, Taktfrequenz und eine durchdachte PalWorldSettings.ini greifen ineinander. Wer die Basis- und Pal-Limits an die reale Spielerzahl anpasst, die Speicherdatei beobachtet und täglich sauber neu startet, hält die Welt auch nach Monaten flüssig. Miss lieber einmal nach, statt bei jedem Ruckler blind an Werten zu drehen – die Zahlen aus free -h sagen mehr als jedes Bauchgefühl.



FAQ

Wie viel Arbeitsspeicher braucht ein Palworld-Server für 10 Spieler?

Plane 16 GB ein. Eine frische Welt läuft anfangs auch mit 12 GB, aber sobald mehrere Gilden je drei bis vier Basen mit voller Arbeiterzahl betreiben, steigt die Belegung deutlich. Prüfe den Verbrauch mit free -h und reduziere BaseCampMaxNumInGuild sowie BaseCampWorkerMaxNum, falls du dauerhaft über 85 Prozent liegst.

Warum ruckelt die Welt trotz freiem Arbeitsspeicher?

Dann liegt der Engpass bei der CPU, nicht am RAM. Palworld hängt stark an einem Hauptthread: Zu viele arbeitende Pals, zu viele Basen oder eine zu hohe Replikationsdistanz überlasten diesen Kern. Senke BaseCampWorkerMaxNum, setze ServerReplicatePawnCullDistance auf 12000 und teste die Startflags -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS.

Werden Änderungen an der PalWorldSettings.ini sofort übernommen?

Nein. Die Datei wird nur beim Start der Instanz gelesen. Stoppe den Prozess über das Panel oder per Shutdown via RCON, bearbeite die Datei und starte anschließend neu. Achte darauf, dass alle Werte in einer einzigen Zeile innerhalb von OptionSettings=(...) stehen – sonst wird die gesamte Konfiguration ignoriert.