RavenousMC
All posts
· 5 min read ·
fabric performance modded

Why your Fabric server hitches when you fly with elytra (and how to fix it)

You’re a couple hundred blocks up, elytra out. You crack a rocket, watch the chunks scroll under you — and then a whole row of them just… isn’t there. You slow down. It catches up. You launch another rocket. Same story.

If your reaction is “this can’t just be me,” it isn’t. Every Fabric server, every Forge server, and every vanilla server does this by default. The mod stack you built didn’t cause it. The world you built didn’t cause it. Minecraft’s chunk pipeline just wasn’t designed for you moving that fast, and once you know why, it’s a 15-minute fix.

What’s actually happening

At every tick, the main server thread has to (a) run the world tick, (b) hand new chunks to a small pool of worker threads that load them from disk, (c) let those workers re-light every new chunk before it’s usable, and (d) send the finished chunks to your client. Everything downstream of the main thread is single-file. If any step gets slow, the whole line stops.

Two of those steps are the usual culprits.

The light engine is single-threaded in vanilla. Every chunk that pops off the loader has to be re-lit before your client sees it. That’s fine at walking speed. It is not fine at elytra + rocket speed, where you’re covering a chunk every half-second and a fresh row is always waiting.

Chunk saves are worse. Vanilla defaults sync-chunk-writes=true, which calls fsync() after every chunk write. Paper switched this to false years ago because it blocks the main thread on disk I/O — you’re paying 3-10 ms per fsync for a durability guarantee you don’t actually need on a Minecraft server. Fabric inherits the vanilla default. So does modded.

Add both up and you get: the main thread constantly bottlenecked by disk fsync, chunk workers waiting on the light engine, client watching a checkerboard of half-loaded terrain.

The fix, ranked by how much it moves the needle

Do these in order. Stop when flight feels smooth.

1. Set sync-chunk-writes=false in server.properties.

Five-second change. Often solves the problem outright on smaller servers. Open the file, change the value, restart. Your saves are still durable — the OS still flushes them, just not synchronously on every single write. If your host power-cycles at exactly the wrong moment you might lose the last minute or two of a chunk’s changes, but at that point you’d want a restore from backup anyway.

2. Install Starlight.

Starlight is a rewrite of Minecraft’s light engine. It’s significantly faster than vanilla and moves lighting off the main thread entirely. It is the single biggest fix for the “chunk loaded but not rendered” symptom, because that visible gap is the light engine catching up.

Drop the jar into your server’s /mods folder, restart. That’s the entire installation. Fabric and NeoForge builds both exist. No config file, no compat flags — it replaces the code path.

3. Install C2ME.

C2ME (Concurrent Chunk Management Engine) parallelizes the chunk loading pipeline itself. Where vanilla uses ~4 worker threads and processes chunks in-order, C2ME uses your full CPU and can load a dozen chunks at once.

This matters most when your world is newly generated during flight — if you’re mostly flying through pre-built territory, Starlight alone probably handles it. If you’re an explorer, you want both.

Same install path — jar into /mods, restart.

On classic Forge (not NeoForge), C2ME doesn’t have a direct port. Substitute Canary — same author as Lithium, similar general-purpose optimizer.

4. Consider lowering simulation-distance.

Distinct from view-distance. Simulation distance is the radius where entities tick, mobs breed, redstone runs. View distance is how far you can see. Most people set them equal by habit and don’t need to.

At simulation-distance=10, entities tick in a 21×21 chunk box around each player. That’s plenty for anything you actually notice. Keep view-distance at 15 (or higher, if you like the vibes), drop simulation-distance to 10, and you buy back a huge amount of CPU without your world looking smaller.

Installing mods on RavenousMC

Open your server in the panel, click Files, drop the jar files into /mods, then hit Restart from the Overview tab. That’s the whole flow — no SSH, no SFTP, no re-zipping the world.

If your server template is Fabric or Forge, /mods is already the right folder. Vanilla and Paper templates don’t have a /mods folder because they don’t support mods; those you’d need to redeploy on a Fabric or Forge plan first.

How to tell it worked

Two ways.

Load your server’s Stats tab in the panel and watch the TPS chart while someone does an elytra sweep across your build. Before the fix you’ll see a visible dip in TPS (the green line drops below 20) while new chunks are streaming in. After Starlight + C2ME + sync-chunk-writes=false, that dip flattens out.

Or just fly. If chunks keep up with rockets, you’re done.

What about Forge?

Same principles, mostly the same mods, different names:

  • Starlight — has a Forge build under the same name.
  • C2ME — not available on classic Forge; use Canary (Lithium’s Forge sibling — general perf, no chunk parallelism, but decent gains).
  • NeoForge — inherits most of Fabric’s ecosystem, so C2ME does have a NeoForge build there. Prefer NeoForge over classic Forge on 1.20+ if you’re starting fresh.
  • server.properties tweaks work identically.

One thing to check first

If you install all these mods and still see hitches, it might not be the pipeline. Look at CPU and RAM utilization in the panel while flying:

  • If CPU is pinned at 100% across every core, no chunk mod will save you. Your world plus mod stack is straight-up bigger than your plan. Time to upgrade RAM/CPU, not tune.
  • If Java heap is above 90% consistently, GC is thrashing. Same answer — you’re heap-constrained.
  • If CPU has headroom (say, sitting under 70%) and you’re still hitching, then yes, it’s the chunk pipeline. Fixes above.

Bottom line

Chunk-load lag isn’t a bug — it’s a design that made sense in 2015 and hasn’t been rewritten since. The mods above have. Treat them as required for any modded server past 1.18. Your future self, flying with rockets, will thank you.