Fix: Server FPS Drops When Players Join

An empty CS 1.6 server holds a high, steady server FPS, but as players join it sags — movement feels rubbery, hit registration gets worse, and stats shows the FPS falling. Server FPS is how many times per second the engine simulates the world; when it drops below the intended rate the whole server feels laggy even on a fast link. The causes are the timing configuration, CPU contention, and expensive plugins. Here is how to pin it down.

1. Measure the real server FPS

Do not guess — read it. In the server console:

stats

This prints the current server FPS, CPU percentage, players, and network in/out. Watch it with the server empty, then again as it fills. If FPS is high when empty and collapses under load, the server is CPU- or timing-bound, not network-bound. Note the FPS numbers at each population; you will compare against them after each change.

2. Set the timing rate correctly

The engine's simulation rate is governed by sys_ticrate and, on ReHLDS, the FPS cap. On original HLDS the classic way to raise and stabilize server FPS is the startup option:

./hlds_run -game cstrike -console -pingboost 1 -sys_ticrate 1000 +map de_dust2

-sys_ticrate sets the target simulation rate, and -pingboost selects a timing method (modes 1–3) that changes how the engine sleeps between frames. On ReHLDS the FPS is controlled through its own cvar rather than the old pingboost hacks — ReHLDS exposes sys_ticrate and an fps_max-style server cvar; set the target there. The goal is a server FPS that stays at your target under full load, not one that only looks good when empty.

3. Rule out CPU contention

If stats shows CPU climbing toward 100% as players join, the box cannot sustain the simulation rate for that many players. Two realities of GoldSrc matter here: it is largely single-threaded, so one busy core caps you regardless of how many cores the box has, and shared/oversold hosting gives you inconsistent CPU time. Check the host CPU with top and look for the HLDS process pegging one core:

top -p $(pgrep -f hlds_linux)

If that process sits near 100% of a core under load, you are CPU-bound — lower the target FPS to something the core can hold, reduce maxplayers, or move to a host with a stronger single-core allocation. No cvar tuning beats a saturated core.

4. Find an expensive plugin

A plugin doing heavy per-frame or per-player work — a badly written server_frame hook, a plugin running blocking work, or one looping over all players every tick — drags FPS down exactly as population rises, because the cost scales with players. Isolate it by pausing plugins one at a time and watching stats:

amxx pause suspect.amxx

If FPS recovers when a specific plugin is paused, that plugin is the cost. A frequent culprit is a plugin issuing synchronous database queries on the main thread — see the blocking MySQL fix for why that stalls the whole server. Replace or fix the offender; do not just leave it paused if you need it.

5. Keep rates sane

Server-side rate caps that are too generous let a full server flood the simulation with more work than the CPU can process. Set reasonable caps in server.cfg:

sys_ticrate 1000
sv_maxrate 25000
sv_maxupdaterate 100

These bound the per-client network and update load so one packed server does not try to push more than the box can handle. Tune them to your player count and link, not to the theoretical maximum.

Troubleshooting

• FPS high empty, collapses full — CPU-bound or an O(players) plugin. Check top and pause plugins one by one.
• FPS never reaches target even empty — wrong timing setup. Set -sys_ticrate/-pingboost on HLDS or the ReHLDS FPS cvar.
• One core at 100% — GoldSrc is single-threaded; you are CPU-limited. Lower target FPS, reduce slots, or upgrade the host.
• FPS recovers when one plugin is paused — that plugin is the cost; fix or replace it.
• Fine on a dedicated box, bad on shared hosting — oversold CPU steals time. Move to a host with guaranteed single-core performance.
• Laggy only in big firefights — rates too high flooding the CPU. Cap sv_maxrate/sv_maxupdaterate.

Verification

After each change, fill the server (or simulate load) and read stats again, comparing the FPS at full population against your empty-server baseline. A healthy server holds close to its target FPS at full slots with CPU below saturation. If FPS now stays stable as players join, the fix held; if it still sags only under load, the bottleneck is the CPU core or a scaling plugin, not the timing config. For servers that degrade only after long uptime rather than under player load, that is a different pattern — see the long-uptime lag fix.