Combating Server FPS Drops and Entity Lag on a Rust Server
The Rust server application is highly demanding on single-threaded CPU performance and storage subsystem speeds. Unlike many other survival games, Rust's world is fully dynamic: players construct massive multi-story bases consisting of thousands of elements, place down hundreds of turrets, traps, and storage boxes, and actively utilize transport. In Unity engine terminology, all these objects are classified as entities.
When the total entity count on the map crosses a critical threshold (typically 150,000 to 200,000 objects for a standard hosting plan), the server's framerate begins to drop rapidly, players experience delays when opening storage boxes (Loot Lag), and network responsiveness degrades. In this article, we will examine how to optimize physics parameters, configure decay rates, and clear map clutter to ensure stable server performance.
1. Restricting Total Entity Count and Building Limits
Every placed wall, foundation, or deployable item creates a constant load on the server, as the engine must continuously calculate their state, network synchronization, and structural stability. The first step toward optimization is strict control over base expansion.
- The
server.maxentitiesVariable: This parameter sets a theoretical entity limit that the server attempts to maintain. However, it does not directly prevent players from building. For rigid control over base structures, it is highly recommended to use plugins like EntityLimit or the built-in limits of the Oxide/Carbon frameworks, which physically prohibit a single clan from placing more than, for example, 20 turrets or 5,000 building blocks per Tool Cupboard. - Optimizing Building Stability: Calculating structural stability for massive buildings strains the CPU whenever a wall is blown up. If your server is strictly a training or creative venue (Build/Creative/Battle), completely disable stability simulations with the following command:
construction.stability false
2. Configuring Building Decay (Decay Scale) — The Server's Main Caretaker
If building decay is disabled or slowed down excessively, the map will become littered with abandoned starter bases within 2 to 3 days. Houses without a Tool Cupboard or lacking upkeep resources must disappear as quickly as possible to free up RAM and unburden the processor.
Open the server.cfg configuration file in your hosting panel and optimize the following parameters:
# Decay speed multiplier. 1.0 is standard (a twig wall decays in a couple of hours, armored takes two days).
# If you want to speed up map clearing, increase this value to 1.5 or 2.0.
decay.scale 1.0
# The time (in minutes) after a Tool Cupboard is destroyed or emptied before a base begins to decay intensely
decay.delay_twigs 10
decay.delay_wood 30
decay.delay_stone 60
decay.delay_metal 120
decay.delay_toptier 240
Important: Never set decay.scale 0 on public vanilla servers with high player counts. Without decay, the entity count will hit your hosting limit long before the scheduled wipe, resulting in permanent server lag.
3. Unity Physics: Optimizing Collider Ticks
Every object in Rust possesses a physical boundary known as a collider, which handles bullet hit registration, player collisions, and item drop physics. By default, Unity updates the physics mesh too frequently.
To reduce CPU overhead, modify the physics engine update frequency in your startup script or directly via the server console:
physics.bouncethreshold 2.0— Increases the minimum velocity required to calculate object bouncing, reducing micro-calculations for dropped loot items.physics.steps 30— The number of physics ticks per second. The default value is 60. Lowering this to 30 or 45 significantly unburdens the primary CPU core while having practically no noticeable impact on bullet hit registration.
4. Monitoring and Limiting Custom Vehicles
Modular cars, minicopters, boats, and horses are dynamic entities. They constantly update their coordinates, calculate friction physics, and check for collisions even when sitting stationary inside a player's base. A massive amount of abandoned transport on roads and rivers is a heavy source of lag.
| Command / Variable | Optimal Value | Performance Impact |
|---|---|---|
minicopter.population |
0 to 1 |
Minicopter spawn density per square kilometer. It is recommended to lower this to a minimum, or set it to 0 if your server utilizes a vehicle shop plugin instead. |
modularcar.population |
1 or 2 |
Limits the number of modular cars spawning and decaying on the roads. |
hotairballoon.population |
0 |
Completely disables hot air balloon spawns. They feature complex wind physics computations that heavily strain the server thread during flight. |
5. Enforcing Map Cleanses and Garbage Collection
In addition to automated decay, administrators should conduct regular maintenance on the game world. This is achieved using the engine's built-in Garbage Collector (GC) configurations and targeted entity deletion commands:
- Managing the Garbage Collector (GC): By default, Rust cleans up unused memory in bulk, causing momentary freezes for all players every few minutes. Configure a more frequent but lightweight incremental cleanup by adding the following parameters to your server's startup arguments:
-gc.incremental true-gc.buffer 2048(allocates a 2 GB buffer for the garbage collector to prevent severe collection spikes). - Clearing Abandoned Loot Drops: If players raid a base and leave tons of loose items floating on the ground, you can clear them manually using the console command:
global.collapsestoreboxesor delete all active loose item drops via:del assets/prefabs/misc/item drop/item_drop.prefab
Quick Monitoring Guide: To view what is currently taxing your server in real time, type the serverinfo command into the console. Pay close attention to the EntCount (total entity count) and Uptime values. If EntCount is growing anomalously fast (e.g., by 50,000 per day with low player activity), check your server logs for cheaters using exploit scripts designed to mass-spawn items and trigger server crashes.