The server is smooth right after a restart, then over days it slowly gets worse — higher server-side lag, choppier movement, occasional hitches — until a restart makes it perfect again. This is a resource-exhaustion pattern: something accumulates over uptime (memory, log files, a growing in-memory structure) until it starts costing performance. The tell is that restarting fixes it and the degradation is gradual, not tied to player count. Here is how to find and manage the accumulation.
1. Confirm it is uptime, not load
First separate this from a load problem. A server that lags in proportion to players is CPU- or plugin-bound under load — that is the FPS-under-load case. A server that lags in proportion to uptime, at the same player count that was fine on day one, is accumulating something. Note the server FPS from stats right after a restart, then again after several days at a similar population; a clear decline over time with steady load confirms the pattern.
2. Watch memory growth
The usual accumulator is memory. Track the HLDS process's resident memory over time from the host:
ps -o pid,rss,etime,cmd -p $(pgrep -f hlds_linux)
Run this daily and watch the rss column (resident memory in KB). Healthy servers settle at a roughly stable footprint; a steady, unbounded climb over days is a leak — almost always a plugin allocating and never freeing, or caching per-player data without ever pruning it. When memory grows into swap on a small VPS, the whole box starts paging and every frame gets slower, which is exactly the gradual lag you feel.
3. Find the leaking plugin
If memory climbs, a plugin is usually responsible. Correlate the growth with what is loaded by testing with a reduced plugin set on a staging server, or by pausing suspects and watching whether the growth rate changes:
amxx pause suspect.amxx
Plugins that build ever-growing arrays or nVault caches, log verbosely to memory, or spawn tasks that never clear are the usual offenders. A plugin doing unbounded SQL result handling or keeping every connected player's history forever will leak. Update the plugin to a maintained version, or replace it — a leak in a plugin is a bug in that plugin, and the durable fix is fixing the plugin, not restarting around it forever.
4. Rotate logs and clear disk bloat
Two on-disk accumulators bite long-running servers. AMX Mod X and the engine write logs continuously; over weeks these grow to hundreds of megabytes and, on a small or nearly-full disk, slow every write the server makes. Check and manage them:
du -sh addons/amxmodx/logs/ du -sh cstrike/logs/ df -h
If the log directories are huge or the disk is near full, archive and truncate old logs and set up rotation so they do not grow unbounded. A disk at 100% causes writes to fail and the server to stall unpredictably — check df -h whenever a long-uptime server misbehaves. Also confirm demo recordings or a runaway crash-log are not filling the disk.
5. Schedule a restart as a safety net
Even with leaks fixed, a scheduled restart during off-peak hours is standard practice for long-lived GoldSrc servers — it resets memory, clears any slow accumulation, and reloads plugins cleanly. Set a cron job on the host to restart the server at a quiet time:
# restart daily at 06:00 (adjust to your process manager) 0 6 * * * /path/to/restart-cs-server.sh
Use your actual start script or process manager (systemd, a screen/tmux wrapper) in the job. A nightly restart is a pragmatic backstop, not a substitute for fixing an identified leak — but combined with a fixed plugin set it keeps the server permanently in its fresh-boot performance band.
Troubleshooting
- RSS climbs steadily over days — a plugin leaks memory. Isolate it by pausing suspects and fix or replace it.
- Lag scales with uptime, not players — accumulation, not load. Track memory and logs.
- Box starts swapping — memory grew past RAM on a small VPS. Fix the leak or add RAM; a restart clears it temporarily.
- Disk near full in
df -h— log or demo bloat. Rotate logs and clear old files. - Restart always fixes it — classic resource exhaustion; schedule a restart while you hunt the leak.
- Only one plugin present makes it grow — that plugin is the leak. Update or remove it.
Verification
After fixing the suspected plugin and setting up log rotation, leave the server running under normal load and sample ps -o rss and stats daily for a week. A healthy server holds a roughly flat memory footprint and steady FPS across the whole period at consistent population. If memory stays flat and the day-seven FPS matches day-one, the accumulation is resolved and the scheduled restart is now just insurance. If it still climbs, a plugin you have not isolated yet is leaking — keep pausing candidates until the growth stops. Pair the restart job with the plugin-update discipline in updating plugins on a live server.
