Diagnose Rust server lag and entity load without wiping

Rubber-banding, slow inventory actions and low client frame rate can have different causes. Collect a short, timed example before changing world settings. A large entity count can be relevant, but it is not sufficient evidence that deleting players' buildings will fix the problem.

Separate the symptoms

Ask two players in different locations to report the same event and time. Note whether everyone sees delayed actions, only one connection suffers, or one player's rendering slows down. Compare the game panel's existing CPU, memory and network history with that period. A brief CPU average can conceal a main-thread stall, so retain the timeline rather than only a current screenshot.

Record player count, map size, world age, plugin versions and recent configuration changes. Include any entity-count information already available through trusted server telemetry. Do not run unverified commands from forum posts to enumerate or remove entities.

Look for correlated activity

Check console and Oxide logs around the reported time for repeated plugin exceptions.
Compare scheduled saves, backups and plugin tasks with the lag window.
Check whether storage is nearly full or memory repeatedly approaches its limit.
Look for a recent plugin or settings change that matches the first occurrence.
Repeat a short observation during a similar player load before drawing a conclusion.

Keep the original logs and redact account details before sharing them. Avoid mass plugin unloading during peak play; inventory, protection and economy plugins may provide essential rules. A temporarily quiet server is not necessarily proof that a particular plugin caused the issue.

Test one reversible change

Back up world, player data, plugin data and any external databases before changing behaviour. Record the current configuration and choose a quiet maintenance window. If evidence points to one plugin, follow its author's supported diagnostic workflow and consider a separate test instance. Compare the same activity before and after; restore the retained settings if there is no clear improvement.

Do not change map seed, remove save files, purge entities or reset databases as a performance experiment. Those actions destroy evidence and can remove customer progress without addressing the original bottleneck.

Use profiling only when justified

Facepunch provides a server profiler enabled through the -enableProfiler startup argument. It requires a restart and can add overhead; recording may substantially degrade performance. Arrange this with support rather than enabling it permanently during an outage.

If a profile is requested, follow the current Facepunch instructions for a short capture and wait for it to finish saving before changing settings or starting another recording. Keep adequate storage space. Remove the profiling startup argument after the investigation and restart normally in the agreed window.

Escalate with useful evidence

Provide the service ID, UTC timestamps, player-count range, affected actions, redacted errors and relevant resource graphs. State which single test was performed and its result. Profiling archives may contain operational details; share them privately with support. Keep the working configuration and backups until a comparable busy period confirms the improvement.