Troubleshooting

Note: The content on this page pertains to Game Server Hosting (Multiplay) available on the Unity Dashboard. If you’re using Game Server Hosting (Clanforge), see the Game Server Hosting (Clanforge) documentation.

Troubleshooting servers

Missing server instances

When you first create a fleet, it might take several minutes for the new servers to show up in the Unity Dashboard.

If you still don’t see servers after 15 minutes, check the scaling settings for each region within your fleet. You might not see servers in the Dashboard if you have a Minimum servers setting of less than one.

Servers crashing

Servers sometimes crash, ending any active game allocations on that server. The following list details some of the common reasons a server might crash.

  • The server is using too many resources for the number of players.
  • There’s something wrong with the build configuration.
  • The build executable doesn’t exist.

If a server is crashing and you are sure it'sn't a bug in your build, reach out to the customer success team.

Note: Before Game Server Hosting restarts a build executable, it attempts to dump the process to allow you to evaluate the stacktrace. This appears in logs as a SIGSEGV.

Servers fail to start

Servers can sometimes fail to start up, which prevents you from using the server in an allocation. The following list details some common reasons a server might fail to start.

  • There’s something wrong with the build executable.
  • The server is using too many resources for the number of players.
  • There’s something wrong with the build configuration.

Too many server instances

If you’re seeing more server instances than you expect in the Unity Dashboard, it might be due to how Game Server Hosting manages server density according to your usage settings.

The scaling system considers all the build configurations within a fleet and uses the worst-case usage settings to determine how many servers can run per machine. Game Server Hosting uses the worst-case usage settings to prevent the fleet from re-scaling each time you switch build configurations.

It’s essential to understand how the worst-case usage settings impact scaling. For example, if the usage settings allow for three servers to run per machine and the scaling settings require four available machines, the scaling system starts two machines. The two online machines result in six available servers instead of four due to the usage settings.

Game Server Hosting creates these two additional servers to make the most of the available capacity. By default, these additional servers are in a stopped state and provide a quick way of increasing server availability without needing to start a new machine.

Troubleshooting installations

Slow build installations

In most cases, a build installation shouldn’t take longer than five to 15 minutes. The following list details some common reasons why installing a game image might take longer than expected.

  • The build is exceedingly large.
  • You’re updating many servers simultaneously.

Troubleshooting usage settings

Usage settings not optimized

You might have to adjust the usage setting values several times before you find the ideal value. For example, if you notice that servers running this build configuration lag or exhibit performance issues, increase the CPU or RAM. If your server performance is acceptable, but you want to increase the server density, decrease the CPU or RAM.

One of the best ways to find the ideal usage settings for your game server is to make CPU value changes in increments and decrements of about 100 MHz and RAM value changes in increments and decrements of about 100 MB. Each time, you make an change, test the build to see how your servers perform with the build.

Note: In the future, Game Server Hosting will have automated tooling to help you calculate the ideal usage settings for each build.

Servers using too much CPU

There are many reasons why a server might use more CPU than you expect. However, one common reason is that the main game loop runs as fast as the CPU will allow, consuming all resources. Game Server Hosting detects this and after a grace period, stop the server.

You can prevent this by limiting the application target frame rate and the number of vertical syncs that pass between each frame.

The application target frame is controlled by the Application.targetFrameRate setting. In most cases, setting it to a value around 60 prevents the game loop from using too much CPU. See the Application.targetFrameRate script reference documentation.

Application.targetFrameRate = 60

The QualitySettings.vSyncCount setting controls the vertical syncs your game uses even without a display. In most cases, setting it to 0 prevents the game loop from using too much CPU. See the QualitySettings.vSyncCount script reference documentation.

QualitySettings.vSyncCount  = 0

Troubleshooting logs

Missing logs

Game Server Hosting allows you to surface server log files through the Unity Dashboard for easy access. However, before you can access your server log files, you must:

Note: Using a query protocol is optional. However, if you choose not to use a query protocol, you will only have access to Unity service-related logs.

The query protocol set in the build configuration must match the query protocol implemented in your build. For example, if a build uses SQP as the query protocol, you must set SQP in all build configurations pointing to that build.

You must specify the correct log location in the build configuration through the launch parameters, a configuration variable, or both. Like the query protocol, the log location implemented in a build must match the log location in all build configurations pointing to that build. The code block shows how to use the $$log_dir$$ configuration variable in the launch parameters.

-logFile $$log_dir$$/Engine.log -dataPath $$log_dir$$

Note: If your game is built using Unreal Engine, you’ll need to redirect your logs before you can access them from the Unity Dashboard.

Note: If your server executable is a Unity build, use -logFile $$log_dir$$ in the launch parameters. If you're using a Unity build and not seeing any log files in the dashboard, try using -logFile $$log_dir$$/logfile.log.