Ready to play?
Your Server Is
One Click Away.
Pick your game, choose a plan, and start playing in under 60 seconds. No lag, no excuses.
Woof! Let's go!
Ready to play?
Pick your game, choose a plan, and start playing in under 60 seconds. No lag, no excuses.
Woof! Let's go!
Minecraft server lag usually shows up as low TPS, and the cause is almost always one of four things: a badly sized Java heap, view and simulation distance set too high, entity buildup, or one misbehaving plugin. Check /tps, run /spark profiler to find what is eating each tick, then fix that one thing before buying more RAM.
Low TPS is the most misdiagnosed problem in Minecraft hosting. The instinct is to buy more RAM, and sometimes that is the fix. Far more often the server has plenty of memory and is held back by a setting, a plugin, or a badly sized heap. This guide shows how to find out which, using tools that ship with modern server software.
On Paper, Purpur or Spigot, type tps in the Console tab. It reports ticks per second averaged over the last 1, 5 and 15 minutes. Vanilla servers have /tick query instead.
Each tick has a 50 ms budget. When ticks regularly take longer (you will see this called MSPT, milliseconds per tick), TPS drops below 20.
If TPS sits at 20 while players complain about stutter, you are looking at client frame rate or a connection problem, and no amount of server tuning will fix it. That distinction saves a lot of wasted effort.
Paper has bundled the spark profiler since 1.21, and so do forks built on it like Purpur. It turns guesswork into an answer. In the console:
/spark profiler start
Leave it running for a few minutes of normal play, then:
/spark profiler stop
It uploads the results and gives you a link to a report showing exactly which plugins, entities and tasks consumed tick time. Read it before you change a single setting.
The usual culprits it surfaces:
/spark tps and /spark health give a faster snapshot if you want a quick read before committing to a full profile.
A Java server has a heap, which is the memory your world and plugins live in, and it also needs memory outside the heap for the JVM itself: metaspace, code cache, thread stacks, garbage collection structures and network buffers. That overhead runs a couple of hundred MB and it does not come out of the heap.
If you give the heap effectively all of the container's memory, the process grows past its limit and the kernel kills it. There is no warning and no graceful shutdown, so the world never flushes to disk and the next start rolls back to the last autosave. Players describe that as "the server keeps crashing and we lose progress", and it reads like a hardware fault when it is a configuration one.
The rule: leave real headroom outside the heap. On a small plan that means a smaller share of total memory, not a fixed number, because the same 250 MB of overhead is a much bigger slice of 1 GB than of 12 GB. If you manage your own startup flags, check this first whenever a server dies with nothing in the log. It is a quick fix once you know to look.
Once you have a profile, these are the changes that actually move TPS, roughly in order of impact per unit of pain:
View distance (view-distance in server.properties, default 10). The single biggest lever on a populated server. The loaded area grows with the square of the distance, so dropping from 10 to 7 roughly halves the chunks the server keeps around each player, and most players do not notice. Edit it in the Files tab and restart.
Simulation distance (simulation-distance, also default 10). Separate from view distance and often overlooked. This controls how far out entities and redstone actually tick. It can sit lower than view distance, so players still see distant terrain without the server simulating it.
Entity limits. Paper's config/paper-world-defaults.yml lets you lower mob spawn limits and cap how many of a given entity a chunk can save. A server dragged down by a mob farm is fixed here rather than by more memory.
Autosave. Saving a large world can cause periodic hitches. If your TPS graph shows a regular sawtooth rather than a flat line, look at auto-save-interval and max-auto-save-chunks-per-tick in the same file.
Change one thing at a time and re-run /spark tps, so you know exactly which change did the work.
Sometimes it does. Add memory when:
/spark gc shows the history).Do not add memory because usage "looks high". A JVM will happily use the heap it has been given and collect when it needs to. High usage with healthy TPS is the system working.
Our Minecraft server RAM guide covers sizing by player count and modpack in more detail, and the server resource calculator gives you a starting number in seconds.
If you are still on vanilla or an old Spigot build, switching to Paper is the cheapest performance win available. Paper includes spark, ships a long list of optimisation patches, and exposes the per-world tuning above. Minecraft moved to year-based version numbers in 2026 (26.1, 26.2, and 26.3, the latest drop, released September 15), and every 26.x release needs Java 25.
Forks like Purpur add further tuning knobs on top of Paper. Our Paper vs Purpur comparison covers which fork suits which server.
Measure before you buy. Check TPS, run /spark profiler to find what is consuming the tick, then change one setting at a time. View distance and a correctly sized heap fix a large share of real cases, and both are free.
BruceNode Minecraft servers run on premium AMD hardware that is single-thread-optimized, with DDR5 and NVMe storage, which suits a game whose main loop runs on one thread. The Java heap is sized for you at setup (75% of the container under 4 GB, 85% from 4 GB), so the JVM always keeps its headroom. Paper is the default, so spark is there from the first boot.
Plans start at $2 a month for 1 GB, and the 4 GB Standard plan at $8 is our most popular. If you outgrow yours, our team can move you to a bigger one. Start a Minecraft server on BruceNode with code BRUCE20 for 20% off your first month.
20 TPS is the maximum and what a healthy server holds. Brief dips to 19 go unnoticed, and sustained readings under 18 are when players start to feel delayed blocks and mobs.
The default is 10. On a busy server, 6 to 8 with simulation distance a step or two lower is a common sweet spot, and most players never notice the change.
Usually one thing: a mob farm, a pile of dropped items, a redstone clock, or a plugin doing too much work each tick. A short spark profile will name it, and the fix is usually quick.