It is the most dreaded sight for any server administrator: you are playing smoothly, and suddenly the server goes dark. No crash report in the logs, no error message in the console—just a stark notification in your panel: Exit Code 137. If this feels familiar, you have just met the Linux OOM (Out of Memory) Killer.

Contrary to popular belief, Exit Code 137 is not a bug in Minecraft itself. It is a protective mechanism of the operating system. In this comprehensive guide, we will dissect exactly what happens when your server "OOMs," why simply "adding more RAM" isn't always the solution, and how to surgically optimize your entities and configurations to prevent it from ever happening again.

Part 1: Decoding Exit Code 137

To fix the problem, you must first understand the mechanism. In the world of Linux containers (which is what modern hosts like King's Domain use to isolate your server), memory limits are strict.

The Difference Between Heap and Container Memory

There is a fundamental misunderstanding among many server owners regarding how Java uses RAM. You might assume that if you have a 10GB server, you should allocate 10GB to Minecraft. This is a fatal error.

• Java Heap (Xmx): This is the memory explicitly allocated to the Minecraft application for storing blocks, players, chunks, and entities. This is what you see when you run the /gc command.
• Off-Heap / Overhead: Java requires additional RAM to function that is not part of the Heap. This includes the Metaspace (loading code/plugins), Direct Byte Buffers (network compression), Thread Stacks, and the JVM code itself.

The Scenario: Imagine you have a container limit of 8GB. If you set your startup flags to -Xmx8G, the Java Heap takes up the full 8GB. As soon as the JVM tries to allocate even 1MB for a thread or network packet (Off-Heap), the total usage exceeds the container limit.

The Linux kernel detects this violation and intervenes with SIGKILL (Signal 9). It doesn't ask the server to close politely; it instantly terminates the process to save the rest of the node. This instantaneous death is Exit Code 137.

Part 2: The Usual Suspects (Entities & Chunks)

While overhead issues cause immediate crashes on startup, the slow, creeping memory leaks that result in Exit Code 137 after hours of gameplay are almost always caused by Entities and Chunk Loading.

Every Zombie, Villager, Drop Item, and Armor Stand requires memory. However, it's not just their existence that costs RAM—it's their AI. Modern Minecraft versions (1.18+) have incredibly complex AI behaviors. When thousands of entities are active, they churn through objects in the Heap, forcing the Garbage Collector (GC) to work overtime.

"When the Garbage Collector cannot clear memory faster than your entities are filling it, the Heap expands until it hits the limit. If the JVM tries to expand beyond the container's physical RAM, the OOM Killer strikes."

Part 3: Diagnostics with Spark

Before you start changing settings blindly, you need data. At King's Domain, we recommend using the Spark profiler. It is far superior to the default /timings report.

Running a Heap Dump

If your server is running but memory usage is climbing dangerously high, run the following command:

/spark heapsummary

This will generate a link breaking down exactly what is inside your RAM. Look for these red flags:

• Huge `char[]` or `byte[]` arrays: Often indicates a plugin text handling issue or massive logs being kept in memory.
• High Entity Count (e.g., 5,000+ Sheep): Players may have built an unregulated mob farm.
• Excessive World Chunks: Your view distance might be set too high for your hardware plan.

Part 4: Specific Optimizations (The Fix)

Now that we understand the cause, let's apply the fixes. These changes are performed in your spigot.yml, bukkit.yml, and config/paper-world-defaults.yml files.

1. Taming Entity Activation Range

This is arguably the most impactful setting for memory and CPU. Located in spigot.yml (or paper-world-defaults.yml on modern Paper builds), this controls how close a player must be for a mob to "think" (run AI).

Why it matters: If this is set to default (e.g., 32 blocks), and you have 10 players spread out, thousands of mobs are ticking. Reducing this puts distant mobs into a "stasis" mode where they exist but don't consume CPU or generate memory garbage.

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 48
  misc: 8
  tick-inactive-villagers: false

2. Simulation Distance vs. View Distance

In server.properties, you will find view-distance. In spigot.yml (or server.properties in 1.18+), you will find simulation-distance.

• View Distance: How far a player can see. This consumes RAM (storing chunk data) and Bandwidth (sending it to players).
• Simulation Distance: How far away the server processes game logic (furnaces smelting, crops growing). This consumes CPU and RAM.

The Strategy: You can keep View Distance high (e.g., 8 or 10) so the world looks nice, but lower Simulation Distance to 4 or 5. This prevents the server from processing thousands of active chunks that players aren't even interacting with.

3. Optimization Configs for Paper

If you are running Paper (which you should be), the paper-world-defaults.yml file offers aggressive optimizations that don't impact gameplay quality.

Recommended settings to reduce memory churn:

collisions:
  max-entity-collisions: 2 # Prevents mob cramming lag
chunks:
  prevent-moving-into-unloaded-chunks: true
entities:
  armor-stands:
    do-collision-entity-lookups: false
    tick: false # Static armor stands shouldn't tick!
  spawning:
    alt-item-despawn-rate:
      enabled: true
      items:
        cobblestone: 300 # Despawn trash items faster
        netherrack: 300
        sand: 300

Part 5: Startup Flags & Overhead Buffers

Optimization isn't just about removing things; it's about initializing Java correctly.

The Golden Rule of Allocation

Never allocate 100% of your container's RAM to the Heap (Xmx). You must leave room for the overhead we discussed in Part 1.

Recommended Buffer:

• 4GB - 8GB Server: Leave 1GB buffer. (e.g., On an 8GB plan, set Xmx to 7168M).
• 10GB+ Server: Leave 1.5GB - 2GB buffer.

Aikar's Flags: The Standard

Using the default Java Garbage Collector (ParallelGC) often leads to "Stop-the-world" pauses, where the server freezes to dump memory. Aikar's Flags switch the server to G1GC, which cleans memory in small, concurrent steps.

While listing the full flag set is beyond the scope of this single paragraph, the key takeaway is that G1GC reduces the massive RAM spikes that trigger the OOM Killer. At King's Domain, our one-click startup flag selector automatically applies these industry-standard optimizations for you.

Part 6: The King's Domain Advantage

You can spend hours tweaking configuration files, or you can host with a provider that understands these bottlenecks at the hardware level.

Many budget hosts oversell their nodes. They put 128GB of servers on a machine with only 128GB of RAM. If everyone logs in at once, the system OOM Killer starts terminating servers randomly to save the OS.

At King's Domain, we do not oversell. When you buy an Extreme Plan with 12GB of RAM, that memory is reserved solely for you. Furthermore, our panel includes tools to:

• Automatically detect crash types.
• Pre-generate chunks (reducing runtime RAM usage).
• Apply Aikar's Flags with a single toggle.

Conclusion

Exit Code 137 is a warning. It tells you that your server is trying to do more than its resources allow. By distinguishing between Heap and Overhead, optimizing your entity activation ranges, and ensuring you aren't allocating 100% of your RAM to Xmx, you can banish these crashes for good.

Server stability is a balance of resources and configuration. If you have optimized everything and are still hitting limits, it might simply be time to upgrade your capacity. But for 90% of cases, the steps above will stabilize your world.