Minecraft Server Multiworld Management: How to Run Multiple Worlds Without Killing Performance

# Minecraft Server Multiworld Management: How to Run Multiple Worlds Without Killing Performance

Running multiple worlds on a single Minecraft server is one of the most powerful ways to offer diverse gameplay — a survival world, a creative world, a resource world, minigame arenas, and more. But it comes with a serious cost: every loaded world consumes RAM, CPU ticks, and chunk-loading overhead, even when no players are in it.

This guide covers how to manage multiple worlds efficiently, which plugins to use, and exactly which settings to tune so your server stays at a stable 20 TPS.

---

Why Multiworld Tanks Performance

Each world in Minecraft runs its own:

• Chunk loading and unloading cycle
• Mob spawning calculations
• Weather and time ticking
• Redstone and block updates
• Entity tracking

If you load 5 worlds at startup but only 2 have players in them, your server is still spending CPU time ticking the other 3. On a heavily loaded server, this alone can drop you from 20 TPS to 15 TPS.

---

Choosing a Multiworld Plugin

Multiverse-Core

The most popular option. It's feature-rich and well-documented but has a reputation for being heavier than alternatives.

Pros: GUI support, per-world game rules, good community support

Cons: Can cause chunk loading inefficiencies, older codebase

MyWorlds

A leaner alternative that integrates tightly with Paper's world API. If you're running Paper 1.19+, MyWorlds is worth serious consideration.

Pros: Better compatibility with Paper internals, lighter footprint

Cons: Smaller community, fewer addons

Recommendation

For most servers: use Multiverse-Core with careful configuration. For high-performance Paper setups: switch to MyWorlds.

---

The Most Important Setting: World Auto-Load

By default, most multiworld plugins load all registered worlds at startup. This is almost always wrong for performance.

In Multiverse-Core, edit plugins/Multiverse-Core/worlds.yml:

worlds:
  resource_world:
    autoload: false
  minigame_arena:
    autoload: false
  survival:
    autoload: true

Set autoload: false for any world that doesn't need to be live 24/7. Worlds can be loaded on-demand via commands or custom logic (e.g., load the resource world only between certain hours).

---

Per-World Game Rules: Disable Expensive Features in Unused Worlds

In worlds where you don't need full simulation, kill expensive game mechanics:

/gamerule doMobSpawning false       # in creative/lobby worlds
/gamerule doWeatherCycle false      # in all non-survival worlds
/gamerule randomTickSpeed 0         # in static/museum worlds
/gamerule doPatrolSpawning false
/gamerule doTraderSpawning false

These commands need to be run inside each world. You can automate them with a plugin like CommandScheduler or a custom startup script.

---

Paper Per-World Configuration

Paper's paper-world.yml (or config/paper-world-defaults.yml in newer versions) supports per-world overrides. Create a file at:

world_name/paper-world.yml

For a lobby world, use aggressive settings:

chunks:
  auto-save-interval: -1          # disable per-world autosave if handled globally
  delay-chunk-unloads-by: 2s      # unload chunks faster when empty

mobs:
  spawn-limits:
    monsters: 0
    animals: 0
    water-animals: 0

entity-per-chunk-save-limit:
  experience_orb: 0

For a resource world that resets weekly:

chunks:
  delay-chunk-unloads-by: 5s

mobs:
  spawn-limits:
    monsters: 30
    animals: 10

This lets you tune each world independently instead of using a one-size-fits-all approach.

---

Controlling Chunk Loading Across Worlds

Chunk loading is the #1 killer in multiworld setups. Configure these in spigot.yml globally, then override per-world in Paper:

# spigot.yml
world-settings:
  default:
    view-distance: 6
    simulation-distance: 4
  survival:
    view-distance: 8
    simulation-distance: 5
  lobby:
    view-distance: 4
    simulation-distance: 3

A lobby world doesn't need a simulation distance of 8 — players are just walking around a hub. Drop it to 3 or 4 and you'll save significant CPU.

---

Resource Worlds: The Right Way to Reset Them

A common pattern is running a separate "resource world" that resets every week so players can mine freely without destroying the main world. Here's how to do it cleanly:

1. Pre-generate the world before putting it live (use Chunky)
2. Store a seed and a vanilla world template before players join
3. To reset: unload world → delete folder → copy template → reload
4. Use a scheduled task via cron or a plugin to automate this

Never reset a world while players are inside it. Always teleport players out, unload the world, then perform the reset.

---

Memory Budgeting for Multiple Worlds

Each loaded world with active players needs roughly:

• Base overhead: ~150–300 MB per world (chunk data, entity lists)
• Per chunk (loaded): ~400–800 KB in memory
• View distance 6, 20 players: ~600–900 MB per world

If you're running 4 active worlds simultaneously, allocate at least 10–12 GB of heap and tune your GC flags accordingly. A 4 GB server running 3 active worlds will run out of memory or trigger constant GC pauses.

Use PulseNode to monitor per-world RAM usage in real time — it surfaces memory pressure before it becomes an outage, so you can react before players notice lag.

---

Bukkit.yml: Global Chunk GC Settings

# bukkit.yml
chunk-gc:
  period-in-ticks: 400     # run chunk GC every 20 seconds

This controls how often Bukkit garbage-collects unloaded chunks from memory. The default is 600 ticks (30 seconds). In multiworld setups, reducing this to 400 ticks helps free memory faster when players leave a world.

---

Portal and World-Linking Optimization

If you're using Nether and End portals linked to custom worlds, portal searches are expensive. In spigot.yml:

world-settings:
  default:
    portal-search-radius: 64    # default is 128, reduce it
    portal-create-radius: 16

Also, avoid having Nether worlds for every custom world unless necessary. A shared Nether with a resource world just adds more loaded chunks with little benefit.

---

Quick Checklist for Multiworld Performance

• [ ] Disable autoload for worlds not needed at startup
• [ ] Set doMobSpawning false in lobby/creative worlds
• [ ] Use per-world paper-world.yml to tune mob limits and chunk settings
• [ ] Reduce view-distance and simulation-distance in non-survival worlds
• [ ] Pre-generate resource worlds with Chunky before opening them
• [ ] Allocate enough heap RAM for all active worlds simultaneously
• [ ] Set chunk-gc.period-in-ticks: 400 in bukkit.yml
• [ ] Reduce portal-search-radius to 64 in spigot.yml

---

Final Thoughts

Multiworld setups are powerful but unforgiving if misconfigured. The biggest wins come from not ticking what you don't need — disabled mob spawning, lower view distances, and smart autoload settings can cut your CPU usage by 30–40% in a typical 4-world setup.

If you're managing multiple worlds and want visibility into which one is causing lag, PulseNode's real-time monitoring breaks down performance by world, so you can pinpoint the culprit without digging through logs manually.

Start with the autoload settings and per-world paper configs — those two changes alone will make a noticeable difference on your next restart.