How much RAM does a modpack need? Our server RAM calculator's estimate, explained, and how to set -Xmx and -Xms

Estimated starting points

The figures below are our own estimate model, the one our RAM calculator uses. They are estimates for smooth play on a typical pack of each size, not measurements of any particular modpack, and two packs with the same mod count can differ a lot. Start from the row that matches your pack, add the per-player estimate for each person online at once, and round up.

Worked example of the estimate: a medium pack with 5 players online is 6 + 5 × 0.15 = 6.75 GB, which rounds up to an estimated 7 GB. The same pack with 20 players online is 6 + 20 × 0.15, an estimated 9 GB.

What actually uses the memory

Most of what a server holds in memory is the loaded world and what lives in it. A modpack adds to that in two ways: every mod's code has to be loaded, and many mods add blocks, machines and creatures that keep their own state in the loaded chunks.

• Loaded chunks. Each player keeps an area of chunks loaded around them, set by view-distance in server.properties. The area grows with the square of the distance, so dropping from 12 to 8 roughly halves the chunks in memory.
• Players spread out. Players standing together share one loaded area; players exploring in different directions each load their own. That is why the per-player figure is an average, and a server of explorers needs more than a server of builders.
• Entities and block entities. Mobs, item drops and modded machines, pipes and storage keep state while their chunk is loaded. Large automated bases are a common reason one server needs more than another running the same pack.
• Mod code. Every mod's classes are loaded into memory outside the main heap, so a 300-mod pack uses memory before a single chunk loads.
• World generation. Generating new terrain is heavier than loading terrain that already exists, so a new world with players exploring uses more than the same world a month later.

The RAM on your plan is not all Java heap

Java splits its memory. The heap, capped by -Xmx, holds the world and everything the game creates. Outside the heap Java also needs room for loaded classes, compiled code, network and file buffers, thread stacks and the garbage collector's own bookkeeping. All of it has to fit inside the server's memory limit together.

That is why a server should never get an -Xmx equal to its full RAM. A heap that fills the whole box leaves nothing for the rest, and the operating system ends the process without a Java error when the total crosses the limit: the exit code 137 kill. A heap a little smaller than the RAM is the correct setting, not a waste.

Setting -Xmx and -Xms

On a server you run yourself, the estimate becomes two Java options. -Xmx sets the largest the heap may grow. -Xms sets the size the heap starts at, which is also its minimum. Both take a number with a unit letter, k, m or g in either case, so -Xmx6G and -Xmx6144M mean the same thing.

• Put them before -jar: java -Xms2G -Xmx6G -jar server.jar. Anything after the jar's file name goes to Minecraft, not to Java.
• NeoForge's installer writes a user_jvm_args.txt file for these options; its run.sh and run.bat scripts read it.
• Set -Xmx below the machine's or container's total memory, never equal to it, so Java has room for everything outside the heap.
• Java's own reference notes that servers often set -Xms equal to -Xmx, which starts the heap at full size. A lower -Xms lets the heap start small and grow, which suits a server that is often quiet. Either way, -Xmx is the number that decides whether the world fits.

Signs you need more memory, and signs you do not

Check that memory is the problem before buying more of it. Low TPS (ticks per second) on a server with plenty of free memory is a tick-time problem, and more RAM will not change it.

How to lower memory use before you buy more

1. Lower view-distance in server.properties by two to four chunks and restart. It is the largest single lever on loaded chunks.
2. Lower simulation-distance as well, where your version has it. It controls how much of the loaded area is actively ticked, which cuts entity and machine load.
3. Take client-only mods out of the server's mods folder. Minimap, shader-loader and HUD mods do nothing useful on a server, and some crash it outright.
4. If memory use creeps up over days with no new players, restart on a schedule and report it to the pack's author. Steady growth on a quiet server often means a mod is holding on to memory it no longer needs.

What MineXHost's launcher does with your memory

MineXEngine, our launcher, sets the Java memory flags for you from your server's real memory limit; you do not type an -Xmx value. It holds back a share of that limit for everything Java needs outside the heap and gives the rest to the heap. The share is larger on small servers, because Java's fixed costs do not shrink with the box.

So a server with an 8 GB limit runs with a heap of about 6.2 GB. The class-memory part of that reserve is sized from your pack's mod count rather than from the RAM: about 2 MB per mod on top of a 192 MB base, capped at 1 GB, and always kept within the reserve, so on a small plan a very large pack gets less than that formula would give it.

The heap starts at a quarter of its maximum and grows when the world needs it, so a quiet server does not hold memory it is not using. If an out-of-memory error does happen, the recovery steps are the ones our OutOfMemoryError guide describes, and the launcher prints what it changed in your console.

Moving to a plan with more memory is a plan change in your account. The server keeps its files and its world and is resized to the new plan, with the new memory limit taking effect on its next restart.