Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent 11d3334c37
commit d8a2d9b2c8b0ece015400110cf69d9b27cfd9896
2 changed files
with 24 additions and 0 deletions
cpu-governor-performance/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "CPU Governor: Why 'performance' Matters for Game Servers" | |
| 3 | +excerpt: "How Linux CPU frequency governors work, why ondemand costs a game server latency, and how to set the performance governor so the core runs at full clock continuously." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "cpu, linux" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A CS 1.6 server sends and services packets in bursts, hundreds of times a second, with long-ish idle gaps between them. That pattern is exactly what fools the default Linux CPU governor: it sees the idle gaps, clocks the core down to save power, and then has to ramp back up when the next packet arrives — adding latency at the worst moment. On a <a href="/tutorials/stable-1000-fps-linux-server">1000 FPS server</a> those micro-stutters show up as jitter. Switching to the <code>performance</code> governor pins the core at full clock and removes the ramp entirely.</p><h2>1. What a governor does</h2><p>The CPU frequency governor is the kernel policy that decides, moment to moment, what clock speed each core runs at. The common ones:</p><ul><li><strong><code>performance</code></strong> — hold the maximum frequency at all times. No ramp, no latency, higher idle power.</li><li><strong><code>powersave</code></strong> — hold the minimum frequency. Worst case for a game server.</li><li><strong><code>ondemand</code> / <code>schedutil</code></strong> — scale frequency up and down with load. Great for laptops, bad for bursty low-average-load servers because the burst is over before the clock has ramped.</li></ul><p>A game server's average CPU can look low even when its latency needs are high — that mismatch is precisely why load-scaling governors underserve it.</p><h2>2. Check your current governor</h2><p>Read what each core is set to:</p><pre>cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor</pre><p>Or, if <code>cpupower</code> is installed:</p><pre>cpupower frequency-info</pre><p>If you see <code>ondemand</code>, <code>schedutil</code>, or <code>powersave</code>, you are leaving latency on the table. Also read the live frequency to see the ramp in action:</p><pre>grep MHz /proc/cpuinfo</pre><h2>3. Set the performance governor</h2><p>The clean way, with the cpupower tool:</p><pre>apt install linux-tools-common linux-tools-generic # Debian/Ubuntu | |
| 10 | +cpupower frequency-set -g performance</pre><p>Or write directly to sysfs for every core, no package needed:</p><pre>for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do | |
| 11 | + echo performance | sudo tee "$c" | |
| 12 | +done</pre><p>Re-read the governor afterward to confirm every core now says <code>performance</code>.</p><h2>4. Make it survive a reboot</h2><p>Both methods above are lost on reboot. Persist it. On systems with the <code>cpupower</code> service, set the governor in <code>/etc/default/cpupower</code> (or the distro's cpufrequtils config) and enable the service. A simple, portable alternative is a systemd unit that writes the sysfs values at boot, or adding the <code>for</code> loop above to a startup script that runs before your game servers launch. Whatever you choose, verify after a reboot — a governor that reverts to <code>ondemand</code> overnight quietly reintroduces the jitter you fixed.</p><h2>5. Where it matters most and least</h2><p>The <code>performance</code> governor helps most on:</p><ul><li>Servers targeting high, steady FPS where jitter is visible to players.</li><li>Bare-metal and dedicated boxes where you control the host and actually own the frequency policy.</li></ul><p>It matters less — or not at all — on many VPS plans, where the <strong>host</strong> controls CPU frequency and your guest may not even expose <code>scaling_governor</code>. If <code>/sys/devices/system/cpu/cpu*/cpufreq/</code> does not exist in your VPS, frequency is the host's decision, and your real enemy there is <a href="/tutorials/cpu-steal-time-vps">steal time</a>, not the governor.</p><h2>6. Turbo, C-states and the BIOS</h2><p>The governor is only the operating-system layer of frequency control; two more knobs live below it. <strong>Turbo/boost</strong> lets a core briefly exceed its base clock — leave it enabled, since a game server benefits from every extra MHz on its single core. <strong>C-states</strong> are deep idle power states the core drops into between packets; entering and exiting them adds latency exactly like the governor's ramp does. On a dedicated box tuned for lowest latency, admins often disable the deepest C-states (via a kernel boot parameter such as <code>processor.max_cstate=1</code> or the equivalent BIOS setting) so the core stays responsive. Do this only on bare metal you own and only if you have measured jitter that justifies it — it raises idle power and heat. The <code>performance</code> governor plus shallow C-states is the standard low-latency combination for a machine whose whole job is serving game frames.</p><h2>Common mistakes</h2><ul><li><strong>Leaving <code>ondemand</code> on a dedicated box</strong> — the ramp latency is exactly what hurts a bursty game server. Set <code>performance</code>.</li><li><strong>Setting it once, losing it on reboot</strong> — sysfs writes and <code>cpupower frequency-set</code> are not persistent. Bake it into boot.</li><li><strong>Expecting it to work on a VPS</strong> — if <code>scaling_governor</code> is absent, the host owns frequency. Chase steal instead.</li><li><strong>Judging by average CPU</strong> — low average does not mean low latency needs; a bursty server benefits from a pinned clock even at 20% average load.</li></ul><h2>Verification</h2><p>Confirm the change stuck and had an effect. Re-read <code>scaling_governor</code> for every core — all should say <code>performance</code>. Then watch the live clock under load with <code>watch -n1 "grep MHz /proc/cpuinfo"</code>; on <code>performance</code> the cores should sit at or near their maximum rated frequency constantly instead of bouncing between a low idle clock and boost. Finally, re-check your <a href="/tutorials/measure-server-fps">server FPS</a> stability — the average may not change, but the dips should shrink. Combine this with <a href="/tutorials/cpu-affinity-taskset-hlds">pinning the server to a core</a> so the same core is both dedicated and running flat-out.</p> |
many-servers-one-box/en.md
A
| @@ -0,0 +1,12 @@ | ||
| 1 | +--- | |
| 2 | +title: "Running 5+ CS 1.6 Servers on One Machine Without Lag" | |
| 3 | +excerpt: "How to pack multiple instances onto one box: per-core pinning, sane fps caps, separate configs and ports, the performance governor, and watching aggregate CPU, RAM and bandwidth." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "multi-server, performance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Because <a href="/tutorials/is-hlds-single-threaded">HLDS is single-threaded</a>, a multi-core box is really a set of independent lanes, and a well-organised admin can run five, eight, even a dozen CS 1.6 servers on one machine without any of them lagging. The trick is treating each instance as an isolated tenant: its own core, its own config, its own port, and an eye on the shared resources they all draw from. Here is the layout that scales.</p><h2>1. One instance per core, pinned</h2><p>The foundation is that each server gets a dedicated physical core and stays there. Without pinning, the scheduler migrates instances between cores under load, thrashing CPU caches and causing fps jitter across all of them. Pin at launch with <code>taskset</code>:</p><pre>taskset -c 0 ./hlds_run -game cstrike +port 27015 +exec server1.cfg & | |
| 10 | +taskset -c 1 ./hlds_run -game cstrike +port 27016 +exec server2.cfg & | |
| 11 | +taskset -c 2 ./hlds_run -game cstrike +port 27017 +exec server3.cfg &</pre><p>Do not oversubscribe: if you have 6 cores, run at most 5–6 busy instances and leave a core for the OS, the master-server traffic and your web/FastDL stack. The full pinning method is in <a href="/tutorials/cpu-affinity-taskset-hlds">CPU affinity with taskset</a> and the multi-server layout in <a href="/tutorials/multiple-cs16-servers-one-vps">multiple servers on one VPS</a>.</p><h2>2. Cap fps sanely per instance</h2><p>Every instance chasing 1000 fps multiplies CPU draw. If five servers each burn a core holding 1000 fps, you have committed five full cores to frame generation alone. Decide honestly what each server needs: a competitive 5v5 benefits from 1000 fps for tight hitreg, a casual 10-slot fun server is perfectly smooth at 500. Set it per instance so you are not paying for fps a server does not use — see <a href="/tutorials/sys-ticrate-truth">sys_ticrate</a> and <a href="/tutorials/stable-1000-fps-linux-server">stable 1000 fps</a>.</p><h2>3. Fully separate configs, ports and content</h2><p>Each instance needs its own <code>server.cfg</code>, its own <code>+port</code> (27015, 27016, ...), its own RCON password, and ideally its own log directory so you can tell them apart:</p><pre>+port 27016 +maxplayers 24 +map de_dust2 +servercfgfile server2.cfg</pre><p>Sharing one config across instances is how you end up with two servers fighting over the same log file or announcing the same hostname. Keep them independent; they can share the read-only game files but not their runtime config.</p><h2>4. Force the performance governor once, for the whole box</h2><p>A single machine-wide setting benefits every instance: stop the cores downclocking between frames.</p><pre>cpupower frequency-set -g performance</pre><p>On a box packed with servers this is one of the highest-value changes — a core that drops to 800 MHz to "save power" between ticks introduces jitter across whatever instance lives on it. Detail in <a href="/tutorials/cpu-governor-performance">the performance governor guide</a>.</p><h2>5. Watch the shared resources</h2><p>Cores are isolated by pinning, but three things are shared and will bite you as you scale:</p><ul><li><strong>Aggregate CPU</strong> — read per-core, not total. Each pinned instance should sit below 100% on its own core at peak.</li><li><strong>RAM and precache</strong> — each instance loads its own copy of map models and sounds. Ten servers running heavy custom-content maps can exhaust RAM even when CPU is fine; watch <code>free -m</code> and keep <a href="/tutorials/precache-limits-performance">precache</a> lean per map.</li><li><strong>Bandwidth</strong> — every player on every server draws from one NIC. Do the <a href="/tutorials/bandwidth-math-cs16">bandwidth math</a>: total players × per-player rate must fit your uplink or every server chokes at once.</li></ul><h2>Common errors</h2><ul><li><strong>All servers stutter together at peak</strong> — shared bandwidth saturated, or the governor is powersave. Check the NIC and the governor first.</li><li><strong>One server lags, others fine</strong> — that instance's core is at 100% (a heavy plugin or fps target). Pin it and lighten its load.</li><li><strong>Instances drift between cores</strong> — you launched without <code>taskset</code>; the scheduler is migrating them.</li><li><strong>Out-of-memory kills a server</strong> — too many heavy-content maps loaded at once; trim precache and watch <code>free -m</code>.</li><li><strong>Two servers show the same name / share a log</strong> — they are reading the same config. Give each its own <code>server.cfg</code> and port.</li></ul><h2>Verification</h2><p>Load every instance to a realistic population simultaneously and watch per-core usage and memory:</p><pre>top -H | |
| 12 | +free -m</pre><p>Each pinned core should stay under 100% and total RAM should have headroom. Join each server and confirm <code>net_graph 3</code> shows zero choke on all of them at once — if choke appears on all servers together the moment they fill, it is a shared bottleneck (bandwidth or governor), not any single instance. Scale the number of servers to the number of cores minus one, and no further.</p> | |
| 0 | 13 |
