Short answer: less than you think, and more isn't automatically faster. This is a quick reference for allocating memory correctly, whether you're launching vanilla, running a heavy modpack, or hosting a server.
These are practical starting points, not hard rules. Start on the low end and only raise the allocation if you actually hit stutter or crashes.
| Use case | Typical allocation |
|---|---|
| Vanilla client, default settings | 2–3 GB |
| Vanilla client with shaders / high render distance | 4–6 GB |
| Lightly modded client (10–30 mods) | 4–6 GB |
| Heavily modded client (large modpack) | 8–10 GB |
| Small survival server, 2–5 players | 2–4 GB |
| Community server, 10–20 players | 4–8 GB |
| Modded server, 10+ players | 8–16 GB |
Where the allocation actually happens depends on how you launch the game.
Open Installations, edit your profile, expand "More Options" and set the memory slider or the JVM arguments field directly.
Tools like CurseForge, Prism, or ATLauncher expose a memory slider per instance, so different modpacks can each get their own allocation.
Use -Xms for the starting heap and -Xmx for the ceiling. Setting them equal avoids the JVM resizing the heap mid-game.
32-bit Java can't address more than roughly 1.5 GB. If your allocation isn't taking effect, confirm you're running a 64-bit Java install.
-Xms4G -Xmx4G
A server's RAM needs scale with player count and loaded chunks far more than with the number of plugins installed.
Minecraft's world simulation is largely single-threaded. A server can be starved for performance on a fast CPU with modest RAM, or sluggish on a slow CPU with plenty of RAM.
Paper and Spigot servers commonly run with G1GC-based startup flags (often called "Aikar's flags") designed to reduce garbage-collection pauses on heaps above 4–8 GB.
Chunk generation is one of the heaviest memory and CPU spikes on a server. Pre-generating the map ahead of time smooths this out for players.
Lowering the server's view and simulation distance by even a couple of chunks can meaningfully cut RAM and CPU load with many players online.
java -Xms8G -Xmx8G -XX:+UseG1GC -XX:MaxGCPauseMillis=130 -jar server.jar nogui
Most "just give it more RAM" advice misunderstands how the JVM manages memory.
Past a certain point, extra heap just means the garbage collector has more to clean up in one pass — which can cause longer, more noticeable freezes instead of preventing them.
The OS, launcher, browser, and other background apps need memory too. Leaving Minecraft with every last gigabyte usually causes system-wide stutter, not smoother gameplay.
Frame rate is mostly a GPU and CPU concern. RAM prevents crashes and stutter from memory pressure, but it won't raise your FPS ceiling by itself.
Allocate the smallest amount that runs smoothly for your setup, and only increase it in small steps when you see an actual out-of-memory error or real stutter — not preemptively.
What common memory-related errors actually mean.
The game or server ran out of the memory you gave it. Raise -Xmx a couple of gigabytes at a time, checking whether the crash still happens before raising it further.
This usually points to a memory leak in a mod or plugin rather than too little RAM. Removing recently added mods one at a time will isolate it faster than raising the allocation.
Double-check you're editing the profile you're actually launching, and that you're running 64-bit Java — 32-bit installs silently cap the usable heap.
That's chunk generation, not a RAM shortage. Pre-generating the world or capping the world border reduces these spikes directly.