Project Zomboid Server Memory 101: End the Lag and Prevent Crashes

A comprehensive guide to optimize your PZ server's memory usage and performance

Is your Project Zomboid server slowing to a crawl or crashing unexpectedly? Don't worry, survivor – we've got you. To keep your server running smoothly, you'll need to give it enough RAM (roughly 0.5 GB per player is a good rule) and address any memory leaks or heavy mods that could be causing issues. In short: allocate more memory if you're hitting the default cap, monitor usage during long sessions, and trim or tweak mods that hog resources.

⚡ Quick-Start Guide

Check Your RAM Needs: Estimate 0.5 GB of RAM per player slot on your server. For example, a 10-player server should have ~5 GB allocated. Ensure your host machine has some extra beyond this for the OS.
Increase Server Memory Allocation: If you see OutOfMemoryError in your console, edit the server launch file to raise the Java heap limit. Open ProjectZomboid64.bat (or .json on Linux) and find -Xmx (the max memory). Bump it from the default (e.g. 2048m or 4096m) to a higher value like 8192m (8 GB). Save and restart the server.
Monitor for Memory Leaks: Use the in-game Admin Panel → Show Statistics to watch server memory in real time. If "Used MB" climbs continuously and never comes down, you likely have a mod-related memory leak. Restart the server periodically to clear memory and remove or update the offending mod.
Optimize Mods & Settings: Uninstall mods you're not using, especially large item packs that add tons of textures (e.g. big weapon packs). Encourage players to disable Double-size Textures and lower settings on their end. Fewer loaded textures = less RAM usage on both server and client.
Upgrade or Offload If Needed: For heavily populated servers (20+ players or lots of mods), consider upgrading the host's RAM or renting a server with more memory. It's better to have overhead than to run at the ragged edge and risk crashes.

🧠 Why Do Project Zomboid Servers Run Out of Memory?

Running a Project Zomboid (PZ) server means simulating an entire zombie-infested world, often with many players – all of which lives in your computer's RAM. The game is written in Java, which uses a heap for memory. By default, PZ servers historically only used a small heap (2 GB by default in early Build 41, increased to ~3–4 GB later). That default is fine for a vanilla server with a few players, but it can be far too low for bigger adventures.

Typical reasons for memory problems:

Too Many Players or Zombies: Each player and zombie consumes memory (pathfinding data, their inventories, etc). PZ's default 2–4 GB cap can get hit with just a handful of active players in densely populated areas. The moment the server needs more memory than the cap, Java will throw an error and crash your server.
Mods, Mods, Mods: Mods can drastically increase memory usage. New items and textures? They all stay in memory once loaded. For example, the popular Brita's Weapon Pack mod adds hundreds of new items – a modded server can easily use several extra GB of RAM just to hold these assets.
Memory "Leaks": Sometimes the issue isn't just volume but memory not being freed properly. A memory leak means the game isn't releasing RAM it no longer needs. PZ Build 42's unstable branch had a known leak causing RAM usage to spiral over time, leading to serious lag spikes for long-running servers (the devs marked this a high-priority fix). Even without a true leak, running a server for hours can gradually accumulate cached data (map chunks, etc.) that isn't cleared until a restart.
Java Garbage Collection Pauses: Java will periodically clean up unused objects (garbage collection). If your heap is very large (say you allocate 16 GB when only 4 GB is needed), garbage collection runs less often but will take longer each time – possibly causing noticeable stutters. One dev noted that giving the game vastly more RAM than needed can make performance worse due to longer GC cycles. Thus, more is not always better beyond a point.

In short, servers run out of memory either because they genuinely need more for what you're throwing at them, or because something is preventing RAM from being recycled. Next, we'll tackle how to raise the memory limits and keep an eye on usage.

⚙️ How to Allocate More Memory to Your PZ Server (Step-by-Step)

Fortunately, Project Zomboid servers can use more RAM – you just have to tell Java to allow it. By default it might be capped (e.g. 2 GB or 4 GB), but you can increase this cap via command-line arguments or config files.

Decide on an Appropriate Memory Amount: Using the earlier rule, calculate what you need. Let's say you expect ~8 players and some mods – around 4–6 GB is a good target. It's wise to stay below your machine's total RAM (if you have 8 GB total in your PC, don't allocate all 8 to the server or your OS will starve).

📊

Project Zomboid Server Statistics Panel

Figure: The in-game Statistics panel (accessed by an admin) shows Server memory usage. "Max" here was set to ~8589 MB (~8 GB), and ~1783 MB is currently used. This server has plenty of headroom for more players or mods.
Edit the Launch File to Increase Xmx: The "Xmx" parameter is what sets the max heap size for Java. There are two common ways to edit it:

▶ Dedicated Server (SteamCMD or manual):

In your server install folder, find start-server.bat (Windows) or start-server.sh (Linux) or a ProjectZomboid64.json config. Open it with a text editor. Look for -Xmx####m. For example, it might say -Xmx2048m (which means 2 GB). Change that number to your desired amount. For 6 GB, use 6144m (just multiply GB by 1024, since it's in MB). Save the file.

▶ Hosted via Game's Menu (Host option):

If you launch a server through the game's GUI, there's a Server Memory dropdown in the hosting settings. Make sure it's set to the value you want (the game now shows options up to 16 GB). The devs increased the default to 4 GB for 64-bit systems in late Build 41, but if you have more players, bump it up accordingly before clicking "Start".

▶ Launch Command Alternative:

If you're running via a shortcut or command line, you can add -Xmx6G (for 6 GB, for example) to the launch parameters.
Verify the Change: When your server starts, check the logs or the stats panel in-game. The server log will often print the heap size at start. In the admin statistics UI, look at "Max (MB)" for the Server – it should reflect the new limit (e.g. ~6144 MB for 6 GB). If it's still showing the old value, then the parameter change didn't take effect – double-check the file edits.
Run a Stress Test: It's wise to simulate a heavy load to ensure the new memory allocation is sufficient. Invite a few friends, spawn a horde, or drive fast through Louisville. Watch the server's memory usage. If it stays well below the max, you're golden. If it still maxes out or the Used MB climbs dangerously close to Max MB under peak activity, consider allocating a couple more GB or removing some strain (fewer zombies or mods).
Don't Set it Excessively High: You might think "I have 32 GB, why not give the server all of it?" But as mentioned, an overly large heap can degrade performance. Plus, if something is leaking, giving it 20 GB just means it takes longer to crash – and when it does, it might freeze your entire machine. Allocate what you need with a little overhead. For most cases, servers run great in the 4–8 GB range. Only the most heavily modded 16+ player servers should need 12+ GB.

By increasing the memory available to Java, you eliminate the immediate OutOfMemory crashes that happen at 2 GB. Your server can now stretch its legs and handle more players and mods. However, this doesn't mean "infinite" memory – if something is consuming RAM rapidly (like a memory leak or unoptimized mod), you've just delayed the issue. That's where monitoring comes in.

📊 Monitoring Server Memory and Catching Leaks

After you allocate a healthy amount of RAM, it's important to keep an eye on how it's used. This can warn you of problems before they crash your server. Project Zomboid offers some built-in tools for this, and there are external tricks too.

📈 In-Game Statistics Panel

As shown earlier, PZ has a live statistics UI for admins. Use /stopwatch in chat or the debug icon (if enabled) to open it. The key fields:

Memory (Server): Free/Used/Total/Max – This is your server's heap. "Used" is what's currently used, "Free" is unused within the current allocated chunk, "Total" is current allocated (used+free), and "Max" is the max it can grow to (your Xmx setting).
Keep an eye on Used vs Free. Used will go up and down as the game runs. It's normal for Used to increase for a while (as more of the map loads, more zombies spawn, etc.) and then drop when Java GC runs or players leave an area.
Warning sign: Used steadily climbing and Free approaching zero, without ever dropping, even when things should calm down – that suggests a memory leak or at least that the server is not freeing something it should. If Used hits Max, the next allocation fails => crash.

💻 Operating System Monitoring

You can also watch the server's RAM usage via your OS:

On Windows, open Task Manager -> Details -> find ProjectZomboidServer.exe (or Java process) and observe its memory.
On Linux, use htop or top in the terminal. Make sure to sum the RES memory if the Java process spawns threads (or check the single process if it's one).
Compare this with in-game stats; they should roughly match (though OS will count some overhead). If you see the process using way more memory than the heap (e.g. heap is 4 GB but process uses 6 GB), that extra might be off-heap allocations (like loaded native libraries or the OS file cache). Usually, though, PZ's main usage is within the heap.

⚠️ Logs and Warnings

If the server is nearing OOM, sometimes you'll catch warning signs in the console:

The server might start logging garbage collection messages or "memory low" warnings (if any configured).
If a crash happens, the log will show the dreaded exception: Exception in thread "XYZ" java.lang.OutOfMemoryError: Java heap space or similar. The thread name (PolyPathThread, LoadChunk, etc.) can hint at what was happening when memory ran out (pathfinding, chunk loading).

🔄 Regular Restart Schedule

One pragmatic solution server owners use: schedule automatic restarts during off-peak hours (e.g., 5 AM daily). This is almost mandatory for servers with memory-hungry mods or slight leaks. Restarting the server clears all runtime memory, essentially "garbage collecting" everything. As a player, I've been on modded servers that announce a daily reboot – it dramatically reduced crash frequency. It's a bit like letting your server take a quick nap to refresh itself.

🔍 Using VisualVM or Profilers

If you're very technically inclined, you can attach a Java profiler (like VisualVM) to the server process. This lets you see detailed memory usage by object type, so you could potentially identify what's eating memory (e.g. thousands of IsoObject instances or something). This is overkill for most, but it's how the developers themselves find leaks. For example, a leak might show a continuously growing list of world objects that never get removed. If you pinpoint it's from a mod, you can report it to the mod author.

🧩 Identifying Problematic Mods

Most often, if you have a leak or just excessive usage, a mod is the culprit. Some strategies:

Remove mods one by one (or in batches) and run the server for a while to see if the issue stops. Start with mods known to be heavy (huge item packs, total conversions).
Check mod discussions on Steam/Reddit. Often, if a mod has a leak, other users will be screaming about it. Example: A mod that spawns an ever-increasing number of invisible objects would cause memory to grow unbounded – likely someone has noticed.
Ensure all mods are up-to-date. A memory issue might have been fixed in a newer version. (On the flip side, occasionally a mod update introduces a leak, so if issues started after an update, consider downgrading as a test.)

🧟 Watch for Zombie Population Setting

One subtle server setting that affects memory is zombie population. If you set insanely high zombie counts, the server has to track more zombie objects at once. That's more memory for AI states, positions, etc. A user in Indie Stone forums noted having "5-10k zombies in one area dropped FPS and likely strained memory". The game can handle a lot of zeds, but if you push it to extremes, ensure your memory is scaled up accordingly.

🚀 Preventing Lag Spikes and Improving Performance

Memory isn't the only factor in server performance, but it's closely intertwined. Often, what we perceive as "lag" or low FPS on the server side can be related to memory pressure or garbage collection.

💾

Use 64-Bit Java

Always run the server with the 64-bit Java runtime. 32-bit will not only cap you at ~1.5–2GB usable memory but also handle memory less efficiently. The PZ server distributed via Steam comes with a bundled 64-bit Java – use that by default (which it should out of the box on 64-bit OS). The game devs dropped 32-bit support for good reason.

🖼️

Texture Compression (Clients)

While this is a client setting, it indirectly helps servers in modded games. If all your players use compressed textures, the server can send them data faster and is less likely to bog down waiting on a player with high VRAM usage. It doesn't reduce server RAM directly, but it reduces network and disk strain.

💻

Avoid Running Other Memory Hogging Apps

If you host the PZ server on your personal PC while also playing on it (or streaming), be mindful of total RAM in use. If your OS starts swapping (using disk as fake RAM) because you gave PZ server too much, everything will lag. I've had a situation where my PC hosting a server started stuttering because a Chrome tab ate RAM and pushed the server to swap – the server's tick rate went down, and all players experienced lag.

⚡

CPU vs RAM

Note that PZ server is quite CPU-intensive too (zombie AI, physics, etc.). Sometimes "lag" might be CPU starvation rather than purely memory. A telltale sign is if the server's memory usage is fine but you still get lag spikes, check CPU usage per core. PZ is multi-threaded, but heavy computation (like hordes) can max one core. Upgrading RAM won't help there – but a faster CPU or lowering zombie count will. That said, insufficient RAM can also manifest as lag (when garbage collection runs, it can pause the game briefly – players might see a "lag spike" every X seconds if the heap is thrashing).

⚙️

GC Tuning (Advanced)

By default PZ uses whatever Java's default GC is (which for modern Java is the G1 Garbage Collector). G1 is usually fine for games. But if you're adventurous, you can try flags like -XX:+UseZGC (a new GC) or tweak G1 settings (like target pause times). There is no one-size-fits-all and the benefits are minor unless you really know what you're doing and have a specific issue (e.g., consistent 200ms GC pauses you want to reduce).

🆕 Build 42 Performance Improvements

Let's talk about the improvements in Build 42 and how they affect performance. The devs made huge strides in optimizing multiplayer in late 2024. They specifically mentioned that Build 42 should yield "a solid framerate even on 4K, or on furthest zoom", which was nearly impossible in Build 41. How did they do this? By caching more data in memory, especially on the GPU side. Essentially, they trade memory for speed: the game preloads and keeps more textures and world data ready, so it doesn't have to constantly stream from disk.

This is awesome if you have the hardware – most players will see much smoother gameplay. But it can bite those with older hardware:

If your GPU has very limited VRAM (say 1GB or less), it might fill up fast. Then the game starts using regular RAM to store graphics assets (which is slower). If both fill up, you'll get crashes or severe slowdowns.
Some people reported that on Build 42 unstable, their game (or server with a GUI) crashed on the main menu due to high RAM usage – possibly the menu was rendering the new animated background or caching something heavy. The devs acknowledged such issues on lower-end cards and marked it as a priority fix.

The good news is The Indie Stone is aware and they plan to allow disabling the new fancy caching if needed. So by the time Build 42 is fully stable, we expect an option like "Legacy performance mode" for those who prefer the old behavior on older machines.

📏 How Much RAM Is Needed for X Players? (Planning Chart)

By popular demand, here's a quick reference for planning your server's RAM:

📊

Project Zomboid Server RAM Requirements

Chart of recommended Project Zomboid server RAM vs number of players (0–30 players)

Rule of thumb: ~0.5 GB RAM per player plus 2GB base requirement

As you can see, the relationship is pretty linear. If you have a tiny co-op server (2–4 players), you can get away with 2–3 GB. A medium group of 8–10 players fares well with ~4–6 GB. Large servers (20–32 players) you're looking at 10–16 GB for safety. These estimates include some typical mods and normal zombie populations. Always err on a bit more if you plan heavy mods.

Remember, this rule (0.5 GB per player) is a guideline. Actual use might be lower, but having that buffer prevents issues. And if you mod heavily, that per-player footprint goes up.

One more consideration: Disk usage vs RAM. PZ loads map chunks from disk into RAM as needed. Faster disks (SSD/NVMe) make those loads quicker (reducing lag when players roam new areas). If you have limited RAM, having a fast disk at least helps swap things in/out faster when needed. But generally, you want enough RAM to keep recently used areas in memory so the server isn't constantly reading from disk.

👥 Real Experiences & Analogies

Running a PZ server is a lot like running a long-term camp in the apocalypse. If you only have a small camp (few friends) and not many supplies (mods), you can survive on the bare minimum resources. But if you invite the whole neighborhood and start stockpiling an armory of weapons (lots of players and mods), you better have built a big storage shed (more RAM) or things will overflow into chaos!

I once helped admin a heavily modded server with around 15 players. Initially, we left it at default memory. Everything was fine on day 1. By day 3, as the map sprawled with player-built bases and huge hordes were drawn in Louisville, the server started hitching badly. Eventually it crashed one evening when a horde event triggered in downtown. Checking the logs, we saw the dreaded OutOfMemoryError. It literally ran out of juice to simulate the world. We bumped the server to 8 GB, and instituted a policy of restarting it every morning at 5 AM. After that, no more crashes – and the lag spikes became rare. It was like giving our server a good night's sleep each day, plus a stronger brain to handle the zombie chaos.

Action Steps Recap: Allocate sufficient RAM, keep an eye on usage, and treat memory-hog mods with caution – your undead apocalypse will thank you with stable gameplay.

📚 Further Resources

Project Zomboid Official Dedicated Server Guide – [[Project Zomboid Dedicated Server Guide]] on the PZ Wiki (covers installation, basic settings, including memory adjustments).
Indie Stone Forums – Support Section – The Support forum on theindiestone.com is full of Q&A; search there for "memory" to see dev responses on specific issues (like memory leaks in B42).
Community Performance Tips – Check out Reddit's r/projectzomboid guides and Steam Community guides for "performance" or "server tips." Many players share up-to-date advice on mods and Java tweaks that worked for them.
Java Tuning Documentation – If you want to delve into garbage collection tuning or understand JVM flags, Oracle's documentation on HotSpot GC is a great resource (though very technical).

Good luck and happy surviving – may your server have zero zombie interruptions and plenty of memory for all your stories!

Patch-History

Date	Change Note	Impact on Servers
Oct 2013	64-bit only interim build due to 3D model memory issues	32-bit systems could no longer host new versions – heralded growing memory needs.
Feb 2022	Default Java heap raised from 2GB to 3GB (patch around Build 41.66)	Reduced OutOfMemory crashes for modded and MP servers; fewer manual tweaks needed for average play.
Dec 2022	Build 41.78 final – Default "Host" server memory = 4GB on 64-bit	Acknowledged more players using MP; ensured new hosted servers weren't under-allocated by default.
Dec 17, 2024	Build 42 Unstable released – Massive performance update using caching	Huge FPS boost for most, but introduced memory leak and higher GPU RAM usage; small servers saw less lag, but low-end hosts reported new crashes.
Jan–Feb 2025	Build 42.1x patches	Memory leak fixes deployed; added optimizations for low VRAM cards. Early adopters reported stability improving. Developers mention possible toggle for caching if issues persist.
May 2025	Ongoing Build 42 testing	Memory usage now higher than B41 overall (due to new features), but manageable with 64-bit and proper allocation. Admins advised to allocate 8GB+ for heavily modded 42 servers.