Why Is My Minecraft Server Lagging? A TPS, MSPT and spark Troubleshooting Guide

“The server is lagging” can describe three different failures: a player's computer struggles to draw the scene, the connection delivers updates late, or the server cannot keep up with the world. Buying more RAM before identifying which one you have is an expensive guess.

This guide follows a diagnostic workflow for a Java server, with Paper and spark as the worked example. It is intended for owners who can read logs and run administrative commands. Players can use the first section to write a useful report. The example measurements below are invented to explain decisions; they are not benchmarks or promises about a hosting plan.

First, separate FPS, network delay and tick lag

These are starting hypotheses, not diagnoses. One crowded spawn can stress a player's renderer and the server simultaneously. Ask two testers in different locations what they observe. Record the time of the complaint and whether it affected everyone. “At 19:42, three players froze while someone explored new terrain” is a much better lead than “laggy all evening.”

If you are a player, report the server name, approximate time, activity, location and whether reconnecting changed anything. Do not paste passwords, session tokens or your whole configuration. If you are comparing servers in the Java server directory, remember that a player-count snapshot is not a performance benchmark.

Read TPS and MSPT together

At Minecraft's usual 20-tick-per-second rate, a tick has a 50-millisecond budget. TPS describes how many ticks are completed; MSPT describes how long tick processing takes. A server can show 20 TPS while having very little spare capacity, and a short spike can be hidden by a longer average. The spark explanation of TPS and MSPT covers the relationship and the meaning of its reported statistics.

Use the same observation window when comparing results. A quiet morning sample cannot validate a change intended for a crowded evening. Keep player count, loaded locations, activities and software versions beside each measurement. If those conditions differ, describe the difference rather than presenting the numbers as a clean before-and-after result.

Capture the problem while it is happening

Paper bundles spark from 1.21 onward. On another platform, check the supported installation rather than dropping a random plugin into a mods directory. Start with a short health check and a profile that covers the activity players reported:

/spark tps
/spark profiler start --timeout 600

The timeout example collects ten minutes. Run it while the troublesome workload is present, then save the report URL and your notes. From a server console, commands generally omit the leading slash. Use the command help for your installed spark build if a flag is rejected. Do not keep restarting the server in the middle of the sample.

1. Write down the server build, Java runtime and relevant plugin or mod versions.
2. Record the number of players and the activity you intend to observe.
3. Start the profile, reproduce that activity and note when symptoms occur.
4. Save the report, the startup log and a short excerpt around any errors.
5. Describe what changed recently: a plugin update, new farm, world import, host move or configuration edit.

Review a report before sharing it publicly. Diagnostic output can expose infrastructure and configuration details. Send it through the support route you intend to use, with only the context needed to investigate. A screenshot of one percentage is usually less useful than the report and a description of the workload that produced it.

Read a profile as a lead, not a verdict

Begin with the work relevant to the symptom. Expand the expensive branches and inspect what they contain. A plugin's name appearing in a report does not automatically make it the root cause: it may be responding to unusually many events or calling another expensive system. Likewise, time under world processing is a category that needs another question, not a complete explanation.

Ask what the server was doing during those samples. Were players generating terrain, moving through an entity-heavy area, executing a command repeatedly or triggering a large edit? Compare that story with the report. If they do not line up, collect a better sample before making a destructive change.

A useful experiment has a narrow claim: “This particular menu action coincides with a spike, so we will reproduce it on a copy with that feature disabled.” A weak experiment says “This plugin appears somewhere near the top, so we will remove it and see what breaks.” Keep dependencies and stored data in mind before removing anything.

If the problem is a spike, stop averaging it away

A long quiet profile may dilute a rare stall. The spark lag-spike guide describes tick monitoring and profiling slow ticks. One useful observation command is:

/spark tickmonitor --threshold-tick 50

That threshold is a diagnostic example for the usual tick budget, not a target you must force every workload under by deleting gameplay. Note the timestamps of warnings and compare them with player actions and logs. If the lag occurs only during a scheduled job, capture that job; do not conclude the problem disappeared because a different ten-minute window was quiet.

For repeatable spikes, agree on a test action and a stop condition. Have one person reproduce it while another watches measurements. Stop if the experiment risks player data or makes the public world unusable. Use a copy for large edits, migrations and deliberate stress tests.

When exploration is the trigger, investigate terrain work

If the server is smooth in established areas but stalls when players explore, terrain generation is a plausible lead. Compare an already explored route with a genuinely new one under similar conditions. Also check disk space and host resource limits. Do not assume every teleport delay is generation; a destination plugin or storage problem may be involved.

Chunky can pregenerate a chosen region. Plan its world, shape, center and radius before starting, and check available storage. For example, a deliberately small trial in a world actually named world could use:

chunky world world
chunky shape square
chunky center 0 0
chunky radius 500
chunky start

These are console commands for an example selection, not a recommendation to run work immediately on a busy server. Back up first, use a maintenance window and confirm your installed command syntax. Keep the radius modest until you understand generation speed and disk growth. In a comparable shape, doubling the radius roughly quadruples the area; a seemingly small number change can create much more work.

Pregeneration moves some work earlier. It does not remove the cost of ticking entities, running plugins or loading and saving active areas. Decide whether to set a suitable world border separately; generating a region alone does not establish your community's exploration rules.

When farms or busy areas are involved, measure their activity

Do not begin by deleting every animal or dropped item. First identify the loaded area, the relevant processing category and the activity that makes it expensive. Ask the builder how the system works and how it can be paused. A reversible pause gives you a better comparison than an irreversible purge.

Useful checks include collection overflow, constantly running clocks, dense entity concentrations and repeated plugin actions attached to those entities. These are investigation categories, not a universal blacklist. Test a smaller active footprint or a paused subsystem, then compare the same activity again. If you establish a rule, explain the measured issue and provide players with a practical alternative.

Changes to simulation, activation and spawning can alter farm behavior. Record the exact setting and original value, read the documentation for your server build, and test the gameplay consequence. “Better TPS” is not an adequate result if a core feature silently stops working for players.

Compare fixes by the evidence they require

Avoid installing several “lag fix” plugins together. That creates overlapping behavior and makes attribution difficult. Keep your plugin stack understandable; the plugin selection and testing guide explains how to introduce components deliberately. Never download an unverified replacement JAR merely because it promises a dramatic percentage improvement.

Use a change log and a rollback test

Keep one row per experiment. Write the hypothesis before editing the configuration, because otherwise it is easy to redefine success after seeing the result. Record enough detail that another administrator can restore the original setting without relying on your memory.

Be careful with data-changing upgrades. Restoring an older plugin JAR is not necessarily a rollback if the new version already migrated its database. Keep the matching data and configuration backup. Test that recovery on a copy rather than discovering during an outage that your archive contains only the world folder.

For an SMP, include normal play in the acceptance test: claims, inventories, shops, portals and restarts. The SMP setup guide provides a broader launch checklist. For crossplay, repeat the test with both editions using the crossplay acceptance matrix; a server change that helps Java players may expose a separate client compatibility problem.

Send support a report they can investigate

Include the exact symptom, the time and time zone, the affected players or locations, the software build, recent changes and a profile captured during the problem. Add what you already tried and whether you could reverse it. Use the host's private support channel for infrastructure-specific details.

Do not present “CPU is only 30%” as proof that processing capacity is irrelevant. Aggregate utilization can hide constraints in the work that matters to the game. Equally, do not diagnose a memory leak from one rising memory graph. Describe the observation and let the time series, profile and workload establish the cause.

Minecraft lag troubleshooting FAQ

Does 20 TPS mean nobody can experience lag?

No. Client rendering, network problems and short spikes can still affect play. Read tick duration and the symptom together instead of relying on one average.

Will allocating more RAM fix low TPS?

Only if memory pressure is part of the problem. Extra memory does not make an expensive plugin action cheap or repair a bad connection. Measure before changing the allocation.

Should I profile an empty server?

An idle baseline can be useful, but it does not reproduce a problem caused by players exploring or using a farm. Capture the workload that triggers the complaint.

Should I install spark separately on Paper?

Current Paper builds in the documented bundled range already include it. Check your exact build and the Paper profiling instructions before adding another copy.

Is clearing entities a safe first fix?

It can destroy player work and erase the evidence. Identify the expensive activity and test a reversible change first. Use destructive cleanup only as a deliberate, communicated operation with recovery planning.

Can a server-list page tell me which host will never lag?

No. Workload, geography, configuration and resource allocation all matter. Use listings to find communities and their stated features, then evaluate the actual experience under the conditions you care about.

Technical references reviewed October 22, 2026. Commands and examples are a diagnostic starting point; no production server was stress-tested for this article.