How to Configure Async Chunk Generation

Why Chunk Generation Causes Lag

Generating new terrain is one of the heaviest operations a Minecraft server performs. Each new chunk requires noise calculations, biome placement, structure generation, feature decoration (trees, ores, caves), and light calculations. In vanilla Minecraft, all of this happens on the main server thread. When a player flies into unexplored territory with an elytra, the server must generate dozens of new chunks per second, and each one blocks the tick loop. The result is TPS drops, rubber-banding, and a terrible experience for every player on the server. Async chunk generation minecraft Paper servers provide moves this work off the main thread, which is the single most impactful chunk optimization available.

Paper's Async Chunk System

Paper has included async chunk loading and generation since 1.13+. On modern Paper builds (1.20+), async chunk generation minecraft uses is enabled by default with no configuration needed. The system works by running terrain generation on separate worker threads. When a player moves toward ungenerated chunks, the request is queued to a thread pool. Once generation completes, the chunk is handed back to the main thread for integration. The main thread never blocks waiting for generation to finish.

You can verify async chunks are working by watching the output of /spark profiler. If ChunkGenerator methods appear on worker threads (not the Server Thread), async generation is active.

Thread Configuration

Paper controls the number of async chunk worker threads through JVM system properties and Paper's global configuration. The relevant settings in paper-global.yml:

# paper-global.yml
chunk-system:
  io-threads: 2              # threads for chunk I/O (reading/writing)
  worker-threads: 4           # threads for chunk generation

The worker-threads value determines how many chunks can be generated simultaneously. The default is calculated automatically based on your CPU core count. As a rule of thumb:

• 2-4 CPU cores: Set worker-threads to 2.
• 4-8 CPU cores: Set worker-threads to 3-4.
• 8+ CPU cores: Set worker-threads to 4-6, but rarely higher. More threads create lock contention that can actually slow things down.

The io-threads value controls how many threads read/write chunk data from disk. On NVMe SSDs, 2 threads are sufficient. On slower SATA SSDs or HDDs, increasing to 3-4 can help prevent I/O bottlenecks during heavy exploration. Matching these settings to your hardware is key to getting the most from async chunk generation minecraft Paper provides.

Pre-generating Your World

Async chunk generation moves the cost off the main thread, but the cost still exists. Each generated chunk consumes CPU on the worker threads. On a server with many explorers, those worker threads can saturate your CPU, causing indirect lag. The best solution is to pre-generate your world so that chunk requests become simple disk reads instead of expensive generation tasks.

Install the Chunky plugin and pre-generate your playable area:

/chunky worldborder      # match your world border
/chunky start

Chunky generates chunks asynchronously in the background and throttles itself to avoid impacting TPS. A 10,000-block radius takes several hours but eliminates generation lag entirely for the covered area. Run Chunky during off-peak hours or before opening the server to players. For a detailed pre-generation workflow, see our chunk loading guide.

Interaction with Other Settings

Several settings interact with async chunk generation:

• View distance and send distance: Higher view distances require more chunks to be generated and sent. A view distance of 10 sends 441 chunks per player. Reducing to 7 cuts this to 225. Every chunk that does not need sending is a chunk that does not need generating.
• Simulation distance: Separate from view distance in modern Paper. Chunks beyond the simulation distance are loaded but not ticked. This means they need to be generated but do not add ongoing tick cost. A simulation distance of 5 with a view distance of 10 is a common, performant combination.
• World border: Setting a world border prevents players from exploring infinitely, which bounds the total generation work your server will ever need to do. Combined with pre-generation, a world border means zero generation lag after the initial setup.

Monitoring Chunk Generation Performance

Use /spark profiler to monitor chunk generation thread activity. In the flame graph, look at the worker threads for ChunkGenerator related methods. If worker threads are consistently at 100% utilization during exploration, either add more worker threads (if CPU cores allow) or reduce view distance to lower demand.

The Spark tick monitor (/spark tickmonitor) also helps: if ticks occasionally spike during chunk loading (not generation), the bottleneck might be I/O rather than generation. In that case, increase io-threads or upgrade your storage.

Async chunk generation is one of Paper's most valuable features and a primary reason to choose Paper over Spigot. Combined with pre-generation and appropriate thread tuning, it eliminates the most common source of exploration lag. For the full performance configuration, see our 20 TPS guide and our JVM flags guide.

See an optimized server in action: Astroworld MC, IP play.astroworldmc.com, Java + Bedrock.