Minecraft villager and mob farm lag

On most survival servers that have been running for a few months, the largest single line in a profiler is not a plugin. It is villagers - two hundred of them in a trading hall, a breeder that nobody turned off, and an iron farm on every second base - followed closely by the mob farms built underneath them. A villager costs far more per tick than a zombie or a cow because it runs a full "brain": job site searches, bed searches, gossip, panic checks and golem summoning. The fix is not to ban villagers. It is to count them, keep each one in a cell where it cannot path anywhere, cap breeders, tune three or four Paper and Spigot settings, and publish farm rules before people build, not after.

This guide assumes Paper or a fork of it. The general distance and spawning settings are covered in Paper optimisation; here we go deeper on the two entity groups that cause most of the trouble on mature servers, and on the rules that stop the problem growing back.

Why a villager costs more than any other mob#

Since the village rewrite in 1.14, every villager runs on the same AI system as the newer mobs: a set of sensors that look at the world, memories that store what they found, and behaviours that act on those memories. Most mobs have a handful. Villagers have dozens, and several of them are expensive.

• Point-of-interest searches. An unemployed villager, or one that has lost its job site, repeatedly scans the area for a free workstation, bed or bell. These searches walk the POI storage of nearby chunks. One villager doing it is nothing; a hall of fifty unemployed villagers doing it every few seconds is a visible slice of the tick.
• Pathfinding. Every time a villager decides to go to work, to bed or to the bell, it computes a path. In an open room, paths are long and frequently recalculated. In a one-block cell, the path is one step or impossible, which is much cheaper.
• Gossip and golem logic. Villagers share reputation data with each other and check whether they should summon an iron golem. In an iron farm, that is exactly what you want, and it is constant work.
• Schedules. Villagers change activity through the day, and each change triggers new decisions.

A cow, by comparison, wanders, eats grass and occasionally breeds. On a profile, a thousand cows in a pen look bad mostly because of collisions; a few hundred villagers look bad because of their brains. That is the key distinction for everything that follows: villagers are expensive because they think, most other farm mobs are expensive because there are too many of them.

Count before you change anything#

Guessing which base is the problem is how admins end up deleting the wrong farm and losing a player. Measure first.

/paper entity list/paper entity list minecraft:villager/execute if entity @e[type=minecraft:villager]/mspt

/paper entity list prints entity counts by type across loaded chunks, and when given a type it lists the chunks holding the most of them, with coordinates. That is the single most useful command for this whole topic: it tells you that 140 of your 310 villagers are in one chunk at x: 1840, z: -620, and you can go and look. The /execute if entity form returns a count in vanilla terms and works on any server. /mspt tells you whether any of this matters yet - if the median is 15 ms, you have headroom and a long list of villagers is not an emergency.

Remember that these commands only see loaded chunks. A trading hall in a base whose owner is offline does not tick and does not show up. Check again when the server is busy, or after the owner logs in, before deciding a base is innocent.

Then take a profile. Reading a spark report covers the method; the lines to look for are villager behaviours and sensors (names such as acquiring a POI, the secondary POI sensor, nearest bed sensor) and the generic entity tick and pathfinding entries. If villager brain work is a few percent of the tick, leave the settings alone and focus on whatever is at the top of the report.

Trading halls and breeders, done cheaply#

The cheapest villager is one that is employed, locked in a one-by-one cell with its workstation in reach, and cannot see a bed it might want. A well-built trading hall is not a performance problem. A badly built one is the classic problem.

What makes a hall cheap:

1. One block per villager, floor and walls solid, workstation directly adjacent. The villager reaches its job without pathing anywhere.
2. Every villager employed. A villager that has lost its workstation (because someone broke it to reroll trades and forgot to replace it) searches for one constantly. Unemployed villagers and nitwits in cells should be sent to the breeder or removed.
3. No beds in range of the hall unless the design needs them. Beds give villagers another thing to search for and walk to.
4. No open space above or beside the cells. Gaps let villagers compute paths that go nowhere.

Breeders are the bigger risk, because they produce villagers forever. An automatic breeder with a food supply and beds keeps working while its owner is online, and anything it produces that is not collected sits in a holding area, idle and searching. A breeder should either feed straight into a hall that has a fixed number of cells, or be switched off once the hall is full. Ask builders to include an off switch - usually removing the food or the beds - and to use it.

Zombie curing for discounts is another source of villager churn. It is fine on its own; it becomes a problem when a cell block of half-cured villagers is left with zombies inside, because zombies in a loaded chunk keep pathing towards villagers they cannot reach.

Paper and Spigot settings for villagers#

Paper adds a set of villager controls on top of Spigot's activation ranges. The defaults below are what recent builds generate; keys move between versions, so search your own files before editing.

entity-activation-range:  villagers: 32  tick-inactive-villagers: true  villagers-active-for-panic: true  villagers-work-immunity-after: 100  villagers-work-immunity-for: 20  wake-up-inactive:    villagers-every: 600    villagers-for: 100    villagers-max-per-tick: 4

What each one does and what changing it costs:

tick-inactive-villagers: false is the strongest of these. With it, a villager outside the activation range of every player does nothing at all - no POI searches, no golem summoning, no restocking. The visible effect is that trading halls and iron farms only work while someone is standing near them, which is how most players use them anyway. The invisible effect is that a hall of two hundred villagers in an offline-ish base that is chunk-loaded by a neighbour stops costing anything.

Paper's own world config has two villager tick rates:

tick-rates:  behavior:    villager:      validatenearbypoi: -1  sensor:    villager:      secondarypoisensor: 40

The sensor rate is in ticks; raising secondarypoisensor to 80 or 100 halves or more the cost of the sensor that looks for secondary points of interest such as composters for farmers. validatenearbypoi at -1 means vanilla behaviour; setting a positive value makes the validation run less often. Both reduce how quickly villagers notice changes to their surroundings - a farmer takes slightly longer to find a newly placed composter - and neither breaks trading.

If you run Purpur, it adds a villager "lobotomise" option in purpur.yml that strips the AI from villagers that cannot move, which is precisely the one-block-cell case. It is effective and it changes behaviour in ways some trading halls rely on (lobotomised villagers restock differently in some versions), so read the current Purpur documentation and test on a copy. Purpur and Pufferfish covers whether switching forks is worth it in the first place. On plain Paper, plugins that do the same thing exist; they are blunt tools, and the settings above usually get you most of the way.

Mob farms and the mob cap#

Mob farms are a different kind of cost. A hostile mob farm works by spawning mobs in a dark area while every other spawnable space nearby is lit or unspawnable, then moving them to a kill point. The per-tick cost comes from three places: spawn attempts, the AI and movement of the mobs before they die, and the items and experience they drop.

The mob cap is what links one player's farm to everyone else. With Paper's per-player-mob-spawns (on by default), each player carries their own budget - monsters: 70 in bukkit.yml by default - and mobs near them count against it. That has three consequences worth understanding:

• Farms run faster when the cap is not full elsewhere. A player standing at a farm whose cap is filled by mobs in nearby caves gets fewer spawns in the farm. Players learn to light caves, which is fine.
• Named and persistent mobs count against the cap. A pen of name-tagged zombies or a collection of persistent mobs fills the cap permanently and kills the farm. It also costs ticks for nothing.
• Lowering the cap lowers farm output in proportion. Dropping monsters to 50 on a busy server is a legitimate trade, and it reduces every hostile farm by roughly the same fraction. Announce it.

Spawn attempts themselves run every tick by default. ticks-per.monster-spawns: 2 in bukkit.yml halves the attempts and is hard to notice in play. Spawners have a separate rate in Paper, tick-rates.mob-spawner: 1 in paper-world-defaults.yml; raising it to 2 halves the cost of every spawner-based grinder and slows them proportionally.

nerf-spawner-mobs: true in spigot.yml gives spawner mobs no AI. They still fall and can be pushed by water, which is how most spawner grinders move them, so many designs still work. Designs that rely on mobs walking or pathing towards a target do not. This is a farm-rules decision, not a silent tweak.

Animal pens, cramming and mobs that never despawn#

Passive animals are the other half of the problem, and they are worse in one way: bred animals never despawn. A cow farm that breeds every five minutes and never culls grows until something stops it.

/gamerule maxEntityCramming

maxEntityCramming defaults to 24: when more than that many mobs share a block space, they take suffocation damage. It is a vanilla safety valve, and some farms use it on purpose as a kill mechanism. Raising it to stop a farm killing animals is a bad idea - collision checks scale badly as entities pile up, which is why entity collision shows up so prominently in pen-heavy profiles.

Paper's collisions.max-entity-collisions in paper-world-defaults.yml (default 8) limits how many collisions one entity processes per tick, which already blunts the worst case. What it cannot do is stop a player keeping 600 chickens. The workable rules are social:

• A per-base animal limit - many servers use something like 50 of each species in one area - with automatic culling designs encouraged.
• Chicken farms must kill adults or use cooking designs, not accumulate.
• Breeding is fine; storing hundreds of breeding stock is not.

For enforcement, chunks.entity-per-chunk-save-limit in paper-world-defaults.yml caps how many of a given type are saved per chunk. It is designed as a protection against chunks that cannot load, not as a farm limit, and it silently deletes the excess when the chunk saves. Use it with generous values for projectiles and experience orbs; do not use it to police cows unless you have told everyone.

Iron, raid and gold farms#

These three are worth singling out, because they are the farms that get blamed most often and are not always guilty.

Iron farms need villagers that are panicking or have gossiped and have not seen a golem recently. Modern designs use a small number of villagers - three is common - and a zombie to scare them. A single well-built iron farm is cheap. Twenty iron farms on one server, each with its own villagers and zombie, multiply the cost by twenty, and the golems they produce become item drops that need collecting. If iron is abundant, ask whether every base needs its own.

Raid farms are expensive when active: raids spawn waves of illagers that path long distances, which is why entity-activation-range.raiders is higher than other mobs (48 by default) and should not be lowered. A raid farm that is AFKed for hours generates totems and emeralds faster than any economy can absorb, and runs continuous raid AI. A time window or a rule that raid farms are not AFKed overnight is reasonable.

Gold farms in the Nether roof or on nether portals produce huge numbers of zombified piglins and gold nuggets. The mobs are cheap individually; the problem is the drops. A gold farm without full item collection fills the ground with nuggets and rotten flesh, and that is an entity count problem covered in entity cleanup and ClearLag.

The common thread is AFK. A farm is cheap when one player uses it for twenty minutes; it is expensive when it runs eight hours a night because its owner is asleep at the controls. If your server allows AFK, consider whether it allows AFK at farms specifically.

Farm rules players will accept#

Configuration only goes so far. The servers that do not fight about lag have rules written down before the first farm is built, and admins who enforce them evenly.

1. State the simulation distance and activation ranges. Builders design around numbers. If they know farms only run within six chunks and mobs only wake within 24 blocks, they will build accordingly and will not report the result as a bug.
2. Set limits per base, not per player. Villager count per hall, animals per pen, number of spawner grinders.
3. Require collection. Every farm must feed into storage or a kill-and-collect system. No ground items.
4. Require an off switch for breeders, raid farms and anything on a clock.
5. Publish what happens when a farm breaks the rules. First a message, then disabling the farm, then removal. Never silently delete.
6. Review new mega-builds before they go live, not after a lag spike.

Pair the rules with tools that let staff act without guesswork: /paper entity list for counts, spark for proof, and a grief-logging plugin so you can see who placed the 300th bed. Rules, moderation and staff covers the human side, and grief protection and anti-cheat covers the logging.

On RE:NODE the console shows /mspt and /paper entity list output unfiltered, with the CPU and memory graphs beside it against your plan's real limits, so you can watch a farm switch on and see the cost. CPU is a hard throttle to the share you bought: a server pinned at 100% is slow, not broken, and never suspended for it - but if a single base can pin it, that is a rules problem before it is a plan problem. CPU vs RAM for game servers explains why more memory does not help here.

FAQ#

How many villagers is too many for a server?

There is no fixed number; it depends on how they are kept. A few hundred employed villagers in one-block cells cost less than fifty roaming loose in a village. Watch /mspt while the busiest hall is loaded and decide from that, not from a count.

Does tick-inactive-villagers: false break trading halls?

No. Trading works whenever a player is close enough to trade, because they are inside the activation range. What stops is activity while nobody is near - restocking, breeding and golem spawning far from players. For most halls that is unnoticeable.

Why did our mob farm get slower after the server grew?

Usually because the mob cap is shared differently, or because the cap was lowered. With per-player spawning, mobs near you count against your budget; more players nearby, lit caves and persistent mobs all change the rate. Check bukkit.yml and ask whether anyone has name-tagged mobs near the farm.

Should I kill all villagers outside trading halls?

Not without warning. Wandering villagers in natural villages are cheap when nobody is near them because they are outside the activation range. The ones to target are unemployed villagers in holding areas and breeders that have overfilled, and the owner should be told first.

Will raising maxEntityCramming fix animals dying in pens?

It will stop them dying and make the server slower. Entities piled into one space are exactly what makes collision checks expensive. Give the animals more space or keep fewer of them.