Paper Server Optimization Guide for Minecraft 1.21.11

Quick answer: The fastest way to optimize Paper is to stop changing random YAML values and profile the workload that is actually slow. Keep a baseline, reproduce the problem, capture a Spark profile, change one constrained setting, and compare the same player activity again. Most “optimization packs” hide the cause while changing gameplay.

Last reviewed: 31 August 2026 for Paper 1.21.11 and Java 21.

Performance targets that matter​

Minecraft aims for 20 ticks per second. One tick has a 50 ms budget. TPS can remain near 20 while individual ticks hitch, so watch mean and high-percentile MSPT, not only the TPS number.

• MSPT: how long each server tick takes. Sustained values near or above 50 ms mean the server cannot maintain 20 TPS.
• Tick percentiles: reveal spikes hidden by an average.
• CPU profile: identifies which plugin, entity, chunk or game subsystem consumes tick time.
• GC activity: shows whether pauses come from allocation pressure rather than game logic.
• Disk and database latency: explain save, chunk-load and persistence stalls.

1. Record a baseline before tuning​

Write down:

• Paper build and Minecraft version
• Java runtime from the actual server process
• Startup command and memory limit
• Plugin list and versions
• World count, view distance and simulation distance
• Online players and the activity that causes lag
• Average/95th/99th percentile MSPT if available

Starting with Paper 1.21, Spark is bundled and is Paper's preferred profiler. Capture the issue while it is happening:

/spark profiler start --timeout 600

Use the returned report with the Minecraft lag diagnosis guide. An idle profile cannot explain a combat, farm, world-generation or arena-reset spike that never occurred during capture.

2. Confirm the supported Java runtime​

Paper's current matrix recommends Java 21 for Minecraft 1.20 through 1.21.11. Newer Paper 26.1+ releases require Java 25. Do not upgrade Java or Paper independently without confirming plugin compatibility.

java -version

On modern Java, Paper's start-script guidance says to try default garbage-collector settings first. Do not paste a decade-old flag collection merely because it is labelled “optimized.” Read the Java 21 and RAM guide before changing heap or GC flags.

3. Set memory for the whole machine​

Do not allocate every gigabyte to -Xmx. The operating system, Pterodactyl/Docker, native buffers, file cache, databases and other servers need memory outside the Java heap. Swapping a Minecraft process usually creates severe latency.

More heap is not automatically more speed. Give the server enough for its measured live set and bursts, retain host headroom, and investigate steady growth instead of continually raising the limit.

4. Tune view and simulation distance intentionally​

Paper documents view-distance and simulation-distance in server.properties:

• View distance controls how much world data is sent around players.
• Simulation distance controls the radius where entities and other ticking game logic remain active.

Reducing simulation distance often saves more CPU than reducing view distance because fewer chunks actively tick. The correct value depends on the game mode. A compact practice arena may need less than a survival server where farms and exploration are core gameplay.

Change one value, restart, reproduce the same workload and compare. Avoid lowering both until players can no longer use intended mechanics.

5. Remove chunk-generation spikes​

New terrain generation is expensive. For bounded survival maps, pregenerate the playable border during maintenance and keep enough disk space for the resulting region files. For PvP arenas, preload or prepare the required chunks before admitting players rather than loading them in the first combat tick.

Watch for:

• Random teleports into never-generated terrain
• Fast flight or elytra exploration
• Plugins synchronously requesting unloaded chunks
• Arena clone/reset systems doing large work on the tick thread
• Backups competing with world saves on slow storage

NVMe storage helps chunk and save latency, but it cannot compensate for synchronous plugin logic that blocks the main thread.

6. Control entities without breaking gameplay​

Count entities by world and type before using a generic “clear lag” task. Regularly deleting dropped items or mobs treats symptoms and can destroy player items.

Use the profile to find expensive AI, pathfinding, collisions, hoppers, projectiles or explosions. Then constrain the specific source with gameplay-aware limits. Paper's per-world configuration lets different worlds use different behavior; do not force a lobby, survival world and duel arena to share every setting.

7. Audit plugins by work performed​

A long plugin list is not automatically slow, and a single plugin can dominate a tick. Look for:

• Database or HTTP calls on the main thread
• Large synchronous loops over players, chunks or blocks
• Scoreboards rebuilt more often than visible data changes
• Repeated placeholder expansion
• Inventory saves on every click
• WorldEdit/FAWE work initiated without lifecycle controls
• Tasks scheduled every tick without need
• Errors repeated thousands of times in logs

Update one plugin at a time on staging. Keep the previous JAR, configuration and database backup so you can roll back safely.

8. Design PvP servers for bounded work​

Practice and duel servers have distinctive spikes: crystal explosions, projectile tracking, kit serialization, queue matching, arena cloning and reset. Performance depends on controlling those lifecycles, not disabling normal server mechanics globally.

ShyamDuels is designed around claimed arenas, chunk preparation and reset ownership. Review ShyamDuels Practice & Duels Core when you need a coordinated foundation, or compare the ready-to-run Advance ShyamDuels Setup. Product choice does not replace load testing; use your own maps, kits and expected concurrency.

9. Test one change at a time​

Use a repeatable test card:

1. Start from the same backup or world state.
2. Use the same Paper, Java and plugin builds.
3. Run the same player actions for the same duration.
4. Capture Spark for the slow window.
5. Change one setting or component.
6. Repeat the workload.
7. Compare MSPT distribution, profile share, memory and player-visible behavior.
8. Keep the change only if it improves the target without unacceptable gameplay loss.

Optimization myths​

• “More RAM fixes lag.” It does not fix a CPU-bound tick or synchronous database call.
• “20 TPS means perfect.” Short stalls can exist while an average recovers.
• “Async means safe.” Bukkit world and entity state usually has thread-affinity rules.
• “Clear-lag tasks optimize entities.” Deletion is not diagnosis.
• “Folia makes every plugin faster.” Folia requires explicit region-safe design and compatible plugins.
• “Copying a config pack is tuning.” Tuning requires a measured workload and accepted gameplay trade-offs.

Primary sources​

• Paper: Profiling with Spark
• Paper: server.properties reference
• Paper: Configuration reference
• Paper: Java requirements
• Paper: Start script guidance

For measured troubleshooting, open a Shyam Studio support request. Include the Spark link, Paper/Java versions, player count and exact reproduction steps.