B42 server lag comes in three distinct flavours, and they have different fixes — buying RAM for a CPU problem (or vice versa) is how admins waste a month. Learn to tell them apart from how the lag feels, then apply the fix that matches.
First: which lag do you have?
| How it feels | Likely cause | Fix section |
|---|---|---|
| Everyone freezes at once, rhythmically; worse as uptime grows | Memory / GC pressure | §1 |
| Constant low-grade slow-motion; zombies and animals stutter-step | CPU / simulation load | §2 |
| One player rubber-bands while others are fine | That player's connection or client | §3 |
| Fine for weeks, then increasingly heavy | Save bloat | §4 |
1. Memory pressure (the whole-server hiccup)
The server is Java; when its heap runs near-full, garbage collection pauses everyone simultaneously. Rhythmic all-player freezes that reset after a restart are the tell.
Fix: size the heap properly — ~6GB base plus mods and players, heap at 75% of machine RAM. The full sizing table is in how much RAM a B42 server needs. A nightly scheduled restart also keeps a long-running heap honest.
2. Simulation load (B42's new costs)
B42 simulates more than B41 ever did, and it's mostly single-thread-sensitive — a high-clock CPU beats a many-core one. The big consumers, roughly in order:
- Animals. Herds path and live server-side continuously. Sandbox options control population; halving animal density is the single biggest CPU relief on a struggling server.
- Zombie population. The classic cost, still true in B42: population multiplier, respawn settings and migration all trade atmosphere for tick time.
- Player spread. Ten players in one town load one set of cells; ten players scattered across the map load ten sets. Big exploration events are heavy by design.
- Mod cost. Every scripted mod runs inside the tick. After any lag regression, the first question is "what did we add to the mod list?" — bisect by disabling the newest additions (mind the load order when re-enabling).
These are gameplay dials as much as performance ones — the relevant sandbox and ini keys are in B42 server settings explained.
3. One player lagging (it's not the server)
If the server metrics are clean and one player teleports around: their connection (Wi-Fi, distance to the server, CGNAT) or their client (B41/B42 branch mismatch, stale mod versions, a potato PC in a 4K base). Have them check ping to the server's region, verify game files, and resubscribe the server's mods. Region distance is physics — a European player on a US-East server carries ~100ms they cannot config away.
4. Save bloat (the three-week fade)
Zomboid persists world change: every looted cabinet, dropped item, corpse, blood splat and player-built wall. Months-old worlds carry it all, and B42's richer world state accumulates faster. Mitigations, from gentle to drastic:
HoursForCorpseRemovaland loot-respawn settings keep the corpse/item population bounded.SaveWorldEveryMinutesat a sane interval (not 0/constant) reduces write pressure on big worlds.- Trim distant, never-revisited claimed areas if a mod provides tooling for it.
- The nuclear option every long-running server eventually schedules: a soft wipe/new-map event. B42's fresh-map energy makes this an easier sell than it used to be.
Take a backup before any of these — save folder plus the two config files, server stopped or freshly /saved.
The fifteen-minute triage, in order
When "the server is lagging" arrives in your Discord, this sequence isolates the cause fastest:
- Ask who. Everyone, or one player? One player → §3, done in five minutes.
- Ask when. Since a specific restart or mod change → bisect the change. Gradually over weeks → §4 (save bloat). Worse as the session ages, resets on restart → §1 (heap).
- Look at the pattern. Rhythmic synchronized freezes → §1. Constant slow-motion that tracks zombie/animal density → §2.
- Check the box. Memory near the ceiling → heap; one core pinned at 100% while others idle → simulation (and note the server's single-thread sensitivity — a "bigger" many-core machine with lower clocks can actually be a downgrade here).
- Only then change something — one variable at a time, and write down what you changed. Lag "fixes" applied in handfuls are how servers end up mysteriously configured forever.
Network settings: mostly leave them alone
A word on the tempting lever: servertest.ini exposes network pacing options, and forum lore is full of magic values. As of 42.20 the defaults are right for the overwhelming majority of servers — network tuning fixes network problems (jitter on marginal connections), not simulation or GC problems, and aggressive values make desync worse. If you're on a datacenter connection, exhaust §§1–4 before touching them; if you're self-hosting on home upload, the connection itself is the setting that matters (the honest comparison).
Frequently Asked Questions
Why does my B42 server lag when nobody is online?
Because the simulation doesn't sleep: animals and zombie populations keep ticking. PauseEmpty=true in servertest.ini pauses the world when the last player leaves — it's the default worth keeping on any private server.
Why did lag get worse after moving from B41 to B42?
B42 genuinely costs more — animals, basements, more tracked world state. The old B41 hardware folk wisdom undersizes it; see the RAM guide for the new floor, and halve animal density if CPU-bound.
Does lowering the zombie population fix lag?
If the lag is simulation-side (constant slow-motion), yes — zombie and animal population are the two biggest dials. If it's the rhythmic everyone-freezes-at-once kind, that's memory pressure and population changes won't touch it.
How do I prove whether it's RAM or CPU?
Watch the pattern: rhythmic synchronized freezes that reset on restart = heap/GC (RAM). Constant stutter that scales with zombies/animals/players regardless of uptime = simulation (CPU). One player affected = their side, not yours.
Or skip the diagnosis rota: our Project Zomboid server hosting plans size heap to plan automatically and include scheduled restarts, so the two self-inflicted lag classes never happen.
