Mindustry Server Optimization Guide (TPS & Lag Reduction)

1. Identifying the Source of Lag (TPS vs Latency)

It is statistically vital to differentiate between network lag (Latency/Ping) and server processing lag (TPS).

Latency (Ping): Players experience teleportation, rubber-banding, or shots hitting behind targets. This is typically a networking issue resulting from insufficient data center bandwidth, a player located continents away from the data center, or DDoS mitigation routing interference. It cannot be fixed via in-game mechanics.

Server TPS Drops: The game fundamentally slows down. Conveyor belts move sluggishly, units respond significantly delayed, and logical processors desynchronize. Mindustry is hard-capped to process the logic loop 60 times per second (60 TPS). If the server console command `status` outputs anything lower than 59, the processor is struggling to compute the sheer volume of game state updates in the required 16.6 milliseconds. This guide focuses entirely on rescuing your TPS.

2. RAM Allocation and Garbage Collection

Because Mindustry runs in a Java Virtual Machine (JVM), every created object (like a discharged bullet or a unit that dies) eventually must be purged back into available system memory through a process called Garbage Collection (GC).

A poorly configured GC creates massive lag spikes (often called GC "hiccups" or "pauses") where the server completely freezes for 100-300 milliseconds. To counter this, you must optimize your Java startup flags in your `systemd` service or executable `.bash` script.

Inefficient Startup Script:

java -jar server.jar

Highly Optimized Startup Script (Requires Java 17+ and 4GB+ RAM):

java -Xms2048M -Xmx4096M -XX:+UseZGC -XX:+ZGenerational -jar server.jar

The flags explained:

• -Xms / -Xmx: Reserves a minimum (`2048M`) and maximum (`4096M`) heap size explicitly. Doing this prevents the OS from having to dynamically resize the heap allocation mid-game, saving CPU strain.
• -XX:+UseZGC: Activates the Z Garbage Collector, designed specifically for low-latency applications like massive game servers. It executes its cleanup almost entirely concurrently, meaning your TPS will not plummet when thousands of dead unit objects are flushed from memory during a massive boss wave.

3. Mitigating Pathfinding Overload

The single most CPU-intensive operation native to Mindustry is enemy AI pathfinding calculations. When hundreds of enemy `Reigns` or `Toxopids` spawn, they must instantly calculate the fastest unobstructed route to the core, avoiding defenses.

If players construct a maze that forces thousands of real-time recalculations (e.g., dynamically closing and opening walls to manipulate AI traffic), the server's CPU thread will instantly choke, diving to 10-15 TPS.

How to Prevent Pathfinding Lag:

• Limit the max enemy spawn caps in your `rules` configuration. Alternatively, adjust map wave rules to spawn fewer, but significantly stronger boss variants instead of thousands of weak tier-1 units.
• Ban or punish players creating "Maze logic loops" that constantly alter pathing geography.
• Utilize massive open-fire zones. The less complex a geography layout is for the A* pathfinding algorithm to parse, the faster the CPU can execute the logic tick and move on.

4. Restricting Unbounded Logic Processors

Mindustry features an incredibly advanced, Turing-complete logic programming block language. Players can theoretically create complex graphical video games inside Mindustry itself using displays and microprocessors.

However, players often write heavily malformed code—infinite `while` loops that continuously check radar data at maximum frequency across the map—generating astonishing processor load. On a public server, 10 players running badly written loop code on massive Hyper Processors will obliterate the server thread.

Administrative Solutions:

Mindustry servers contain internal limits defined in configuration or through permissions. To protect the host, utilize server plugins (like AntiGrief) to restrict the quantity of Hyper Processors an individual user or IP can construct globally. Additionally, limit the number of Instructions Per Tick (IPT) allowed per processor if you are modifying a custom build.

5. Liquid and Item Routing Optimization

Liquid conduits and high-tier item conveyors interact with adjacent blocks dozens of times per second to push inventory. Massively bloated networks consisting of thousands of redundant routers or chained overflow gates are legendary for destroying server performance ("router spam").

To optimize:

• Educate players to utilize Titanium or Plastanium conveyors which transport large batches (bundles) instead of single individual items rendering individually on belts. Batch transport reduces total entity iterations per tick massively.
• Restrict the use of continuous looping setups where items endlessly circle belts without a destination; this keeps item entities loaded forcefully inside the update array instead of resting securely in a core storage variable.
• Utilize Mass Drivers to bypass massive physical transportation logic requirements over long distances.

6. Operating System Level Optimizations

If you have implemented all in-game logic changes, upgraded to ZGC Java 17, but STILL suffer from drops below 60 TPS when your server hits 50+ concurrent players, it's time to analyze your Linux OS directly:

• CPU Frequency Governors: On many Debian/Ubuntu VPS environments, the processor governor defaults to `ondemand` or `powersave`. Mindustry is largely single-threaded, and its execution thread requires absolute maximum boost clocks constantly. Use `cpupower` or modify `/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor` specifically setting them to performance to prevent the CPU from dynamically downclocking during slight lulls in combat.
• Swappiness: If your server overflows RAM entirely and writes memory to the Linux `/swapfile`, the server will freeze for seconds at a time due to disk writing latency. Ensure `vm.swappiness` in `/etc/sysctl.conf` is diminished to `10` or lower, forcing the OS to rely on RAM unless completely desperate.