Rust server performance: entities and FPS

A Rust server's health is one number: its frame rate, the number of simulation ticks it completes per second. When it drops, doors open late, players rubber-band and fights feel unfair. The biggest thing pulling it down is the entity count - every wall, box, turret, sleeping player and dropped item the server tracks - which climbs from wipe day until the next wipe. After that come plugins, garbage collection pauses and the size of the map. The fixes, in order of value: keep decay on, size the map to your population, audit plugins by hook time, give the garbage collector headroom, restart daily, and wipe on a schedule. Measuring first with serverinfo turns all of this from guessing into a checklist.

Measuring before changing anything#

Two console commands tell you most of what you need.

> server.fps> serverinfo{  "Hostname": "Longship | EU | Biweekly",  "MaxPlayers": 75, "Players": 61, "Queued": 0, "Joining": 1,  "EntityCount": 184213,  "Framerate": 58.0,  "Memory": 11240,  "Collections": 312,  "NetworkIn": 412000, "NetworkOut": 3950000,  "Uptime": 51320}

serverinfo is the same call status bots and RCON tools use, so you can log it every few minutes and see the curve of a whole wipe. Rust RCON and WebRCON includes a short script for that. One sample tells you little; a week of samples tells you whether lag follows player count, entity count or uptime, and each has a different fix.

What server FPS means and what is healthy#

The server runs its simulation in a loop, and Framerate is how many times per second that loop completes. It is not the players' graphics frame rate, and a server at 30 can feel perfectly smooth while a client at 30 would not.

These are rough bands, not rules - a quiet PvE server at 25 is happier than a busy PvP server at 40 with spikes to 5. Spikes matter more than averages: a server that averages 50 but hitches to single digits every few minutes feels worse than a steady 30.

The server caps itself at the value of fps.limit. Raising the cap does not create performance that is not there. Lowering it to around 60 is reasonable on a shared machine, because cycles spent above that are wasted for players and taken from neighbours. What tick rate actually means covers the general concept.

Entities: the main cost#

Almost everything in Rust that is not terrain is an entity: building blocks, doors, boxes, furnaces, turrets, sleeping bags, sleeping players, dropped items, corpses, animals, NPCs, vehicles, resource nodes. Each one costs memory, and many cost CPU every tick - anything that thinks, moves, decays, or checks for players nearby.

On a fresh procedural map, the count is mostly environment and monuments. Then players build. A busy community server can add tens of thousands of entities a week, and a server that started a wipe at a comfortable frame rate ends it struggling, with the same hardware and the same player count. The wipe is what resets it.

What drives entity growth, roughly in order:

• Bases. Large compounds with hundreds of blocks, external walls and dozens of boxes. Clans build more than solos.
• Deployables. Every box, furnace, planter, sign, light and trap.
• Abandoned bases. Without decay, they never leave.
• Electrical and industrial setups. Conveyors, sorters and wired systems are entities that also do work every tick.
• Dropped items and corpses after fights, until they despawn.
• Players asleep in their bases, which are entities while logged off.

Controlling entity growth#

• Keep decay and upkeep on. Vanilla decay removes abandoned bases within a day or two; upkeep makes giant bases expensive to keep. decay.scale 0 on a monthly server is the single most reliable way to make the last week unplayable. server.cfg and convars explains the decay settings.
• Size the map to the population. A bigger map gives players more space to build and more monuments full of NPCs. Custom maps and procedural size has a population table.
• Wipe often enough. If performance collapses in week three, a biweekly cadence fixes it more cleanly than any plugin. The monthly force wipe schedule covers fitting cadences around the forced update.
• Limit what one group can place. Building-limit plugins cap blocks or specific deployables per player or per Tool Cupboard. On a modded server with high gather rates they are close to mandatory, because 5x resources produce 5x bases.
• Deal with the worst offenders directly. An admin with debugcamera can find the compound that is ten times bigger than anything else. Talking to its owners is usually more effective than a rule nobody reads.

Cleanup plugins that periodically delete entities on a timer are a last resort. They treat the symptom, and they delete things players care about at moments they will not forgive.

Finding the expensive bases

Entity counts are not evenly spread. On most servers a handful of groups account for a large share of what was built, and one sprawling compound with external walls, dozens of boxes and an automated industrial setup can cost more than the twenty smallest bases put together.

Finding them is a job for an admin with debugcamera or noclip and an evening. Fly the map at height, note the largest compounds and the densest clusters of deployables, and look inside the ones with wired electrics and conveyors, which also do work every tick. Admin radar plugins on a modded server shorten this, because they show boxes and deployables through walls.

What you do with the list is a community decision, not a technical one. Many servers publish limits in their rules - a maximum footprint, a cap on turrets or external walls - and enforce them with a building-limit plugin so nobody has to argue case by case. Others talk to the biggest groups directly and ask them to clean up abandoned pieces. Both work better than deleting anything without warning. Rust admin commands covers the inspection tools.

Plugins and hook time#

On a modded server, plugins are the second-largest cost and the easiest to fix, because the cost is usually concentrated. Most plugins do a little work on a few events. A few do a lot of work on events that fire constantly - every entity spawn, every damage tick, every item movement - and those few can cost more than everything else combined.

On Oxide, oxide.plugins lists each plugin with the total time spent in its hooks. Sort by that time after a busy evening. On Carbon, the built-in profiler records hooks and plugins during a window you choose, which is better evidence. Patterns that show up at the top:

• UI plugins that redraw for every player on a short timer.
• Anything that iterates over all entities periodically.
• Logging plugins that write on every damage or loot event.
• Two plugins doing the same job, each hooking the same events.

Unload the suspect on a quiet evening and compare frame rate the next evening at the same population. Oxide (uMod) plugins and Carbon vs Oxide cover the commands.

Memory and garbage collection#

Rust is a Unity game, and its game code runs on a managed runtime with a garbage collector. As the server allocates and discards objects, garbage builds up; a collection pauses work to reclaim it. Frequent collections show up as regular hitches - the frame rate dips briefly and recovers - and Collections in serverinfo climbs quickly.

Rust exposes gc.buffer, the amount of headroom (in MB) the collector keeps before collecting. A larger buffer means fewer, larger collections, at the cost of more memory in use. On a server with memory to spare, raising it is a common and effective change; server guides typically use values in the low thousands of megabytes. Set it on the launch line, check the convars your build has with find gc., and watch both the hitching and total memory afterwards. Raising the buffer on a server already near its memory limit trades hitches for an out-of-memory stop, which is worse.

Memory also grows with uptime and with entity count. Two rules follow:

1. Size memory for the end of the wipe, not the start. A server at 9 GB on day one can need 14 GB by day twenty.
2. Restart daily on busy servers. A scheduled restart at a quiet hour, announced in advance, returns memory and clears accumulated state. Restart schedules that help explains how to do it without annoying people.

say "Server restart in 10 minutes - find a safe spot"server.saverestart 600 "Daily restart"

CPU, players and the main thread#

The simulation leans on one main thread. More cores help with saving, networking and plugin compilation, but the frame rate is decided by how fast one core can do the work. That is why a server with eight slow cores can lag where one with four fast cores does not, and why per-core speed is the number to compare when choosing hardware. CPU vs RAM for game servers is the general version.

Players cost CPU in proportion to what they do near each other. Fifty players spread across a map are cheaper than fifty in one raid, and peak lag tends to be the evening raid on the largest base. The queue protects you: setting server.maxplayers to what the server can carry and letting the rest wait is better than letting everyone in and lagging for all of them.

NPCs, animals and events

Not every CPU cost comes from players. Scientists at monuments, animals roaming the map, the patrol helicopter, the cargo ship and the other scheduled events all think and move on the server, and their cost scales with the map: a larger world has more monuments and more spawn area, so more of them. Most of the time this is a steady background load rather than a problem, but it explains why an empty large map can still use noticeable CPU, and why event-heavy plugins that add extra NPCs, raidable bases or more frequent events are among the more expensive things you can install.

If you add content of that kind, add it one piece at a time and compare the frame rate at a similar population before and after. The cost of a raidable-base plugin that spawns dozens of armed NPCs is very different on a quiet Tuesday and during a Saturday evening with every group online.

On hosting that limits CPU as a share, as container-based panels do, the limit is a hard ceiling: hitting 100% of your share makes the server slow, not suspended. On RE:NODE, CPU is a hard throttle to the share bought, and the console graphs show memory, CPU and disk against the plan's limits, so you can see whether the frame rate dropped because the CPU share was exhausted or for some other reason. Reading a server load graph explains how to read them.

A diagnosis table#

When the server keeps restarting#

A Rust server that exceeds its memory limit is stopped. On RE:NODE, a container that hits its memory limit is stopped by the kernel and restarted clean rather than left to swap, so the symptom is a restart with nothing useful in the game log, and anything since the last save is lost. A crash watcher counts unplanned restarts; three in an hour produce a warning on the server page and an automatic ticket. If that is what you are seeing, the cause is almost always memory growth through the wipe, and the fixes are the ones above: decay, map size, daily restart, and enough memory for the last day. Shortening server.saveinterval limits what each restart costs. Why your game server keeps restarting goes through the other causes.

FAQ#

What is a good server FPS for Rust?

Above 30 sustained is generally fine, and 60 is comfortable headroom. What players notice most is spikes - a server that drops into single digits every few minutes feels worse than one sitting steadily at 30.

How many entities is too many for a Rust server?

There is no fixed number; it depends on CPU, plugins and what the entities are. Watch the trend instead: if frame rate falls as EntityCount rises through the wipe, entities are your limit on that hardware.

Does a bigger map cause more lag?

Indirectly. A bigger map holds more terrain, more monuments and NPCs, and gives players room for more bases. Sized to the population, it is fine; oversized, it costs memory and CPU for empty space.

Should I restart my Rust server every day?

On a busy server, yes. A daily restart at a quiet hour clears memory growth and accumulated state. Announce it, save first, and keep it at the same time every day.

Do ClearLag-style cleanup plugins help Rust?

Rarely, and they annoy players. Decay, upkeep, building limits and a sensible wipe cadence control entities at the source; deleting things on a timer is a last resort.