A Custom Modpack Was Maxing Out RAM With Zero Players Online. Here's What Fixed It.

If your modded Minecraft server is maxing out RAM even with zero players online, you're not alone. Last week someone reached out from a Shockbyte thread with a custom pack on 4 GB RAM that had been stable for months and suddenly started crashing the moment anyone joined.

Here's exactly what happened, what we found, and what fixed it.

TL;DR — What to Check

If you're dealing with high RAM usage with no players online on a modded server, here's the short version:

• Run spark profiler --timeout 300 and check heap usage and GC pause time
• Run spark heapsummary to see what's occupying memory
• Ensure FerriteCore is present in your server mods folder — not just your client
• Cross-reference server mods against client mods for any performance mods meant to run on both sides

Read on for the full story and why each step matters.

The Symptoms

The server was running a custom modpack on 4GB RAM. It had been working fine for months — two players, no issues. Then without any obvious change, it started crashing the moment anyone tried to join. The error mentioned the server being several thousand ticks behind.

The strange part: RAM was sitting at maximum even with zero players online and no chunks loaded.

One of the mods in the pack was Ksyxis, which delays chunk loading until a player actually joins. So at zero players the server should have been doing very little. But memory was already at the ceiling.

Shockbyte's advice had been to re-add all non-client-side mods to the server folder. That was done. The problem continued.

Step 1 — Run Spark

The first thing to do with any unexplained server performance issue is get real data. We asked them to run:

spark profiler --timeout 300

Spark is a free open-source performance profiler for Minecraft servers. It samples CPU and memory usage over a set period and produces a shareable report you can actually read.

The report showed heap memory sitting at 3.9GB out of a 4GB total allocation. That left almost no headroom for non-heap memory — the memory the JVM uses outside the heap for things like class metadata and compiled code. When that space is squeezed, the server becomes unstable regardless of what's happening in the game itself.

The garbage collector pause time was at 1660ms. To put that in context: GC pauses above a few hundred milliseconds start causing noticeable lag in-game. At 1660ms the server is effectively freezing briefly and repeatedly as Java tries to free up memory — which with a near-full heap happens constantly.

Step 2 — Rule Out a Memory Leak

High heap usage can mean one of two things: either the server genuinely needs more RAM for the workload it's running, or something is holding onto memory it should have released — which is called a memory leak.

To look deeper we asked them to also run:

spark heapsummary

This produces a breakdown of what objects are occupying heap memory at that moment. After reviewing the output, the pattern didn't look like a classic leak — there wasn't an obvious class accumulating objects over time. The memory profile looked more consistent with a modded Minecraft server maxing out RAM because it was simply missing an optimisation it had previously been relying on.

Step 3 — The Real Cause

At this point we suggested trying FerriteCore and asked whether any mods had changed recently.

Then it clicked on their end.

FerriteCore is a mod that reduces memory usage in modded Minecraft by optimising how certain data structures are stored. It's designed to run on both the client and the server side. They had it installed on their client — but it was missing from the server mods folder.

When Shockbyte told them to re-add non-client mods, FerriteCore hadn't made it back in during that process. It had been silently absent from the server for an unknown amount of time.

They added it to the server folder and restarted.

RAM dropped from approximately 3.9GB to around 1200MB.

Why This Matters

A few things stand out about this case.

The symptom pointed away from the real cause. A server crashing on join with maxed RAM looks straightforwardly like a RAM problem. The natural instinct — and Shockbyte's recommendation — was to check the mod folder contents. But FerriteCore was missing precisely because it had been re-added incompletely during that same process.

Custom modpacks are unpredictable in ways pre-built ones aren't. Modpack developers who release on CurseForge spend significant time on optimisation passes. A custom pack doesn't have that. A single missing or misconfigured mod can shift memory behaviour significantly.

Spark is the right starting point. Running a profiler before guessing at solutions narrowed the problem quickly. The heap summary showed the server wasn't leaking — it was just running without a mod it had previously depended on for memory efficiency.

What to Check If You're Seeing This

If your modded server is using unexpectedly high RAM with few or no players online:

• Run spark profiler --timeout 300 and check heap usage percentage and GC pause times
• Run spark heapsummary to see what's occupying heap memory
• Verify FerriteCore is present in your server mods folder — not just your client
• If you're on a custom modpack, cross-reference your server mods against your client mods for any performance mods that are meant to run on both sides

If you're also thinking about switching to a host that doesn't cap your storage, we covered how to migrate a modded server away from Exaroton step-by-step.

A Note on Support

This person had been dealing with this for over a week. The fix took an afternoon once we had a Spark report to look at.

This is the gap Piggo exists to close — not just faster responses, but someone who actually understands what's happening inside a modded server and knows what to look for. If you're dealing with something similar, our Discord is open at discord.gg/KsXepU7A59. No obligation, just help.

Piggo is a managed Minecraft hosting provider built specifically for modded servers. We handle setup, monitoring, and support personally. piggo.host