Dedicated server performance diagnosis without fake tuning values

Start with the symptom, not a tuning number

There is no source-backed universal RAM allocation, restart interval, tick rate, or player-to-core formula in the references used by this page. Do not change an unrelated value because an old hosting post presents it as a guaranteed fix. First identify which layer failed.

This separation prevents a connection problem from being mislabeled as CPU pressure or a wrong-world problem from being “fixed” by replacing a save.

Preserve a clean baseline

Stop the server and copy the active world before changing launch parameters, updating files, or editing sandbox rules. Record the game version, world name, current launch command, port values, and exact symptom. Keep credentials out of screenshots or shared reports.

The maintained server instructions use Steam app ID 2857200 for the dedicated server tool and show launch parameters such as -MaxServerPlayers, -PORT, -QueryPort, -ServerPassword, -AdminPassword, -SteamServerName, and -WorldSaveName. Use the current project documentation for exact syntax. This page does not add undocumented performance flags.

1. Stop the server and copy the active world outside its live folder.
2. Save a redacted copy of the current launch command.
3. Keep the last known-good server files or record how to validate them again.
4. Make one change and assign one observable test.
5. Restore the baseline when the result does not match the hypothesis.

Verify the process and installation

Confirm the dedicated-server executable starts and that only the intended number of instances is running. Review the console and the current server log under the documented Saved/Logs location. A process appearing briefly is not evidence that the server initialized its world or network services.

When an update or installation is suspected, use the maintained SteamCMD instructions and validation flow rather than copying binaries from an unknown archive. Record the first error, not the cascade that follows it. If the error names a missing file, permission, service, or platform dependency, solve that layer before changing gameplay settings.

Separate network checks from simulation checks

The maintained instructions show a game port and query port in the launch example. The repository's troubleshooting guidance identifies UDP port 7777 as the default game port and recommends confirming the executable is listening, checking for port conflicts, and testing from outside the local network when internet reachability is the goal.

Use this order:

1. Confirm the launch command contains the intended ports.
2. Confirm the server process is listening on those ports.
3. Confirm no second instance or application owns them.
4. Confirm local firewall and router rules match protocol and destination host.
5. Confirm the host still has the expected local address.
6. Test from an external connection rather than using a local result as proof of internet reachability.

Do not publish a claim that opening more ports improves server performance. Reachability and runtime capacity are different questions.

Verify world and sandbox identity

The Sandbox Settings page locates dedicated-server settings under the server installation's Saved/SaveGames/Server/Worlds path, inside the selected world. The file must begin with [SandboxSettings], and a restart may be required for changes to take effect.

If no sandbox change loads, confirm world folder, filename, section header, key spelling, value form, and restart before changing the value again. Use the Sandbox Config Builder for a reviewed subset of keys, and preserve unrelated lines already present in the active file.

Run a reproducible runtime check

For a problem that appears after players connect, keep the server configuration unchanged and reproduce one ordinary path. Record:

• connected player count;
• broad area or transition where the symptom begins;
• whether it affects everyone or one player;
• console or log event at the same time;
• whether the problem persists after players leave;
• whether the same state recurs after a clean restart.

This evidence does not prove a CPU, memory, network, or save cause by itself. It does show whether the symptom is tied to a repeatable state. Use host monitoring to compare process CPU, memory, disk, and network at that timestamp, but avoid publishing a universal threshold unless the server developer documents one.

Change one documented system

Sandbox settings alter gameplay and can also alter workload indirectly, but they are not generic performance switches. Enemy spawn rate, loot respawn, world cycles, and other fields should be changed only when the test hypothesis names that system.

Use the multiplayer sandbox scaling guide to keep encounter, progression, and logistics tests separate.

Roll back and report useful evidence

If a change fails, stop the server and restore the paired known-good configuration. Keep the failed file and relevant log so the difference can be reviewed. Do not overwrite the only world backup while testing recovery.

A useful report contains current game/server version, platform, installation method, redacted launch parameters, world identity, exact symptom, reproduction steps, relevant log excerpt, and the single change tested. Community issue reports can identify known problems, but an unresolved report is not proof of a general fix.

Completion condition

The diagnosis is complete when the team can name the failing layer, reproduce or clear the symptom with one controlled change, and restore the last accepted state. If no local cause is established, retain the evidence and check current maintainer issues instead of inventing a tuning value.

Use the save and config recovery workflow before another experiment. Revisit this page after server updates because launch syntax, known issues, and available settings can change independently.