Zum Inhalt springen 
To fix low Minecraft TPS, measure tick duration during the slowdown, capture a spark profile, and identify the work delaying ticks. Check plugin tasks, entities, chunk activity, and CPU availability. Test one change on a recoverable copy, repeat the same workload, and confirm that gameplay and saving still work.
Start with your server build, Java version, player activity, recent changes, and the time of each incident. These details help separate a busy farm from a plugin fault, memory pressure, or a host resource limit.
This Minecraft low TPS troubleshooting guide focuses on Java Edition running Paper. We use a repeatable process: measure the problem, isolate its cause, check the result, and keep a working recovery path.
Distinguish TPS from Network Lag
TPS means ticks per second. It measures how often the server advances its game simulation. Minecraft normally targets 20 TPS, which gives the server an average processing budget of 50 milliseconds per tick.
MSPT means milliseconds per tick. A tick that finishes in 20 milliseconds leaves time before the next scheduled tick. It does not need to consume the full 50 milliseconds. Sustained processing above that budget reduces the achievable tick rate.
TPS alone can hide short freezes. Check median, 95th-percentile, and maximum tick duration over the incident window. The 95th percentile shows the value at or below which 95% of recorded tick durations fall. A maximum identifies the slowest recorded tick, but does not show how often that delay occurred. See the Spark explanation of TPS and MSPT.
| Symptom | First check | What to investigate |
|---|---|---|
| Mobs, block actions, and farms slow down | TPS and tick duration during the event | Work delaying the server tick |
| Short freezes with normal average TPS | Slow-tick samples and timestamps | Brief processing or pause events |
| Actions arrive late while tick metrics stay normal | Player latency and packet loss | Network route, server connection, or client connection |
| One player sees choppy movement | Client FPS and render load | Local graphics or client performance |
| Terrain arrives slowly during travel | Chunk activity and network conditions | Generation, loading, delivery, or queues |
Ping measures connection delay. FPS measures client rendering speed. Neither is a substitute for server tick measurements.
The number of affected players is a clue, not proof. One player can trigger expensive work in a particular area. A shared network problem can affect several players while the tick loop remains healthy.
Prerequisites and Supported Versions
Use a supported Paper release and the Java runtime required for that release. At the documentation check for this draft, Paper lists Java 25 for 26.1 and newer. Confirm the requirement for your exact build in Paper’s setup documentation.
Paper includes spark from version 1.21 onward. Its documentation favors spark over the older Timings workflow. Check the startup log before installing a second copy. Commands and settings here should not be applied unchanged to Bedrock, Folia, or modded server platforms. See Paper’s profiling guidance.
Before testing, prepare:
- Console access or the required spark permissions.
- A stopped-server backup and a separate test instance.
- Matching world files, plugin data, and configuration.
- Enough storage for the backup, test world, and reports.
- A record of CPU allocation, memory limits, software versions, and test date.
Keep the test instance disconnected from production databases, payment systems, and webhooks. Use a separate port and restricted access. Check that the backup restores before changing the test copy.
If you still need the operating-system setup, use our Minecraft Java server on a Linux VPS guide. That installation guide covers a separate task; it does not replace Paper-specific checks.
Profile Slow Ticks
Capture the problem while players perform the activity that causes it. An empty server after a restart can produce a clean report that says little about peak-hour lag.
Write down the incident time, player count, affected world, and activity. Note whether the slowdown started after a plugin update, during exploration, near a farm, or alongside a backup.
Configuration and Expected Output
Enter these commands in the Minecraft server console. In game, add a leading slash and use an account with the required permission. Do not paste them into a Linux shell.
spark tps
spark health show
spark profiler start –timeout 600
The first command reports tick metrics. The second prints a health summary. The third starts a ten-minute profile and returns a report link when it finishes.
If a profiler is already active, check its status before starting another capture:
spark profiler info
To end an active capture early:
spark profiler stop
For a separate capture of severe spikes, use:
spark profiler start –only-ticks-over 100 –timeout 300
This records samples from ticks above 100 milliseconds for five minutes. It excludes smaller delays, so retain a normal capture too. The threshold is a diagnostic filter, not a health target.
If a command fails, check permissions and the installed version against the spark command reference. Keep report access restricted until you have checked its contents for sensitive details.
Read the Profile Before Choosing a Fix
Start with the incident window, then inspect the relevant server thread and expand the costly call paths. The viewer helps show where sampled execution time was spent. Follow the caller chain before assigning blame to a plugin or game system. See Spark’s viewer guide.
A plugin name in a large branch is a lead. It can call expensive game operations, wait for another service, or share a parent method with unrelated work. Test the suspected behavior before deciding that removal is the answer.
Keep an annotated copy of the baseline report. Mark the incident window, tick-duration readings, and suspected call path. Save the accompanying activity notes so another administrator can repeat the test.
Isolate Plugins, Entities, and Chunk Generation
Choose a test from the evidence. Changing several settings at once makes the result harder to explain and the successful change harder to keep.
| Evidence during the incident | Controlled test | Failure check |
|---|---|---|
| A plugin task dominates the relevant path | Change one feature or compatible plugin version | Missing dependencies or new errors |
| Entity or block-entity work rises | Pause the identified farm or mechanism | Broken behavior or lost items |
| Spikes occur in new terrain | Compare controlled exploration conditions | Different routes or already-generated chunks |
| Simulation work is expensive | Reduce simulation distance for one test | Farms stop working at the required distance |
| Freezes align with memory or storage pressure | Compare pause records and scheduled jobs | Treating correlation alone as proof |
Check CPU Availability, Memory Pauses, and Storage Delays
Low total CPU usage does not prove that the server has spare tick capacity. The main tick thread can limit progress while other cores remain less busy. Minecraft also performs work on other threads, so “Minecraft uses only one core” is too broad.
Check what the hosting panel’s CPU percentage measures. Ask whether it represents one core, several allocated cores, or the whole host. Record quota limits and any visible throttling. A processor model alone doesn’t show how much CPU time the instance gets.
For memory, separate Java heap use from total process memory. A high heap reading alone does not prove a leak. Look for pauses that coincide with freezes, repeated collection pressure, swapping, or process-limit failures. Paper discusses these distinctions in its troubleshooting documentation.
Check saves, backups, and other scheduled jobs against incident timestamps. Storage type is only part of the picture. Shared storage contention, queues, or competing jobs can affect the workload. Keep saving enabled while you investigate.
Find a Plugin That Delays Ticks
Use the test copy for plugin changes:
- Reproduce the slowdown and keep the baseline report.
- Stop the test server cleanly.
- Back up the suspect plugin’s configuration and data.
- Change one feature, or test one compatible plugin update.
- Restart and inspect the startup log.
- Repeat the same player activity and capture another profile.
If the suspect is unclear, test dependency-aware plugin groups. Keep required libraries with the plugins that use them. Avoid hot-unloading plugins or using a reload as a substitute for a clean restart.
Reject a result if the server now fails to load permissions, economy services, protection rules, or other required functions. A repair that reduces work due to a broken plugin stack is not successful.
Test Entities, Villagers, Hoppers, and Redstone
Follow the profile to a specific mechanism or area. Possible workloads include villagers searching for paths, item collections, mob farms, hopper systems, and repeating redstone circuits. Their costs depend on the build and activity, not just the count.
On the test copy, pause one identified mechanism using its normal controls. Keep player locations and other activity unchanged. Compare the profile with the mechanism active and paused.
Before editing a setting, identify its purpose:
| Steuern | What it changes |
|---|---|
| Spawning limits | Rules for new natural spawns |
| Activation range | How loaded entities tick outside a range |
| Tracking range | How far entity information is sent to players |
| Merge radius | How nearby items or experience are combined |
| Save limits | Which entities persist through chunk saving and loading |
Paper documents activation ranges and merge radius in spigot.yml under world settings. Check the Spigot configuration reference for the exact structure.
Paper’s chunks. entity-per-chunk-save-limit is a persistence control. It is not a general live population cap. Changing it can affect which entities survive saving and loading. Check the world configuration reference before using it.
Avoid broad item or entity deletion as the default repair. It can remove player property without proving the cause. Test collection, trading, farm output, and protection behavior after any relevant change.
Separate Chunk Generation, Loading, and Simulation
These are different jobs. Generation creates new terrain. Loading brings existing terrain into memory. Simulation advances active game behavior.
If the incident occurs during exploration, compare travel through existing terrain with travel through new terrain. Record the route and world snapshot. Repeating yesterday’s exploration route today also changes the workload because those chunks already exist.
View distance controls the server’s chunk view distance; simulation distance controls the reach of simulation around players. Check effective world overrides before editing either setting. Their documented meanings appear in Paper’s server.properties reference.
For example, if the test server currently uses simulation distance 10, a controlled trial could change only that value to 8:
# server.properties: example test value
simulation-distance=8
Stop the test server before editing, preserve the original file, and restart afterward. Keep view distance unchanged for this comparison. Confirm the effective setting and test the farms or activities players need at a distance. Eight is an example trial value, not a universal recommendation.
Pre-generation is useful when new terrain generation is the measured cause. For a small test selection with a compatible Chunky installation, explicitly set the world and area:
chunky world world
chunky shape square
chunky center 0 0
chunky radius 500
chunky selection
Check the displayed selection and available disk space before starting:
chunky start
Monitor progress and host load. Pause the task if necessary:
chunky pause
This example uses a 500-block radius for a bounded test. It is not a recommended production world size. Generation consumes time and storage; it does not remove future entity or plugin work. Canceling a task does not undo terrain already generated. Use the saved world snapshot for restoration. See the official Chunky commands.
Success and Failure Checks
Keep a change only when the same activity produces a repeatable improvement and required gameplay still works.
Reject the test if player numbers fell, a dependency failed, inventory changed unexpectedly, saving failed, or the problem did not occur during the capture. Restore the baseline before testing another explanation.
Check Improvements Without Masking Errors
Use the same player count, activity, route, software, capture duration, and warm-up procedure for comparable runs. Keep profiler filters consistent.
For a practical first comparison, repeat each condition three times where feasible. Report variation instead of selecting the best run. Test new terrain from matching starting snapshots so earlier generation does not quietly remove the original workload.
Compare Before-and-After Profiler Captures
Build a record from actual measurements:
| Record | Before change | After change | After restoration |
|---|---|---|---|
| Player count and activity | Baseline | Matching workload | Matching workload |
| TPS windows and tick duration | Measured | Measured | Measured |
| Suspected call path | Baseline capture | Comparison capture | Recovery capture |
| Logs and plugin functions | Checked | Checked | Checked |
| Save, restart, and rejoin | Checked | Checked | Checked |
Attach the before-and-after reports with captions that state the exact change and workload. If fewer mobs or a shorter simulation run produced the gain, explain that gameplay tradeoff.
Do not lower the target tick rate, disable the watchdog, stop world saving, or hide warnings to improve the displayed result. These actions can conceal the problem or change what the server is doing.
Rollback and Maintenance
Stop the test server. Restore the original configuration and compatible plugin files. If the test changed data, restore the matching world and plugin-data backup too. Replacing a JAR alone may not reverse a data migration.
Start the restored instance and check the log. Join, inspect inventory, and test the affected mechanism. Make a small recognizable world change, save, restart, and confirm that it remains. This checks recovery beyond a successful startup.
Record the hardware allocation, operating system, Minecraft build, Java runtime, plugin versions, test date, and person responsible for follow-up. Keep the reports and configuration differences beside that record.
Recheck after relevant software updates, new farms, plugin changes, or player growth. Scheduled restarts can serve an operational need, but they do not prove that a recurring performance fault has been fixed.
Common Questions About Low Minecraft TPS
Why is TPS low when CPU usage looks low?
The CPU display may average several cores while the tick thread is constrained. CPU quotas, waits, and pauses can also delay progress. Compare the profile with the host’s resource measurements.
Can a Minecraft server lag at 20 TPS?
Yes. Average TPS can hide brief slow ticks. Chunk delivery, connection delay, or client rendering can also cause poor play. Check the metric that matches the symptom.
Will more RAM fix low TPS?
It can help when memory pressure causes the delay. It will not remove expensive plugin logic or excessive simulation work. Check pause and memory-limit evidence before changing the allocation.
Which anti-lag plugin should I install first?
Start with measurement. Paper already bundles Spark on supported modern releases. Add a behavior-changing plugin only when it addresses a measured cause and passes your gameplay checks.
Does chunk pre-generation fix every TPS drop?
No. It moves terrain generation to a planned period. Existing chunks still need loading, and entities, plugins, saves, and simulation still require resources.
What should I send hosting support?
Send the exact software versions, incident timestamps and time zone, workload description, profiler report, recent changes, and relevant logs. Remove secrets before sharing. Include any visible CPU limits or memory failures.
Before applying the tested change to production, confirm that you have captured the incident, checked one cause at a time, compared matching workloads, tested gameplay and saving, proved restoration, and assigned a maintenance owner.
If the evidence points to an infrastructure limit, request a dedicated game server configuration review from Atal Networks. Share your workload, player region, capacity target, profiler evidence, and recovery requirements so the discussion starts with the conditions your server must handle.