Optimize Rust server performance & FPSStable server FPS, even on wipe day

Published on August 4, 2026 · last updated on November 8, 2026

Why Rust is CPU-heavy

Rust computes a large part of its server logic on a few threads - the single-thread performance of the CPU is therefore decisive. On top of that comes the memory needed for the map and entities. That is why we rely on fast CPUs and NVMe SSDs; the rest is determined by your configuration.

Keep an eye on server FPS

Server FPS show how smoothly the server ticks. Check and limit them:

server.fps        # show current server FPS
fps.limit 256     # set an upper limit (0 = unlimited)

If server FPS drop below the tick rate, the game becomes noticeably sluggish. If the value collapses when the server is full, the cause is usually map size, entity count or plugins.

The biggest levers

• worldsize - a smaller map (for example 3500 instead of 4500) takes considerable load off CPU and RAM.
• Plugin load - every plugin costs performance. Remove unused plugins and avoid very compute-intensive ones (such as elaborate live maps or raid tools).
• Entities - many bases, deployables and buildings increase the load; a timely wipe helps.
• The right plan - more players and bigger maps need more RAM. When in doubt, choose one tier larger.

Wipe day & framework

On force wipe day, everyone rushes onto fresh servers at the same time - the load is at its highest. Make sure your framework is up to date (Oxide reinstalled or Carbon active), restart the server cleanly and watch server.fps during the first hours. If you want maximum performance and fast availability on wipe day, Carbon often has the edge.

Map size: the underrated lever

No other setting affects server load as strongly as the world size. A map with worldsize 4500 has to manage considerably less terrain, fewer monuments and fewer objects than one with 6000 - and the difference is not a detail, it is in the range of multiples.

There is a second effect as well: on a map that is too large, players spread out so far that the world feels empty. So you pay twice - with performance and with game feel. A useful guideline is around 3000 to 3500 of map size per 50 expected players; for a small group, 3500 is often better than 4500.

The values can only be set when a new world is generated, so in practice at a wipe. Details under worldsize & seed.

Plugins are the most common brake

When a Rust server drops for no apparent reason, in most cases it is not the hardware but a single plugin. Typical candidates are anything that computes continuously in the background - zone systems, event plugins, elaborate statistics or map overlays.

This is how you find it:

1. Watch server.fps via RCON and note the value when it stutters.
2. Unload suspicious plugins one at a time and wait for the effect.
3. With Oxide, o.plugins shows what is loaded - under Carbon, it is c.plugins.

As a rule of thumb: every plugin you do not actively use should come off the server. Running twenty plugins, half of which nobody would miss, is the most common reason for a server that feels sluggish.

Plan restarts

Rust servers get slower over their uptime - that is normal and cannot be configured away. A daily restart in the early morning hours keeps the server in its usual range and is standard practically everywhere.

Announce it ahead of time via say so that nobody gets kicked out in the middle of a raid, and run server.save beforehand. Afterwards, the state is cleanly written to disk, and an unexpected crash costs minutes at most instead of hours.

Independently of that, backups remain your job: with us, backups are self-service across the board via WebFTP or SFTP, see Create backups. Especially before switching frameworks or making larger plugin changes, that is worth the minute.

Frequently asked questions