How to reduce GameServer memory usage on your MU Online server

A MU Online GameServer that consumes memory in an ever-growing, uncontrolled way will eventually crash the process or force restarts, dropping the experience for hundreds of players right at peak time. Reducing and controlling memory usage requires methodical diagnosis — guessing at settings without understanding where the consumption comes from won't work. This tutorial walks through everything from identifying leaks to practical optimizations in maps, events, the database, and restart scheduling.

Understanding where GameServer memory consumption comes from

The GameServer allocates memory mainly for: geometry and collision of each loaded map, character and item structures for connected players, event queues and monster spawns, database query cache, and network buffers for packets in transit. High but stable consumption isn't necessarily a problem; the real red flag is when consumption keeps growing continuously and doesn't return to normal after the player count drops.

Telling normal consumption apart from a memory leak

Tools to monitor consumption over time

On Windows, Task Manager shows instantaneous consumption, but real diagnosis requires tracking the trend. Set up Performance Monitor (perfmon) to log the GameServer process's memory usage every 5 minutes, or use Sysinternals' Process Explorer for a detailed view of handles, threads, and private versus shared memory.

# Simple collection example via PowerShell, logging memory usage every 5 minutes
while ($true) {
  $proc = Get-Process -Name "GameServer" -ErrorAction SilentlyContinue
  if ($proc) {
    "$(Get-Date) - WorkingSet: $($proc.WorkingSet64 / 1MB) MB" | Out-File -Append memoria_gameserver.log
  }
  Start-Sleep -Seconds 300
}

Isolating the cause: testing with a minimal configuration

If a leak is suspected, the most reliable test is running the GameServer in a staging environment with a minimal configuration — no custom scripts, no third-party events, just the emulator's core with a few active maps. If memory consumption stays stable in this scenario, the cause lies in a customization; if it still grows, the problem is in the core or the base configuration.

Reducing unnecessarily loaded maps

Every active map consumes memory for geometry, collision mesh, and spawns, regardless of whether players are present. Review the list of enabled maps in the GameServer configuration and disable:

• Seasonal event maps outside their corresponding season (a Halloween map in March, for instance).
• Test or development maps left active in production by mistake.
• Rarely visited maps that could instead be enabled on demand via a GM command.

Optimizing custom events and scripts

Poorly implemented events (loops with no object cleanup, lists that grow without removing old entries, timers that are never canceled) are the most common cause of leaks on customized servers. When reviewing event scripts, check specifically whether: temporary objects (event monsters, special drop items) are destroyed correctly at the end of the event, event listeners are unregistered when no longer needed, and data structures (lists, dictionaries) used to track participants are cleared at the end of each round.

Tuning the database query cache

Many emulators keep an in-memory cache of frequently accessed data (items, monster configuration, drop tables) to reduce database queries. A poorly sized cache — larger than necessary or without expiration — consumes memory without a proportional performance benefit. Review the cache size parameters in the configuration and adjust them to your server's actual data volume, not the emulator's generic default.

Limiting in-memory log history

Some emulators keep log buffers in memory before writing to disk, and an oversized buffer combined with slow disk writes can accumulate memory. Reduce the log buffer flush-to-disk interval and confirm that the destination disk isn't the bottleneck (an SSD is strongly recommended for the logs directory on high-volume servers).

Comparing mitigation strategies

Setting up a scheduled restart as a safe stopgap

While the root cause isn't fixed, a scheduled restart during low-traffic hours (usually overnight) prevents the leak from accumulating to the point of a crash. Set up a scheduled script (Windows Task Scheduler or cron on Linux) that warns players in advance (in-game message and Discord), saves the necessary state, and restarts the process in a controlled way.

#!/bin/bash
# Example of a scheduled restart script during low-traffic hours (Linux)
echo "Aviso: reinício do servidor em 5 minutos" | ./notify_ingame.sh
sleep 300
systemctl restart gameserver.service

Common errors and fixes

GameServer memory optimization checklist

• Memory trend monitoring set up (perfmon/Process Explorer).
• Minimal configuration test performed to isolate the leak's cause.
• Unused maps disabled in the configuration.
• Custom event scripts reviewed for object cleanup.
• Database cache sized according to actual data volume.
• Scheduled restart configured as a stopgap, with advance notice to players.
• Known emulator leak patch applied, if available.

With memory consumption under control, it's worth reviewing the server's overall configuration to make sure other resources (CPU, database, network) are also properly sized — check the MU Online server setup tutorial to review the full infrastructure foundation.

Frequently asked questions