Twenty players on a Tuesday. No problems. One hundred players on a Saturday. TPS crashes to 12, chat lags, blocks take a second to break, and mobs teleport around instead of walking.
The "Saturday crater" is one of the hardest scaling problems in Minecraft hosting. The game server runs on a single thread for its main tick loop. More players means more entities, more chunk loading, more hopper ticking, and more redstone computation. All of it stacks onto that one thread.
Here is how to handle it.
Why 100 Players Breaks Things
Each player online adds load in several ways:
- Chunk loading: Every player forces the server to keep chunks loaded around them. 100 players spread across the map means thousands of active chunks
- Entity processing: Each loaded chunk ticks its entities. More chunks = more mobs, more item drops, more XP orbs
- Network packets: The server sends position updates for every nearby entity to every nearby player. 10 players in the same area generate 10x10 = 100 position update pairs per tick
- Redstone and hoppers: Player bases with hopper chains and redstone circuits tick constantly. 100 players with 100 bases means massive redstone overhead
A Ryzen 9 3900X at full boost handles the single-threaded tick loop at 4.6 GHz. That is fast, but Minecraft's architecture means you cannot throw more cores at the problem. You need to reduce the work per tick.
Step 1: Reduce Simulation Distance
This is the single most effective change. Simulation distance controls how far from each player the server ticks entities and redstone.
In server.properties:
simulation-distance=6
Default is 10. Reducing to 6 cuts the ticked area per player by roughly 60 percent. Players still see terrain at full view distance, but mobs and redstone only run within 6 chunks.
In spigot.yml, also check:
world-settings:
default:
view-distance: 8
simulation-distance: 6
Step 2: Limit Hopper Tick Rate
Hoppers are the number one lag source on established survival servers. Each hopper checks for items to pull and push every single tick. A sorting system with 200 hoppers runs 200 item checks per tick, 4000 per second.
In paper-world-defaults.yml:
hopper:
cooldown-when-full: true
disable-move-event: false
On older Paper versions, use spigot.yml:
ticks-per:
hopper-transfer: 8
hopper-check: 1
Setting hopper-transfer to 8 means hoppers move items every 8 ticks instead of every 1 tick. Items move slower but the server saves massive CPU time.
Step 3: Limit Entity Counts
In bukkit.yml:
spawn-limits:
monsters: 40
animals: 10
water-animals: 3
water-ambient: 3
water-underground-creature: 3
axolotls: 3
ambient: 1
Default monster limit is 70. Dropping to 40 means fewer mobs spawn per player. Combined with simulation distance reduction, this dramatically cuts entity processing time.
In paper-world-defaults.yml, also limit entity tick rates:
entity-per-chunk-save-limit:
experience_orb: 16
arrow: 16
item: 32
Step 4: Use Async Chunk Loading
Paper handles chunk loading asynchronously (off the main thread) by default. Make sure you are running Paper, not vanilla or Spigot. Vanilla and Spigot load chunks on the main thread, which blocks the entire tick loop when 50 players are exploring new terrain simultaneously.
If you run Paper (and you should), chunks load in background threads. The main thread stays free for entity processing and game logic.
Step 5: Monitor with Spark
Install the Spark profiler plugin. During your Saturday peak, run:
/spark profiler start
Wait 5 minutes, then:
/spark profiler stop
Open the generated URL. The profile tree shows exactly what is consuming the most tick time. Common findings:
| Source | Typical Tick Cost | Fix | |---|---|---| | Hopper transfers | 5-15ms/tick | Reduce hopper tick rate | | Entity pathfinding | 3-10ms/tick | Lower mob spawn limits | | Chunk generation | 2-8ms/tick | Pre-generate terrain | | Redstone updates | 1-5ms/tick | Reduce simulation distance | | Plugin overhead | Varies | Profile individual plugins |
Step 6: Pre-Generate Terrain
When players explore new areas, the server generates terrain in real time. This is CPU-intensive. On a Saturday with 100 players exploring, chunk generation alone can eat half your tick budget.
Pre-generate terrain before it is needed:
Install Chunky (chunky plugin on SpigotMC):
/chunky radius 5000
/chunky start
This generates all terrain within 5000 blocks of spawn. Run this during off-peak hours (Tuesday night). By Saturday, all the popular areas are pre-generated and the server only needs to load them from disk instead of computing them.
Step 7: Hardware Matters
All the optimization above reduces CPU load. But at 100+ players, you still need strong hardware.
Minimum recommendations for 100 players:
| Component | Requirement | |---|---| | CPU | High single-thread performance (4.0 GHz+). Ryzen 9 3900X or newer | | RAM | 10-16 GB allocated to Minecraft (plus 2 GB for the OS) | | Storage | NVMe SSD (chunk loading from spinning disks is unacceptable at this scale) | | Network | 1 Gbps connection minimum |
Space-Node runs AMD Ryzen 9 3900X processors with NVMe storage in the Netherlands. Plans go up to 16 GB dedicated RAM. For servers that need to scale past 100 players regularly, contact support for custom configurations. Check the plans here.
