When the whole factory runs slowly, first determine whether simulation speed is low on the server or whether one player's computer cannot follow it. A larger VPS helps only the first case, and only when its resources address the actual limit. Low graphics FPS and a slow map download need different investigations.
This guide concerns an existing Factorio 2.x headless server on Ubuntu 24.04 and matching PC clients. Commands assume the installation guide's layout: service factorio, executable /opt/factorio/bin/x64/factorio, runtime /srv/factorio. Substitute the effective paths from your service. Keep the original factory unchanged while diagnosing.
Classify the slowdown#
Ask two players to describe the same moment: is the factory itself slow, is only the picture choppy, or is someone stuck at Catching up? Record whether the problem started after factory growth, a mod change, a server move or a client update.
| Observation | First comparison |
|---|---|
| One player has low FPS, while simulation keeps pace | That client's graphics workload and settings |
| Every connected player sees slow production and movement | Server simulation and host contention |
| One player repeatedly catches up or falls behind | That client's ability to simulate this exact factory |
| Actions arrive late but simulation counters stay normal | Network statistics, packet loss and route |
| Brief freezes rather than continuous slow motion | Timing spikes, saves and concurrent host work |
The official performance guide distinguishes rendered frames from world updates. A headless server does not render a player's screen. Lowering that player's graphics settings can improve their display; it does not reduce the server's factory simulation.
Capture a reproducible moment#
On a connected client, open F4 and enable show-fps, show-time-usage and show-multiplayer-statistics. The debug reference documents these controls. If configured on the Debug tab, press F5 to display the selected debug overlays. Record a short sample during ordinary play and another during the reported slowdown. A screenshot of a quiet factory after everyone stopped building can miss the trigger.
The timings shown on a player's computer describe work there; do not relabel them as direct server CPU measurements. Compare that client's results with another player's and with host observations at the same time. Avoid enabling every debug overlay: additional instrumentation and unreadable numbers make comparisons harder.
At the normal target of 60 updates per second, one update has about 16.67 milliseconds. Treat that as a timing budget, not a promise that one named subsystem must stay below an arbitrary threshold. For steady slowness, inspect sustained costs; for intermittent freezes, preserve the spikes and the action that triggered them.
Record the full game version and enabled mod versions. A comparison between different releases, startup settings or expansion configurations is not a hardware comparison.
Check the host while the problem occurs#
Run these read-only checks on the server:
sudo systemctl show factorio -p MainPID -p ExecStart
/opt/factorio/bin/x64/factorio --version
sudo journalctl -u factorio -n 100 --no-pager
free -h
vmstat 1 10
df -h /srv/factorio
Use the reported PID in top and inspect the service's actual command line if the printed binary is different. Check whether backups, compression, other game instances or provider CPU contention coincide with the slowdown. Compare several samples; the first vmstat report is a longer-term summary, not just the latest second.
Memory exhaustion, swapping and storage errors are actionable findings. Free RAM remaining on the machine is not evidence that adding more RAM will accelerate simulation. Likewise, an average CPU percentage across many virtual cores can hide a constrained part of the workload. Keep host evidence alongside game timings rather than choosing a VPS by total core count alone.
Do not benchmark a second copy on the same busy production machine and then attribute the resulting contention to Factorio itself. Arrange a maintenance window or use a separate test host with recorded specifications.
Treat catch-up as its own case#
A joining client receives a factory state and must reach the running simulation. A faster download can reduce the initial gap, but it cannot make a client simulate a factory faster indefinitely. Test the affected player's machine with a private copy of the same save and matching environment. If it already struggles locally, changing the server's firewall or raising upload limits will not cure that computation limit.
If local simulation is healthy but joining fails, preserve client and server logs and follow the connection investigation. Compare network conditions before changing the factory. A temporary pause agreed with current players can help distinguish joining backlog from a permanent performance problem; it is not evidence that the client can keep pace afterwards.
Compare one controlled change#
Keep a dated save copy, exact binary, mod ZIPs and settings. On an isolated installation, --benchmark can run a save for a chosen number of ticks and repeated runs; check the installed --help and the command reference. Select explicit config and mod directories so the test cannot use production's writable data. Record the command, build, hardware and unchanged input before comparing results.
A benchmark measures that simulation workload. It does not measure a player's graphics, internet path or successful multiplayer join. Reject comparisons that use a smaller factory, remove major mods or switch hardware and software simultaneously.
Use profiling to choose a change: inspect an expensive mod or factory subsystem, retain the original and alter only the test copy. Avoid deleting mods or rebuilding entire logistics networks on the live save merely because an old optimization post recommends it. Wube's 2.0 optimization notes show that subsystem costs and threading change between releases; historical advice is a hypothesis to test.
For several supported game instances, Nexardo’s panel and agent for your own Linux infrastructure can keep administration in one place. Instance controls do not replace profiling this factory or establish that a manually installed service has been adopted.
Accept a change only after the same factory shows an improvement under comparable conditions and players can join, play, save and reconnect normally. Retain the before/after record even if the result is “no improvement”: it prevents buying resources for the wrong bottleneck.
