How to Fix Low TPS on a Minecraft Server

A server can show 20 TPS at spawn, then collapse the moment five players fly into new terrain or a farm starts running. That is the frustrating part of Minecraft performance: the problem is rarely just "not enough RAM." If you are figuring out how to fix low TPS, start by treating it like a tick-time problem. Find what is consuming each 50-millisecond tick, reduce the work, then make sure your hardware can keep up with the world you want to run.

TPS means ticks per second. Minecraft targets 20 TPS, which gives the server 50 ms to process each tick. At 15 TPS, redstone clocks slow down, mobs react late, and players feel rubber-banding even when their ping is fine. The useful companion metric is MSPT, or milliseconds per tick. Lower is better. Anything consistently above 50 MSPT means your server cannot maintain 20 TPS.

Diagnose before you change things

Do not start by randomly deleting plugins or doubling your RAM allocation. A server can have plenty of unused memory and still lag because one CPU core is pinned by entities, chunk generation, or a badly behaved mod. Check the pattern first.

If TPS falls only while players explore, terrain generation is the likely culprit. If it drops in a specific base, inspect mobs, hoppers, item piles, redstone, and modded machines. If it degrades after several hours online, look for a memory leak, an oversized world, or entities accumulating in unloaded-looking areas.

A profiler gives you the answer faster than guesswork. On Paper or Purpur, use a profiler such as spark to capture a report during active lag. On Forge or Fabric, use the profiler supported by your loader and modpack. Run it while players are doing the activity that causes the slowdown, not while everyone is standing at spawn.

Pay attention to these common tick consumers:

• Entity ticking, especially dense animal farms, villagers, item drops, and armor stands.
• Chunk generation when players use elytra, teleport widely, or join an unexplored map.
• Tile entities and machines in modpacks, including pipes, cables, storage systems, and auto-crafting setups.
• Plugins that scan the world, query large databases, update scoreboards too often, or run heavy tasks on the main thread.
• Redstone clocks and hopper networks that run every tick, even when nobody is using them.

The goal is not to blame players or remove every fun feature. It is to identify the one or two workloads taking the biggest share of the tick. A 300-villager trading hall is a different fix from slow chunk generation, and both need a different fix from a broken plugin task.

Fix the world load first

Entity-heavy builds are the most common TPS killer on survival servers. Start with limits that players can understand. Reduce the number of villagers in a trading hall, keep animal breeders under control, and use item cleanup rules carefully. Clearing every dropped item every few minutes may protect TPS, but it can also delete loot players reasonably expect to collect.

Hoppers deserve special attention. A large hopper line checks inventories continuously, and hundreds of them add up quickly. Replace unnecessary hopper chains with water streams, minecarts only where they are truly useful, or smarter storage solutions. Cover hoppers with composters or other containers when appropriate to reduce their inventory checks.

For Paper and Purpur servers, tune view distance and simulation distance separately. View distance controls what players can see. Simulation distance controls which nearby chunks actively process entities, redstone, and crops. Lowering simulation distance from 10 to 6 often cuts tick work significantly without making the world feel small. The right value depends on your player count and gameplay style. A quiet whitelist SMP can run higher settings than a public server with 80 players online.

Pre-generating your world is another high-impact move. New chunks are expensive because the server must create terrain, structures, lighting, and population data. Generate the area players will realistically use before opening the server or before a major event. This turns random exploration spikes into a one-time preparation task. Keep in mind that a huge pre-generated world also needs more disk space and backup capacity.

Audit plugins, mods, and server software

Running the right server jar matters. For plugin servers, Paper is a strong baseline, while Purpur gives admins more gameplay and performance controls. Vanilla is appropriate when you need strict vanilla behavior, but it leaves fewer optimization options. Do not install Paper-only plugins on a server that needs Forge mods and expect stable results.

On Fabric and Forge, performance mods can help, but compatibility comes first. Add them one at a time, restart, and test the workflows your players use. Stacking every optimization mod from a list can create crashes, broken rendering assumptions, or strange world behavior that costs more time than it saves.

Plugins and mods should earn their place. Disable anything unused, update actively maintained projects, and check changelogs after a Minecraft version upgrade. A scoreboard plugin refreshing every tick for every player may look polished, but it can be expensive on a busy server. The same goes for map renders, anti-cheat scans, cosmetic particle systems, and economy plugins with inefficient database calls.

If a profiler points to a specific plugin or mod, confirm it before removing it. Test in a copy of the server, check its configuration, and see whether an update fixes the issue. For community servers, explain the change before you alter a popular feature. Performance is important, but so is preserving the gameplay your players joined for.

Give Minecraft the hardware it actually uses

Minecraft's main tick loop is heavily dependent on single-core CPU speed. More vCPUs can help with supporting tasks, but they do not automatically fix a main thread that is taking 90 ms per tick. This is why cheap, oversold hosting can struggle even when the plan advertises generous RAM.

Fast Ryzen and EPYC infrastructure, high-frequency CPU performance, and NVMe Gen4 storage make a practical difference. CPU speed handles ticking, while fast storage helps with chunk loading, world saves, backups, and restarts. DDoS protection also matters for public servers because a network attack should not become your community's Friday-night outage.

RAM still matters, especially for modpacks, but allocating more than the server can use is not a free performance upgrade. Too little RAM causes garbage collection pressure and crashes. Too much can lead to longer garbage collection pauses. A small Paper SMP may run comfortably with 4-6 GB, while a large Forge pack can need 8-12 GB or more depending on mods and player activity. Watch actual usage instead of choosing a number based on the biggest plan available.

Use sensible JVM flags for your Java version and server type, but do not expect flags to rescue an overloaded world. Modern Java and current server software already handle many defaults well. The winning order is: fix the workload, tune the settings, then size the hardware correctly.

Keep TPS stable after the fix

A server that reaches 20 TPS once is not necessarily healthy. Test during peak conditions: players exploring, farms running, mobs loaded, and scheduled backups or restarts happening normally. Track MSPT after adding a new plugin, opening a new dimension, or updating a modpack. Small checks prevent one change from becoming a week of player complaints.

Backups are part of performance management, too. Before changing configs, removing mods, or trimming entities, create a backup you can restore. It gives you room to test confidently instead of gambling with a world your community has spent months building.

If you have optimized the obvious problems and the main thread is still maxed out, it may be time to move rather than keep compromising the server. Elysium is built for this exact situation, with Minecraft-focused plans, fast CPU performance, NVMe storage, automatic backups, and support that understands the difference between a plugin issue and a tick bottleneck.

Your players do not care whether the fix came from a better simulation distance, a rebuilt farm, or faster hardware. They care that combat feels responsive, chunks load when they fly, and their builds work when the server is busy. Start with one profiler capture during real lag, make the highest-impact change, and let the numbers guide the next move.