Chunk Loading, View Distance and Simulation Distance: What Each One Costs a Server
How chunk loading, view distance and simulation distance each cost a Minecraft server in memory, CPU and bandwidth, how chunk tickets work, and how Paper exposes the settings.
ChunkPod Team · · 9 min read
Chunk Loading, View Distance and Simulation Distance: What Each One Costs a Server
A Minecraft server spends most of its CPU time on two things: ticking chunks and shipping chunk data to players. View distance and simulation distance are the two knobs that decide how much of both work the server signs up for, and they hit the server in different places. Cranking them up without understanding what changes is how a server ends up burning RAM for chunks nobody is looking at, or burning a full CPU core on mobs and hoppers 200 blocks away from anyone.
What a chunk actually is
A chunk is a 16 by 16 column of blocks that runs from the bottom of the world (y = -64 in 1.18+) to the top (y = 320). The server stores each chunk on disk in a region file, loads it into memory when it needs to, and unloads it when nothing keeps it alive. Every block, block entity (chest, hopper, sign), entity (mob, item, player) and biome sample in that column lives inside that chunk's data.
The server doesn't think in "distance from a player" directly. It thinks in chunk coordinates and a system of tickets that pin a chunk into memory at a specific level. Players hold the strongest tickets. Force-loaded chunks (from /forceload) hold another. The spawn chunks hold their own. The rest of the world exists on disk and nowhere else until something asks for it.
What the server does when a player moves
Every time a player crosses a chunk boundary, the server does a small amount of bookkeeping and, sometimes, a lot of work:
- It looks at which chunks are now inside the player's view distance and starts loading any that aren't in memory yet. That means reading them from disk, or generating them if the world has never been to that spot, which is one of the most expensive things a Minecraft server can do.
- It sends the chunk data packets to the client for every chunk that just entered view range. On a fresh join at view-distance 10, that's 441 chunks in one burst.
- It updates the player ticket that keeps chunks alive. Chunks that used to be inside the player's radius but now aren't lose that ticket, and if nothing else is holding them, they get queued for unloading.
- It moves the ring of ticking chunks with the player, based on simulation distance. Chunks that just entered simulation range start ticking their entities, block entities and random block updates. Chunks that just left stop.
Multiply that by every player, and by every player teleport or nether portal, and it's clear why chunk work dominates a busy server's profile.
View distance: what the client sees
The view-distance setting in server.properties tells the server how many chunks around a player should be sent to the client. A view-distance of 10 means the player gets a 21 by 21 grid of chunks (10 in each direction plus the chunk they stand in), or 441 chunks. Vanilla defaults to 10.
View distance costs the server in three places:
- Disk and generation. Every chunk in the visible ring has to be loaded or generated. New terrain is the slow part. Once a chunk is on disk, reloading it is much cheaper, which is why chunk pregeneration is so popular.
- Memory. Every loaded chunk sits in the JVM heap. Each fully loaded chunk with its entities and block entities takes a few megabytes, and it climbs fast when you multiply by hundreds of chunks per player.
- Bandwidth. New chunks and block updates are sent over the wire. Wider view distances mean bigger initial join bursts and more block-change packets travelling out.
View distance doesn't, on its own, run the game logic in those chunks. That's simulation distance's job.
Simulation distance: what actually runs
simulation-distance was split out from view distance in Minecraft 1.18. Before that, the two were the same number, and there was no clean way to let players see far without paying the CPU cost of ticking everything they could see.
Simulation distance controls the radius in which chunks are entity ticking. Inside it:
- Mobs move, path and take AI decisions.
- Hostile and passive mob spawning runs.
- Crops, saplings, leaves, redstone dust and other random-tick blocks tick.
- Hoppers, furnaces and other block entities run their logic.
- Water and lava flow.
- TNT counts down.
Outside simulation distance but inside view distance, the chunk is loaded and visible, but frozen. A player can see a village in the distance and watch it tick when they walk closer.
Simulation distance is the CPU knob. Doubling it doesn't double the work, it roughly quadruples it, because the number of ticking chunks is (2r + 1)^2 where r is the distance in chunks. Going from 4 to 8 takes you from 81 ticking chunks per player to 289, and every one of those chunks contributes its share of entities and random ticks per tick, twenty times a second on a healthy server.
The chunk ticket system, in plain terms
Under the hood, chunks live at one of a few levels, set by tickets:
- Entity ticking. Full game logic, matches simulation distance.
- Block ticking. Random block ticks and block entities run, but entity AI doesn't. This is a narrow ring just beyond entity ticking on vanilla.
- Border. The chunk is loaded and can send updates to clients, but very little ticks.
- Inaccessible. Queued for removal from memory.
Different sources hand out tickets at different levels. A player near a chunk hands out a strong ticket. /forceload add hands out a ticket that keeps a chunk loaded and fully ticking, even with no player nearby, which is why players use force-loaded chunks to keep farms running. The spawn chunks around world spawn are also kept loaded so that redstone contraptions there keep running. Since Minecraft 1.20.5, the size of that area is set by the spawnChunkRadius game rule. It defaults to 2, which is much smaller than the old spawn chunk area, and setting it to 0 turns spawn chunks off.
Understanding tickets matters because it tells you which chunks can cost you CPU. A chunk nobody holds a ticket for isn't loaded at all, so it costs nothing. A chunk held by a player or by /forceload is loaded and ticking, which means its mobs, redstone and block entities all run. A force-loaded farm keeps doing that even when every player is on the other side of the world.
Why higher distances hurt in more than one way
The multiplier effect is the part that catches people out. Raising view distance from 8 to 12 changes the visible chunk count per player from 289 to 625, a 2.16x jump for a "just four more chunks" tweak. Raising simulation distance from 4 to 6 changes ticking chunks per player from 81 to 169.
On top of the per-player cost, the chunks a player is holding open aren't always unique. Two players standing next to each other share most of their chunks, and the server only loads and ticks each chunk once. Two players in different biomes, or in different dimensions, share nothing. That's why a 20-player server where everyone hangs out at spawn behaves nothing like a 20-player server where everyone runs off in different directions to build.
Memory scales with view distance, CPU scales with simulation distance, and network scales with view distance and how much is changing in those chunks. If your TPS is fine but your RAM is full, that's a view distance and chunk retention conversation. If your RAM is fine but your TPS is dropping under load, that's a simulation distance and entity-density conversation.
How Paper exposes these settings
Vanilla gives you view-distance and simulation-distance in server.properties, and that's it. Paper and its downstream forks like Purpur go further.
- Paper reads the same server.properties values as defaults.
paper-global.ymlandpaper-world-defaults.ymllet you set per-world overrides for view distance and simulation distance, so a lobby world can run at simulation-distance 2 while a survival world runs at 6.- Paper's
no-tick-view-distancefrom older versions served the same role that vanilla'ssimulation-distancenow serves, and modern Paper effectively bakes that into the standard setting. - Async chunk loading and Paper's rewrites of the chunk system make the raw cost of loading chunks lower than vanilla, but they don't change the fundamental math: more chunks is more work.
Plugins like Chunky handle pregeneration so that "load from disk" replaces "generate from scratch" for the parts of the world players are likely to walk into. That doesn't reduce the number of loaded chunks, it just makes each new one cheaper.
Picking numbers that fit the server
There isn't a universal right answer, but there are shapes. A small SMP with a handful of friends on modest hardware often runs happily at view-distance 8 and simulation-distance 4. A public server with dozens of concurrent players will usually pull view distance down to 6 or 7 and keep simulation distance lower still at 3 or 4, then lean on Paper's per-world overrides to give creative and lobby worlds even smaller numbers.
The honest test is to watch /tps and the memory graph under real load, not idle. A server that looks fine empty can fall over the moment ten players spread out and each one starts holding their own chunk radius alive.
If you'd rather not run the hardware or the Java process yourself, ChunkPod is a Minecraft server host in early access. You can join the waitlist at chunkpod.com, and the free server.properties Generator at chunkpod.com/tools is a good place to sanity-check view-distance and simulation-distance values against the kind of server you're planning.