How to Monitor CPU, RAM, and Network on a MU Online Server

A MU Online server can look healthy right up until the moment it freezes in the middle of a packed Castle Siege. The difference between an administrator who fights fires and one who prevents the problem lies in the continuous monitoring of three resources: CPU, RAM, and network. Without those numbers, you operate in the dark — restarting the server "just in case," blaming the provider for lag that is actually a saturated core, or paying for a bigger VPS without knowing whether the real bottleneck is something else. This tutorial shows how to observe each resource, understand what's normal, keep a history, and turn data into decisions: when to optimize, when to restart, and when to actually migrate machines. All the limits and values mentioned are examples and vary by provider/version; the method of looking is what matters.

Prerequisites

• A MU server already running (if you still need to build one, start with the guide on how to create a MU Online server).
• Administrative access to the VPS: RDP on Windows Server or SSH on Linux.
• Permission to install lightweight monitoring utilities (optional, but recommended for history).
• An idea of which processes belong to your server: GameServer, ConnectServer, JoinServer, the database (SQL Server/MySQL), and the website.
• A known peak time (Castle Siege, invasion, event) to compare the metrics under real load.

Understand the three resources and how MU uses them

Before collecting any number, you need to know what each metric means in the context of a MU server, because the game stresses each resource in a different way.

The most misunderstood point is the CPU. Many GameServer versions are heavily single-threaded: a single core does the heavy lifting of the game logic. This means total CPU can read 25% while a specific core is at 100% and becoming the bottleneck. That's why looking only at the overall average is misleading — you need to see per-core usage.

Step 1 — Live monitoring on Windows Server

Most MU servers run on Windows Server. Start with the native tools, which cost nothing and aren't heavy.

Task Manager (Ctrl+Shift+Esc) gives the immediate view. On the Performance tab, right-click the CPU graph and choose "Change graph to → Logical processors" to see each core separately — that's how you catch a saturated core.

Resource Monitor (resmon) is the next level: it shows which process consumes CPU, RAM, and network in real time. Filter by the GameServer process and see exactly how much of each resource it pulls.

For a quick command-line collection, PowerShell does the job:

# CPU usage by process (top 5)
Get-Process | Sort-Object CPU -Descending |
    Select-Object -First 5 Name, CPU, @{N='RAM(MB)';E={[math]::Round($_.WS/1MB,1)}}

# free physical memory on the system
Get-CimInstance Win32_OperatingSystem |
    Select-Object @{N='LivreMB';E={[math]::Round($_.FreePhysicalMemory/1KB,0)}},
                  @{N='TotalMB';E={[math]::Round($_.TotalVisibleMemorySize/1KB,0)}}

Step 2 — History with Performance Monitor

Looking at the current instant only helps when the problem is happening right in front of you. To diagnose crashes that happened in the small hours, you need history. Windows Performance Monitor (perfmon) records this in a Data Collector.

1. Open perfmon and go to Data Collector Sets → User Defined.
2. Create a new manual collector, of type "Performance Counter."
3. Add the essential counters:

• Processor(_Total)\% Processor Time and each core instance
• Memory\Available MBytes
• Memory\Pages/sec (indicates paging — the higher, the worse)
• Network Interface(*)\Bytes Sent/sec and Bytes Received/sec

1. Set the sampling interval (example: 30 seconds) and the log location.
2. Start the collector and leave it running for days.

Then you just open the recorded log and compare the behavior during event times with the quiet ones. That's how you find out whether Tuesday's crash was CPU, RAM, or network.

Step 3 — Monitoring on Linux servers

If your MU runs on Linux (common in modern seasons and mobile emulators), the native tooling is excellent. For the live view, htop shows per-core CPU, RAM, and swap in a single, readable panel. Install it with your distro's package manager and run:

htop

For one-off numbers in scripts, vmstat and free are direct:

free -h            # RAM and swap in a readable format
vmstat 1 5         # CPU, memory, and IO every 1s, 5 samples

The si/so column in vmstat (swap-in/swap-out) is the red flag that RAM has run out and the system is using disk as memory — that's when the game stutters. For network, iftop or nload show real-time bandwidth per interface.

Step 4 — Measure the network and packet loss

Network is the most neglected resource and the most frequent cause of "mysterious lag" when CPU and RAM are fine. Two things matter: bandwidth (are you filling the link?) and loss/latency (are the packets arriving cleanly?).

For bandwidth, the network counters already covered are enough. For latency and loss, test from a player's perspective with a continuous ping to the server's IP:

# 100 packets; watch the loss percentage in the final summary
ping -n 100 SEU.IP.DO.SERVIDOR      # Windows
ping -c 100 SEU.IP.DO.SERVIDOR      # Linux

Consistent packet loss above zero already causes teleporting and in-game delay. If loss only appears at peak times, the bottleneck is saturated bandwidth; if it appears all the time, it may be a routing issue or the provider itself. Tools like mtr (Linux) or pathping (Windows) show at which hop of the route the loss begins.

Step 5 — Continuous collection with history and graphs

For serious servers, it's worth having a lightweight tool that collects all three metrics continuously and draws graphs over time. The concept is always the same: an agent collects CPU, RAM, and network at regular intervals and a dashboard keeps the history. A homemade PowerShell script is already a start, writing a CSV you can open later in any spreadsheet:

# coleta-metricas.ps1 — records CPU, free RAM, and network every 60s
$csv = "D:\Monitor\metricas.csv"
if (-not (Test-Path $csv)) {
    "DataHora,CPU_Pct,RAM_LivreMB,NetKBps" | Out-File $csv -Encoding UTF8
}

while ($true) {
    $cpu = (Get-CimInstance Win32_Processor | Measure-Object -Property LoadPercentage -Average).Average
    $ram = [math]::Round((Get-CimInstance Win32_OperatingSystem).FreePhysicalMemory/1KB,0)
    $net = (Get-Counter '\Interface de Rede(*)\Bytes Total/s' -EA SilentlyContinue).CounterSamples |
           Measure-Object -Property CookedValue -Sum | Select-Object -Expand Sum
    $netKB = [math]::Round($net/1KB,1)

    "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss'),$cpu,$ram,$netKB" | Out-File $csv -Append -Encoding UTF8
    Start-Sleep -Seconds 60
}

Schedule that script to start with the server and you'll have weeks of history taking up just a few megabytes — enough to spot trends, like RAM that drops a little each day (a memory leak) or the network spike that always coincides with an invasion.

Step 6 — Define thresholds and alerts

Monitoring without alerts is just collecting data nobody looks at. Define thresholds for the three resources and turn them into notifications. Example values (adjust to your reality):

A simple alert can fire a webhook to the team's Discord when a threshold is crossed. What matters is that the alert reaches you before the player complains — mature monitoring is when you already know about the problem when you open the chat.

Step 7 — From data to decision

Collecting is half the road; the value comes from interpretation. Some classic patterns and what to do:

• One core always at 100%, the rest idle: the GameServer's single-thread bottleneck. Optimize heavy scripts/events, reduce excessive spawns, or consider splitting subservers into separate processes.
• RAM dropping continuously until it runs out and the service restarts: likely a memory leak. Identify the guilty process in the history and plan a scheduled preventive restart until you fix it.
• Network saturated only at peak: not enough bandwidth for the player count; time to talk to the provider or size it better.
• Everything calm but players lagging: look at packet loss and latency — the problem is network/routing, not the machine's resources.

Common errors and fixes

Launch checklist

• CPU usage visible per core, not just the average
• Free RAM and paging (swap/pages/sec) being watched
• Network bandwidth and packet loss measured under real peak
• History collector running 24h (perfmon, CSV, or a lightweight tool)
• MU processes identified (GameServer, ConnectServer, database, website)
• Warning and critical thresholds defined for all three resources
• Automatic alert (Discord/email) firing when a threshold is crossed
• Comparison made between event time and quiet time
• Decision to optimize/restart/migrate based on data, not guesswork

With CPU, RAM, and network under continuous observation, you stop reacting to crashes and start anticipating them. The history turns every server event into a lesson and every infrastructure decision — optimize, restart, or migrate — into something based on real numbers, not a hunch.

Frequently asked questions