This guide exists to help a specific kind of server owner: the one whose hardware is fine, whose plugin list is not obviously broken, and whose TPS still collapses once sixty players log in. When we open a profiler on a server like that, the top of the stack is usually not chunk generation and it is rarely the nether. It is a pile of entities that nobody has counted in two years.

Everything below comes from a controlled bench run rather than a guess. The test host was an Intel Core i5-13400F with 16 threads, 14 GB of RAM, Ubuntu 26.04 and OpenJDK 25.0.4.1, running Paper 26.2 build 129 with -Xms2G -Xmx4G -XX:+UseG1GC, over 22,801 pre-generated chunks. No players were connected, and a 240×240 area was force-loaded so the only variable was entity count. Numbers are medians of ten samples from tick query output.

The result that reframed how we think about mob lag: 2,000 villagers cost 113.8 ms per tick and dropped the server to 8.79 TPS, while 5,000 AI zombies cost 28.5 ms. A trading hall is roughly four times more expensive than a zombie farm of similar population. If your lag hunt has been focused on mob farms, this article will move your attention somewhere less glamorous.

Why entity count matters more than mob type

A server has a fixed amount of main-thread time. At 20 TPS the whole tick gets 50 ms, and everything competes for that slice: chunk ticking, block updates, redstone, hopper transfers, player movement and entities. Entities are the part most owners underestimate because they stay invisible in-game until you look for them.

Cost is not linear in a friendly way either. Doubling entity count roughly doubles cost until you cross the tick budget, and then TPS falls and players rubber-band on top of everything else. The no-AI zombie run shows the shape: 1,000 zombies added 7.7 ms, 5,000 added 22.1 ms, and 20,000 added 120.6 ms, where the server fell to 8.25 TPS.

The takeaway is an entity budget. Decide roughly how many ticking entities your hardware can afford, measure what you have, and spend the budget where it produces gameplay. Mechanics are documented on the Minecraft Wiki entity reference, and the knobs live in the Paper world configuration reference.

How Minecraft actually ticks entities

Almost every fix below targets one of five things: whether an entity ticks at all, how far its brain runs, how much collision work it forces, how long it lives, and how many of them a plugin creates.

Entity ticking chunks and activation range

Paper does not tick every entity in every loaded chunk. It keeps a smaller active set and applies an activation range per entity category. Inside that radius the entity runs its full tick including AI; outside it, the entity is largely frozen. It stays in memory, keeps its data, and costs very little.

That is why an entity far from players is nearly free while the same entity in a force-loaded chunk is expensive forever. Spawn chunks, loader-held chunks and anything a plugin keeps alive pay the ticking price whether or not a player is nearby.

AI goals, pathfinding and collisions

An AI zombie costs more than a no-AI zombie because goal selectors run, the entity scans for targets, and once it decides to move it asks the pathfinder for a route. Pathfinding is the expensive part, followed by collision resolution and entity lookups. Open pens full of wandering mobs are worse than tightly packed ones because every mob can path somewhere.

Items, merging and despawn timers

Dropped items are their own category. Every item entity ticks its age, checks for a merge partner, tries to fall, and holds a slot in movement and collision passes. A farm dropping items into a hopper line that is briefly backed up leaves a carpet of entities on the floor. At 4.0 microseconds each, 5,000 items measured 20.7 ms for objects no player will ever pick up.

Why more RAM does not help

Entity ticking is CPU work on the main thread. Adding heap does not make goal selectors faster, reduce pathfinding calls or merge items. Extra RAM buys headroom before garbage collection pressure hurts, and with a sane G1 heap that is not your bottleneck. Our test server ran the whole suite in a 4 GB heap and still hit 8 TPS from entity cost alone.

The measured results

Every run used the same world, the same JVM flags and the same force-loaded area. The only variable was entity count and type.

Scenario	MSPT	TPS	Note
Idle (no entities)	0.6	20.0	Baseline for the whole suite
1,000 no-AI zombies	8.3	20.0	Cheapest mob per unit
5,000 no-AI zombies	22.7	20.0	Still comfortable
10,000 no-AI zombies	48.5	20.0	At the edge of the tick budget
20,000 no-AI zombies	121.2	8.25	Tick budget blown
2,000 AI zombies	19.1	20.0	AI roughly doubles per-entity cost
5,000 AI zombies	28.5	20.0	AI scales worse than count
10,000 armor stands (marker, no gravity)	19.2	20.0	Cheap each, deadly in bulk
5,000 dropped items	20.7	20.0	Farm overflow territory
2,000 villagers	113.8	8.79	Most expensive per entity by far

Clearing every entity afterwards returned the server to 0.6 ms, which proves nothing else in the world was contributing measurably. It also shows the limit of the test: a 240×240 force-loaded area with no players isolates entity cost. A real server adds player movement, chunk sending, redstone, hoppers and plugin listeners, so your absolute numbers will be higher and your safe entity ceiling lower. Use the shape of these results, not the exact values.

Cost per entity: villagers are the outlier

Subtracting the 0.6 ms idle baseline and dividing by entity count gives a rough per-entity cost. Treat these as order-of-magnitude figures, since cost depends on what each entity is doing.

Entity type	Test size	MSPT	Approx. cost each
No-AI zombie	20,000	121.2	4.4 – 6.0 us
AI zombie	5,000	28.5	5.6 – 9.3 us
Armor stand (marker, no gravity)	10,000	19.2	1.86 us
Dropped item	5,000	20.7	4.0 us
Villager	2,000	113.8	~56.6 us

One villager costs roughly the same as nine to twelve no-AI zombies. That is the most useful number in this article. It comes from the villager brain: POI and workstation lookups, gossip and reputation handling, restock scheduling, breeding checks and pathfinding to beds and workstations all run on the main thread. A hall with 200 villagers is the computational equivalent of a 2,000 mob farm.

There is a second, hidden cost to mass entity operations. Killing 2,000 villagers in one event wrote 2,002 journal lines and 498,607 bytes of the message Villager was killed into the log. That is roughly half a megabyte of synchronous logging during one tick spike. If you do bulk cleanup, filter death messages out of your log pipeline first, or raise the log level so the kill notification does not flood disk I/O while the server is already struggling.

How to count what you actually have

Measure first. Every fix below is guesswork until you know the composition of your entity population. Three tools cover almost everything.

spark

The spark profiler tells you whether entity ticking is genuinely the top cost or whether you have been blaming mobs for a plugin problem. Run it during the actual problem window with players online; a profile from an empty server tells you the truth about an empty server and nothing else.

/spark profiler --timeout 60
/spark profiler --only-ticks-over 50
/spark tps
/spark health

Tick timing

Tick query reports median, percentile and worst-case tick durations over recent ticks. Take it before and after every change, at least three samples, and write the numbers down.

/tick query
/tick query report

Vanilla commands for counting

You do not need a plugin to count entities. An execute if entity test returns the number of matched entities as its result, capped by limit, so you can store it in a scoreboard objective and scope it with distance.

/scoreboard objectives add counts dummy
/execute store result score #villagers counts run execute if entity @e[type=minecraft:villager,limit=2000]
/scoreboard players get #villagers counts
/execute store result score #items counts run execute if entity @e[type=minecraft:item,limit=20000]
/scoreboard players get #items counts
/execute if entity @e[type=minecraft:armor_stand,distance=..240,limit=1]

Swap the type for minecraft:armor_stand, minecraft:item or minecraft:experience_orb, and add distance=..240 to scope a count to the region you care about. For a spatial check, /execute as @e[type=villager,distance=..32] run say found shows how tightly stacked a hall is. Before blaming spawn limits, cross-check the mob spawning rules to confirm natural spawning is even contributing.

The prioritized fix list, cheapest first

Work down this list in order. Each step is cheaper in effort and risk than the one below it, and each step gets a measurement before you move on.

1. Remove or merge dropped items

Items are the best ratio of pain removed to risk taken. Look for farms whose output backs up, then tighten the defaults in your Paper world configuration.

• Lower item despawn time so useless drops vanish faster than the default five minutes.
• Increase the item merge radius so nearby stacks consolidate instead of ticking separately.
• Set per-type despawn overrides for bulk drops such as cobblestone and netherrack.
• Fix the source: add overflow voiding, buffer chests or comparators so a backed-up hopper never becomes a floor full of entities.

Merging changes where items visually sit and can break farm designs that rely on precise item positions, so test one farm at a time.

2. Cap armor stands and holograms

At 1.86 microseconds each, armor stands look free until you have ten thousand, which measured 19.2 ms. Holograms are the usual culprit: each line of floating text is often its own invisible armor stand, so a twenty line leaderboard is twenty entities per location, plus whatever the plugin does with them every tick.

• Count armor stands first with the scoreboard method above, then hunt the coordinates.
• Consolidate holograms and shop signs; one display is better than five stacked stands.
• Turn off armor stand collision lookups in Paper’s world defaults if your stands are decorative.
• Delete leftovers: old event displays, dead shop holograms, test rigs from former staff.

3. Reduce villager count and consolidate trading halls

This is where most SMPs find their real lag. Villagers cost more than any other common entity, and servers accumulate them because every player builds a private hall and then a shared hall appears at spawn. Audit for duplicate halls, abandoned bases and villagers roaming free in villages nobody uses.

• Keep a small number of dedicated halls rather than one per player.
• Confine villagers to a compact footprint so they sit in one or two ticking chunks instead of a dozen.
• On Paper, disabling ticking for villagers outside the activation range removes most of the cost of a large hall when nobody is near, but those villagers will not restock, breed or work until a player comes close.
• Free-roaming villagers are the worst case: they path constantly, spread out, and no config can reason with them.

Be honest with players about why you are consolidating. A hall of 40 villagers with clear signage beats 400 in basements nobody visits.

4. Tune entity activation range and spawn ranges

Paper exposes per-category activation ranges for animals, monsters, raiders, misc, water, flying monsters and villagers, plus a switch for ticking inactive villagers. Every key is documented in the Paper world configuration reference.

• Reduce monster and animal activation range moderately, not drastically. Mobs outside the range freeze, so farms relying on distant movement will slow down.
• Keep villager activation range generous if trading matters to your economy, and cut villager count instead.
• Lower per-player mob spawn limits and spawn range to shrink the background population on servers with players spread across the map.
• Reduce spawn limits in small steps; each step cuts natural spawn rates and therefore mob farm output.

Every setting here trades gameplay for performance. Change one, restart, measure for at least ten minutes with realistic player load, and keep notes. The broader Paper configuration reference is worth reading end to end before touching defaults.

5. Only then consider nerfing spawner mobs

Paper can disable AI on mobs that come out of spawners. It is a large saving and a blunt instrument: those mobs will not chase or navigate, and farms that depend on movement break. Enable it only when your profile or counts prove spawner output is the cause, and tell players before you do.

6. Audit plugins that spawn or tick entities

A plugin running a task over every entity each tick can cost more than the entities themselves. Look for plugin frames in the profiler under the entity and scheduler sections, and check anything managing holograms, mob stacking, custom mobs, pets, crates or leaderboards. On servers with dozens of plugins, a trim pass is often the biggest single win.

Pros and cons of aggressive entity limits

Entity limits work. They also change how the game plays, and players notice fast. Here is the honest trade.

Pros

• Immediate tick time reduction with no new hardware and no migration.
• Predictable capacity: a fixed entity budget means performance does not degrade as players build.
• Cheap to reverse if you keep notes and backups.
• Forces better world design, which usually improves the player experience too.

Cons

• Farms lose rates, sometimes a lot, and players will file tickets about it.
• Mobs freezing outside activation range can look like bugs and can break vanilla mechanics or datapacks.
• Aggressive settings mask the real problem if a plugin is actually at fault.
• Villager and iron farm behaviour depends on ticking, so over-tuning quietly breaks an economy.

Common mistakes and expert tips

• Killing every entity without fixing the spawn source. The population returns in hours, and you also paid for a tick spike and half a megabyte of death logging.
• Setting activation range to 1 as a quick fix. Everything stops moving, players call it broken, and you learn nothing about your cost distribution.
• Forgetting persistent mobs. Nametagged pets, mobs with persistence flags and anything in a force-loaded chunk ignore despawn logic; count them separately.
• Ignoring item entities from farms. Owners blame mobs while a hopper line silently accumulates thousands of items on the floor.
• Measuring during a spawn burst. Take medians over at least ten samples; one tick query during a spawn wave tells you nothing useful.
• Changing five settings at once and then guessing which one helped.
• Testing with no players online and assuming the result transfers. Add player load before drawing conclusions.
• Skipping world pre-generation and blaming mobs for what is really chunk generation.

A workflow that works: baseline with spark and tick query, fix items, measure, fix stands, measure, fix villagers, measure, then tune activation and spawn ranges one key at a time. Do not raise chunk throughput before you have cut entity load, or you will spend a week chasing the wrong thing, as our view distance and simulation distance breakdown explains.

Frequently Asked Questions

The bottom line

Mob lag is almost always an accounting problem, not a hardware problem. Count what you have, spend your entity budget deliberately, and start with the cheapest wins: items on the floor, then armor stands and holograms, then villagers. Only after those are clean does it make sense to touch activation range, spawn limits or spawner nerfs, because those settings change the game your players actually play.

Do it in one sitting. Take a tick query baseline, run the scoreboard counts, write the numbers down, apply one change, and take the baseline again. You will usually find that a fifth of your entities were producing none of your gameplay. If entity load turns out not to be the ceiling, look at chunk generation and plugin overhead next.

Related reading on this site: [View Distance vs Simulation Distance: Cutting Chunk Lag for Real], [Understanding Chunk Loaders and Their Performance Cost], [How to Pre-Generate Your Minecraft World with Chunky], and [How to Audit and Trim Plugins to Reduce Server Lag]. If you run a busy SMP and want a second opinion on your numbers, publish your spark link and ask; the community is good at spotting what a profile hides.