Build Your Own Minecraft Server, Part 3: Settings That Actually Reduce Lag
Published 2026-07-25 · SameOS Tools
Once the server is up and friends start joining, the next problem is always lag. But that word bundles three different problems: the server falling behind on simulating the world (mobs teleport-stutter, doors respond late), a slow network (high ping), and your own computer struggling to render (low FPS). Only the first one is fixable with server settings, and that is what this article is about - ordered by impact.
First: simulation distance, not view distance
The config file has two similar-looking values. view-distance is how far the world is shown to players (bandwidth); simulation-distance is how far the world actually runs (computation). Mobs moving, crops growing, machines ticking - all of it happens only within simulation distance, and that computation is what weighs a server down. So when lag hits, shrink simulation before view: the scenery stays the same while the server load drops. Mine runs both at the default 10, with the plan of dropping simulation to 8 first if player count grows. Each step down shrinks the number of chunks (the 16×16-block units the world is divided into) roughly quadratically, so the effect is large.
# server.properties — the two lines that matter for lag
view-distance=10 # how far players can see - lowering cuts bandwidth
simulation-distance=10 # how far the world runs - lowering cuts computation
# Order of operations when lag appears:
# simulation-distance 10 → 8 (barely noticeable, big effect)
# still heavy? view-distance 10 → 8
# Restart the server after changingSecond: more RAM is not better
This one is counterintuitive, so everyone gets it wrong at first. Java periodically cleans up discarded memory (garbage collection), and the server briefly freezes during each cleanup. The more memory you hand it, the more there is to clean in one pass - so giving the server 32GB does not make it smooth; it can make it stutter for whole seconds instead. Small servers are fine on 4-6GB, and 8GB is the realistic ceiling for heavily modded ones. Mine starts at 2GB with a 6GB cap and runs a 10-player world without trouble.
# Memory options in the launch command
java -Xms2G -Xmx6G -jar fabric-server-launch.jar nogui
# -Xms2G memory reserved at startup
# -Xmx6G the cap - 4-6G for small servers, 6-8G for modded
# 32G "just in case" backfires: longer GC pauses
# If the machine has 16G total, do not give it all to the server -
# leave room for the OS and everything else on the boxSo how many players can it take? A recommendation table
Since we are on the topic of memory, here is the answer to the most-asked question. The table below is a conservative starting point based on rules of thumb - the same RAM stretches differently depending on CPU speed, world size, and the distance settings above, so start at these numbers and raise them while the server stays comfortable. The gap between vanilla and modded is bigger than people expect: heavy modpacks attach machine, pipe, and magic computations to every player, so the same RAM carries less than half the players.
# Recommended concurrent players by memory (conservative starting point)
[Vanilla / a few light mods]
2GB → 2-4 players
4GB → 5-10 players
6GB → 10-20 players # mine: 6GB cap with max-players=10 (comfortable)
8GB → 20-30 players
[Heavy modpacks (dozens of tech/magic mods)]
4GB → 2-4 players
6GB → 4-6 players
8GB → 6-10 players
# beyond this, single-core CPU speed becomes the wall before RAM does
# More important than the table: dropping simulation-distance to 8
# lets the same RAM carry more than listed. The table is a starting
# point - the player count where your server starts stuttering is
# its real capacity.Third: optimization mods that live only on the server
Part 2 mentioned that server-side-only mods need nothing installed by the players - optimization mods are the prime example. On a Fabric server the two most widely used are Lithium (rewrites the game's internal computations to be more efficient) and FerriteCore (cuts memory usage). Neither changes game rules, only how the math is done, so they go on the server alone and your friends install nothing. Always download the build that matches your server's game version.
# Fabric server - drop into mods/ and restart, done
# (download version-matched files from modrinth.com)
cd ~/minecraft/mods
# Lithium - optimizes game logic (mob AI, physics) / no rule changes
# FerriteCore - reduces memory footprint
# e.g. lithium-fabric-0.x.x+mc26.1.2.jar
# ferritecore-x.x.x-fabric.jar
ls # both sitting next to fabric-api = ready
docker compose restart # (systemd path from Part 1: sudo systemctl restart minecraft)Everything else that genuinely helps
A few things live outside the config file. First, keep the world on an SSD - Minecraft constantly reads and writes the small files the world is chopped into, and on a spinning hard drive no amount of tuning saves you. Second, keep Java current - Part 1 covered the version trap, but newer Java also simply collects garbage faster. Third, schedule automatic backups for hours when nobody plays - the few seconds the Part 2 backup script runs can momentarily stall the server while it flushes saves. Fourth, set max-players to the number who will actually show up - empty slots cost nothing, but players are simulation load, and knowing your ceiling is where good operation starts.
Wrapping up
In order: simulation distance first, memory in moderation, optimization mods on the server only, world on an SSD. Those four cover most small-server lag. The next article changes direction: it is about defending the server - I will show you, straight from my own firewall logs, how bots from around the world start knocking on the Minecraft port the moment a server goes online.