139
If your Minecraft server starts lagging, randomly drops TPS or freezes when more players join, randomly changing configuration values is usually not the best way to fix it.
A better option is to find out what is actually using server tick time.
For Paper servers, one of the easiest tools for this is spark.
On modern Paper versions, spark is already included with the server, so in most cases you do not need to install another plugin.
Run:
<span>/tps</span>
A healthy server should normally stay close to:
<span>20 TPS</span>
You can also check MSPT:
<span>/mspt</span>
MSPT means milliseconds per tick.
Minecraft tries to run 20 ticks every second, which gives the server about 50 milliseconds to complete each tick.
A simple way to read MSPT:
<span>Below 30 MSPT = usually fine<br>30-50 MSPT = getting heavier<br>Above 50 MSPT = server can no longer maintain 20 TPS</span>
Do not panic because of one short spike. What matters more is whether high MSPT happens regularly or stays high for longer periods.
<span>/spark profiler start --timeout 600</span>
This records server activity for 600 seconds, which is 10 minutes.
When the profile finishes, spark gives you a link to the report.
Open the report in your browser.
It is important to run the profiler while the lag is actually happening.
For example, if your server only lags with 40 players online, profiling it at 4 AM with two players online will probably not show the real problem.
Examples:
The report shows where the server spent its processing time during the profiling period.
You do not need to understand every Java method in the report.
Start by looking for sections that take a large percentage of tick time.
If one plugin repeatedly appears high in the profile, it is worth investigating.
For example, if you see a plugin responsible for a large amount of server thread activity, check:
Some plugins naturally appear because they are responsible for important server tasks.
The important part is finding something that is using an unreasonable amount of tick time.
In that case you can tell spark to only record slow ticks.
Example:
<span>/spark profiler start --only-ticks-over 100 --timeout 300</span>
This runs for five minutes and focuses on ticks taking longer than 100 milliseconds.
This can be useful when you have problems such as:
<span>Server runs at 20 TPS<br>Server randomly freezes<br>MSPT suddenly jumps<br>Players rubberband for a second<br>Everything returns to normal</span>
A normal profile may contain a lot of unrelated activity.
Filtering slow ticks makes short lag spikes easier to investigate.
Paper provides a useful command:
<span>/paper entity list *</span>
This displays information about currently loaded entities.
If one world has a very large number of mobs, villagers, armor stands or other entities, investigate that area.
You can also specify a world:
<span>/paper entity list * world</span>
Examples of things worth checking:
Find out why the excessive number of entities exists first.
Paper provides:
<span>/paper chunkinfo</span>
This gives information about loaded chunks.
If a plugin, farm or chunk loader keeps a huge number of chunks active, it may be contributing to performance problems.
This is especially worth checking if your server has:
<span>/timings</span>
On modern Paper servers, spark is the better option.
Paper has deprecated Timings and recommends using spark for performance profiling instead.
If you are following an old optimization guide that relies entirely on Timings, it may be worth using spark instead.
First check:
<span>/tps<br>/mspt</span>
Confirm that MSPT is regularly above 50.
Then start:
<span>/spark profiler start --timeout 600</span>
Leave players playing normally for ten minutes.
When the report finishes:
If performance improves, you know which change actually helped.
Check:
<span>/paper entity list *</span>
Pre-generating the playable area can reduce this problem.
spark can help you identify where server time is being spent.
Check:
<span>/paper chunkinfo</span>
Temporarily disabling the machine while profiling can help confirm whether it is responsible.
Backups, database cleanup, map rendering and plugin saves can sometimes create short performance spikes.
Minecraft server performance depends on more than memory.
CPU performance, plugins, entities, chunks, world generation and server configuration can all affect tick time.
A server can have plenty of unused RAM and still have terrible TPS.
Profile first, then decide what needs to be changed.
You do not need to run all of these every time.
Usually the basic process is:
<span>Check MSPT<br>Start spark<br>Reproduce the problem<br>Open the report<br>Find the cause<br>Make one change<br>Test again</span>
If your server is running perfectly at 20 TPS, you do not need to randomly change dozens of Paper settings because an optimization guide told you to.
When a real performance problem appears, capture it with spark and work from the report.
This makes troubleshooting faster and also helps you avoid breaking gameplay mechanics for performance improvements you may not even need.
Always make a backup before making major changes to a production server.
A better option is to find out what is actually using server tick time.
For Paper servers, one of the easiest tools for this is spark.
On modern Paper versions, spark is already included with the server, so in most cases you do not need to install another plugin.
Step 1: Check TPS and MSPT
Before creating a profile, check if the server is actually struggling.Run:
<span>/tps</span>
A healthy server should normally stay close to:
<span>20 TPS</span>
You can also check MSPT:
<span>/mspt</span>
MSPT means milliseconds per tick.
Minecraft tries to run 20 ticks every second, which gives the server about 50 milliseconds to complete each tick.
A simple way to read MSPT:
<span>Below 30 MSPT = usually fine<br>30-50 MSPT = getting heavier<br>Above 50 MSPT = server can no longer maintain 20 TPS</span>
Do not panic because of one short spike. What matters more is whether high MSPT happens regularly or stays high for longer periods.
Step 2: Start a spark Profile
If the server is lagging while players are online, start a profile:<span>/spark profiler start --timeout 600</span>
This records server activity for 600 seconds, which is 10 minutes.
When the profile finishes, spark gives you a link to the report.
Open the report in your browser.
It is important to run the profiler while the lag is actually happening.
For example, if your server only lags with 40 players online, profiling it at 4 AM with two players online will probably not show the real problem.
Step 3: Reproduce the Lag
While spark is running, try to reproduce whatever normally causes the problem.Examples:
- Players exploring new chunks
- Large mob farms running
- Players joining the server
- Large redstone machines
- Crates or menus being opened
- Custom mobs spawning
- Large numbers of dropped items
- Scheduled plugin tasks
- World backups
- Map rendering
Step 4: Read the spark Report
After the profiler finishes, open the link that spark gives you.The report shows where the server spent its processing time during the profiling period.
You do not need to understand every Java method in the report.
Start by looking for sections that take a large percentage of tick time.
If one plugin repeatedly appears high in the profile, it is worth investigating.
For example, if you see a plugin responsible for a large amount of server thread activity, check:
- Its configuration
- Its update interval
- How many entities or objects it manages
- Whether a newer version exists
- Whether the plugin is generating errors
- Whether another plugin can replace it
Some plugins naturally appear because they are responsible for important server tasks.
The important part is finding something that is using an unreasonable amount of tick time.
Step 5: Profile Only Large Lag Spikes
Sometimes the average server performance looks fine, but players experience random freezes.In that case you can tell spark to only record slow ticks.
Example:
<span>/spark profiler start --only-ticks-over 100 --timeout 300</span>
This runs for five minutes and focuses on ticks taking longer than 100 milliseconds.
This can be useful when you have problems such as:
<span>Server runs at 20 TPS<br>Server randomly freezes<br>MSPT suddenly jumps<br>Players rubberband for a second<br>Everything returns to normal</span>
A normal profile may contain a lot of unrelated activity.
Filtering slow ticks makes short lag spikes easier to investigate.
Step 6: Check Entity Counts
Entities are a common source of server load.Paper provides a useful command:
<span>/paper entity list *</span>
This displays information about currently loaded entities.
If one world has a very large number of mobs, villagers, armor stands or other entities, investigate that area.
You can also specify a world:
<span>/paper entity list * world</span>
Examples of things worth checking:
- Massive villager trading halls
- Mob grinders
- Hundreds of armor stands
- Large amounts of dropped items
- Farms keeping many mobs active
- Plugins spawning custom entities
Find out why the excessive number of entities exists first.
Step 7: Check Loaded Chunks
Large numbers of loaded chunks can also increase server load.Paper provides:
<span>/paper chunkinfo</span>
This gives information about loaded chunks.
If a plugin, farm or chunk loader keeps a huge number of chunks active, it may be contributing to performance problems.
This is especially worth checking if your server has:
- Chunk loader plugins
- Large automation systems
- Multiple worlds
- Map rendering plugins
- Custom world generators
- Players spread across huge distances
Step 8: Do Not Use Timings as Your First Choice
Older Minecraft server guides often tell you to run:<span>/timings</span>
On modern Paper servers, spark is the better option.
Paper has deprecated Timings and recommends using spark for performance profiling instead.
If you are following an old optimization guide that relies entirely on Timings, it may be worth using spark instead.
Example Troubleshooting Process
Imagine your server normally runs fine but drops to 15 TPS when 30 players are online.First check:
<span>/tps<br>/mspt</span>
Confirm that MSPT is regularly above 50.
Then start:
<span>/spark profiler start --timeout 600</span>
Leave players playing normally for ten minutes.
When the report finishes:
- Open the spark report.
- Find the largest consumers of tick time.
- Check whether a plugin or game mechanic is responsible.
- Change one thing.
- Restart if required.
- Run another profile.
- Compare the result.
If performance improves, you know which change actually helped.
Common Causes of Minecraft Server Lag
Too Many Entities
Mob farms, villagers and custom mobs can create a lot of work for the server.Check:
<span>/paper entity list *</span>
New Chunk Generation
Players generating unexplored terrain can create heavy CPU usage.Pre-generating the playable area can reduce this problem.
Heavy Plugins
A badly configured plugin can run expensive tasks too frequently.spark can help you identify where server time is being spent.
Too Many Loaded Chunks
Chunk loaders, plugins and players spread across multiple worlds can keep large areas active.Check:
<span>/paper chunkinfo</span>
Large Redstone Builds
Large automated farms and redstone clocks can create significant tick activity.Temporarily disabling the machine while profiling can help confirm whether it is responsible.
Backups and Other Scheduled Tasks
If lag always appears at the same time every hour or every day, check your scheduled tasks.Backups, database cleanup, map rendering and plugin saves can sometimes create short performance spikes.
Do Not Assume RAM Is the Problem
One of the most common mistakes is seeing lag and immediately buying more RAM.Minecraft server performance depends on more than memory.
CPU performance, plugins, entities, chunks, world generation and server configuration can all affect tick time.
A server can have plenty of unused RAM and still have terrible TPS.
Profile first, then decide what needs to be changed.
Useful Commands
<span>/tps<br>/mspt<br>/spark profiler start --timeout 600<br>/spark profiler start --only-ticks-over 100 --timeout 300<br>/paper entity list *<br>/paper chunkinfo</span>You do not need to run all of these every time.
Usually the basic process is:
<span>Check MSPT<br>Start spark<br>Reproduce the problem<br>Open the report<br>Find the cause<br>Make one change<br>Test again</span>
Final Notes
Server optimization should be based on measurements instead of guessing.If your server is running perfectly at 20 TPS, you do not need to randomly change dozens of Paper settings because an optimization guide told you to.
When a real performance problem appears, capture it with spark and work from the report.
This makes troubleshooting faster and also helps you avoid breaking gameplay mechanics for performance improvements you may not even need.
Always make a backup before making major changes to a production server.