How to Optimize a Modded Minecraft Server (Stop the Lag)

First, understand: TPS, MSPT and the two families of lag

The server aims for 20 ticks per second (TPS), one tick every 50 ms. MSPT (milliseconds per tick) measures how long each tick actually takes: as long as it stays under 50 ms, the server holds 20 TPS and all is well. TPS is therefore a late indicator — it only drops once the budget is blown — while MSPT shows the remaining headroom: a server at 20 TPS with 45 ms MSPT is one mob farm away from collapse. On Forge and NeoForge, /forge tps gives a first per-dimension overview; Spark does much better.

Also separate server lag from everything else: if mobs freeze and mined blocks reappear, it is the server tick (this guide). If your frame rate stutters while the world runs normally, it is the client — see our performance mods guide. If your actions respond late while TPS is fine, it is the network or the player’s connection.

Diagnose with Spark, step by step

Spark (Fabric, Forge, NeoForge, Paper) is the reference profiler: it records what the server actually does for a few minutes and produces a readable report in the browser. Here is the full procedure.

1. 1

   Install Spark on the server

   Download the Spark build matching your loader from Modrinth, drop it into the server’s mods folder and restart. The commands require operator permissions.

2. 2

   Record TPS and MSPT

   Run /spark tps: it prints average TPS and MSPT over several time windows. A median MSPT under 35 ms is comfortable; above 50 ms, the server is falling behind. Write these numbers down — they are your baseline.

3. 3

   Run a profile under load

   At peak hours — lag is diagnosed while it happens — run /spark profiler start --timeout 300: the profiler records for five minutes, stops on its own and prints a link to the report.

4. 4

   Read the report

   Open the link in a browser and expand the call tree following the highest percentages. Look at which dimension, then which system (entities, block entities, chunk generation) dominates, and above all which mod shows up in the method names: that is your likely culprit.

5. 5

   Cross-check server health

   /spark health summarizes memory, garbage collection time and CPU load. Frequent GC pauses point to a RAM or Java flags problem; a single CPU core pinned at 100 percent means the hardware is the ceiling.

6. 6

   Fix one thing, measure again

   Apply a single fix — a setting, a mod, dismantling a farm — then run another profile under the same conditions. It is the only way to know what actually worked.

The server.properties settings that actually matter

Two lines outweigh everything else. view-distance sets the radius of chunks sent to players: 6 to 8 is plenty on a modded server (default 10); beyond that, memory and bandwidth costs climb fast. simulation-distance sets the radius where the server keeps the world alive — entities, crops, machines: this is the one that costs tick time. Set it to 4-6; below 4, mob farms and some redstone contraptions stop working, so warn your players.

The winning combination for most modded servers: view-distance=7, simulation-distance=5. Players see far, the server only simulates what is near. Round it out with sync-chunk-writes=false (asynchronous chunk saving, a real gain on slow disks) and, if your pack allows it, slightly lower mob spawn caps in the relevant mod configs. Validate every changed setting with the next Spark profile.

Pre-generate the world with Chunky

Chunk generation is the most expensive job on a young modded server: every exploration trip triggers biomes, structures and ores from dozens of mods at once. The fix is to pay that cost up front, with no players online. Chunky (Fabric, Forge, NeoForge, Paper) handles it: /chunky radius 3000 then /chunky start pre-generates a 3,000-block radius around spawn — expect several hours depending on pack and machine, ideally overnight or before launch day.

Pair it with a world border (/chunky border, or your pack’s WorldBorder mod) at the same radius: without a limit, the first player who sets off with an elytra will recreate generation lag forever and balloon the save file. Pre-generate the Nether too (an eighth of the radius covers the same logical area), and widen the border later if the population grows.

Install the server performance mod stack

With the settings in place, performance mods win back the rest: Lithium trims every tick, C2ME parallelizes chunks, Krypton streamlines networking, FerriteCore cuts memory, ModernFix fixes and speeds up. All of them are server-side only — your players install nothing — and available on both Fabric and NeoForge in 2026.

The detailed list — each mod’s role, exact loaders, legacy Forge equivalents and compatibility traps — has its own dedicated guide on performance mods, linked at the bottom of the page. Keep the golden rule: add mods one at a time and validate each with a Spark profile, because two mods touching the same system can cancel each other out or crash.

Hunting the gameplay causes

On a modded server that has been running for months, lag rarely comes from the tech stack: it comes from what players built. The Spark report will tell you which of these families dominates on your map.

• Oversized mob farms: hundreds of living entities pathfinding around the clock. Enforce automatic kill mechanisms and reasonable per-player caps.
• Hopper carpets: every hopper checks its inventory every tick. Replace hopper lines with the pipes, belts or conduits from your tech mods — incomparably cheaper.
• Dropped items: an overflowing farm or an unclaimed death leaves thousands of item entities. Shorten their lifetime in the configs or run a periodic clear-lag mod.
• Forgotten chunk loaders: every force-loaded area is simulated continuously, player present or not. Audit chunk loaders regularly and cap them per player.
• Block entities in bulk: thousands of active machines, chests and cables weigh on the tick even when idle. Encourage compact factories — a few fast machines rather than hundreds of slow ones.
• A forgotten dimension: Spark’s per-dimension breakdown sometimes reveals that a mining world or a mod dimension concentrates the lag — usually a farm or chunk loader nobody thought to look for there.

When it is the hardware or the host, and how to tell

If, after settings, pre-generation, mods and a full cleanup, MSPT stays high and the Spark profile shows no obvious culprit, the server simply lacks power. Minecraft’s main tick loop is still single-threaded: what matters is per-core CPU performance, not core count. A heavy pack (400+ mods) wants a recent high-frequency CPU, 8 to 12 GB of RAM dedicated to the server and NVMe storage — and be wary of shared hosting plans sold by the gigabyte: RAM never substitutes for CPU.

Watch out for the opposite reflex too: over-allocating RAM lengthens garbage collector pauses and creates a telltale periodic stutter. Allocation guidelines and the right Java flags (ZGC or G1 depending on heap size) are covered in our dedicated guides, linked below. Finally, if /spark health shows network spikes or noisy neighbors on a shared plan, moving to a dedicated server or a well-specced VPS fixes what no mod can.