A vanilla server and a 200-mod pack differ by more than content. Mods add blocks that tick, machines that run continuously, and world generation that has to place all of it — so the same player count costs several times more.
Where the extra cost comes from
| Source | Why |
|---|---|
| Ticking machines | Tech mods add blocks that process every tick, whether or not anyone is watching. |
| World generation | More ores, structures and biomes to place makes generating each chunk slower. |
| Memory | Every mod's registry, recipes and textures live in memory before a single player joins. |
| Startup time | Loading and stitching hundreds of mods takes minutes, not seconds. |
| Chunk size on disk | More block types and block entities per chunk means bigger region files. |
What actually helps
- Give it the memory the pack asks for
Modpacks publish a recommended figure and it is usually honest. Running a pack that wants 6 GB on 4 GB is the most common cause of a modded server that «randomly» freezes.
- Pregenerate the world
Modded chunk generation is genuinely slow. Generating the area people will explore in advance moves that cost off the live server entirely.
- Install a performance mod set
Server-side mods that improve chunk handling and entity behaviour are widely used and usually safe. Add them one at a time and read what each one changes.
- Profile with spark — it works on modded too
Spark exists for Fabric and Forge as well. A modded server that lags almost always has one machine, one chunk loader, or one mod at the top of the tree.
Blocks and items from a removed mod disappear from the world, and depending on the mod that can mean chunks that will not load. Never remove a mod from a pack people have built in without a backup and a test on a copy first.
In modded packs, low FPS is far more common than low TPS. Ask for /spark tps before spending an evening on server tuning — if TPS is 20, the problem is on their machine, and the fix is graphics settings.