You cannot optimize what you cannot measure. Before you touch a single cvar, you need numbers: what the server FPS actually is, which core is loaded, whether the box is losing packets, and whether the hypervisor is stealing your CPU. This is the practical toolkit — standard Linux utilities plus the two in-game commands — that tells you where a CS 1.6 server actually hurts.
1. Server FPS: the in-game number that matters most
The single most important performance metric is the server's frame rate, because it caps how smooth movement and hit registration feel. Read it from the server console:
stats
The fps field is your headline number. A healthy sys_ticrate-driven server holds a steady 500–1000; if it sags under load, that is your bottleneck. The full method, including how to log it over time, is in measuring server FPS.
2. top and htop: per-core CPU
HLDS/ReHLDS is single-threaded per instance, so aggregate CPU is misleading — you care about the one core it runs on. In top, press 1 to expand per-core lines:
top # press 1 to show every core separately
One core pinned near 100% while others idle is normal and expected for one server — that is the single-thread reality, not a bug. Watch the %us (user) column for the hlds process. Also watch %st (steal) on a VPS — more on that below. htop gives the same data with a nicer per-core bar display.
3. Watch steal time explicitly
On a VPS, the number that silently ruins performance is steal. Two ways to see it:
vmstat 1 # the 'st' column, far right mpstat -P ALL 1 # per-core %steal
Any sustained non-zero st means the hypervisor is handing your vCPU to another tenant; the full diagnosis is in CPU steal time. On a healthy dedicated box this is always zero.
4. Network: choke, loss and interface counters
Distinguish server-side choke from real network loss. In-game, the scoreboard shows per-player choke and loss; on the box, watch the interface and sockets:
ifstat 1 # per-second in/out per interface ss -u -a -n | grep 27015 # UDP sockets on the game port ip -s link show eth0 # RX/TX errors and drops
Rising RX dropped or errors on ip -s link points at the NIC or kernel buffers; per-player choke on the scoreboard points at rate settings instead. Keep the two separate — see choke vs loss.
5. Latency and path quality: mtr
For anything ping- or loss-related from the outside, run a continuous traceroute from a client toward the server:
mtr --report --report-cycles 100 YOUR.SERVER.IP
Read the Loss% and Avg columns per hop; loss that appears mid-path but clears at the final hop is usually ICMP rate-limiting, not real loss. The full reading guide is in diagnosing packet loss.
6. Keep history, not just snapshots
Live tools show now; problems happen at 9pm when you are asleep. Log trends:
vnstat -i eth0 # daily/monthly traffic totals sar -u 1 3 # CPU history via sysstat apt install sysstat vnstat
sar (from the sysstat package) records CPU, load and network to disk so you can look back at what the box was doing during last night's lag spike. Pair it with an external uptime monitor so you are alerted when the server drops rather than finding out from angry players.
Common mistakes
- Judging load by total CPU% — a quad-core at 25% total can have one core pegged. Press
1intopand read per-core. - Ignoring
%st— steal does not show in aggregate load; it is CPU you paid for and did not get. - Blaming the network for choke — scoreboard
chokeis the server hitting a rate cap, not packet loss on the wire. - Only looking live — without
sar/vnstathistory you cannot diagnose a spike that already passed.
Verification
Build a one-screen baseline while the server is busy: stats in the game console for FPS, top with per-core view for the pinned core and %st, ifstat 1 for throughput, and an mtr from a client. Record those four numbers when the server is healthy. Next time players report lag, re-read the same four — whichever one moved is your culprit, and it points straight at the matching fix: low FPS to server FPS tuning, high steal to a better host, choke to rate cvars, path loss to the network.
