Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent bab3e001a8
commit 84f6984f3990e5810a98996e13deadbcbbfe0cf7
2 changed files
with 29 additions and 0 deletions
cpu-steal-time-vps/en.md
A
| @@ -0,0 +1,15 @@ | ||
| 1 | +--- | |
| 2 | +title: "CPU Steal Time: Why Your VPS Lags at Peak Hours" | |
| 3 | +excerpt: "What CPU steal time is, how to read the %st field in top and vmstat, why an oversold VPS lags exactly at peak, and what you can actually do about it." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "vps, cpu" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Here is a maddening pattern: your VPS runs a CS 1.6 server that is smooth at 3pm and stutters every evening at peak, even though your own CPU usage has not changed. The cause is almost always <strong>CPU steal time</strong> — the hypervisor is giving the physical core your vCPU maps to another tenant, and your server simply does not get to run when it needs to. You cannot cvar your way out of it; it is the host oversubscribing hardware. But you can prove it, and proof is what gets you a refund or a migration.</p><h2>1. What steal time actually is</h2><p>Your "vCPU" is a share of a real physical core scheduled by the host's hypervisor. When another VM on the same physical core is running, your vCPU is <em>ready</em> to run but is not being scheduled — that waiting time is <strong>steal</strong>. From inside your guest it looks like the CPU vanished: your process is runnable, nothing is using your CPU, yet work is not getting done. On an honest, non-oversold host, steal is essentially zero. On an oversold node it climbs exactly when neighbours get busy — evenings and weekends — which is why your lag tracks the clock, not your player count.</p><h2>2. Read %st in top</h2><p>Run <code>top</code> and look at the CPU summary line:</p><pre>%Cpu(s): 12.3 us, 4.1 sy, 0.0 ni, 78.2 id, 0.0 wa, 0.0 hi, 0.4 si, 5.0 st</pre><p>That trailing <code>st</code> is steal, as a percentage. <code>5.0 st</code> means 5% of wall-clock time your vCPU wanted to run and could not because the host gave the core to someone else. A few tenths is noise; sustained single or double digits is a problem, and it directly translates to a single-threaded game server missing its frame deadlines.</p><h2>3. Confirm with vmstat and mpstat</h2><p><code>vmstat</code> shows steal in its own column so you can watch it over time:</p><pre>vmstat 1 | |
| 10 | +# procs -----------cpu----------- | |
| 11 | +# r b us sy id wa st | |
| 12 | +# 1 0 9 3 80 0 8</pre><p>The final <code>st</code> column is steal. For per-core detail — useful because a <a href="/tutorials/cpu-affinity-taskset-hlds">pinned server</a> only cares about its core — use:</p><pre>mpstat -P ALL 1 | |
| 13 | +# watch the %steal column per CPU</pre><h2>4. Correlate steal with the lag</h2><p>Do not guess — log steal through a peak so you have evidence. Record it over an evening:</p><pre>sar -u 1 >> /var/log/steal-watch.log # %steal is in the output | |
| 14 | +# or a crude sampler: | |
| 15 | +while true; do date; vmstat 1 2 | tail -1; sleep 60; done</pre><p>If the <code>st</code> figure spikes at exactly the times players complain, you have your answer. Cross-check that your own core is not simply saturated — if <code>%us</code> is near 100% too, that is a <a href="/tutorials/best-cpu-for-cs16-server">CPU-speed problem</a>, not steal. Steal is specifically idle-you, busy-someone-else.</p><h2>5. What you can actually do</h2><p>Steal is the host's doing, so your options are about the host, not the guest:</p><ul><li><strong>Open a ticket with the evidence.</strong> A reputable host will migrate your VM to a less-loaded node when you show sustained steal. Many oversold budget hosts will not — which tells you what you bought.</li><li><strong>Buy a dedicated-vCPU plan.</strong> Some providers sell plans with guaranteed/pinned physical cores (often labelled "dedicated CPU"). Steal on those is near zero by contract.</li><li><strong>Move to a real box.</strong> A <a href="/tutorials/dedicated-vs-vps-performance">dedicated server</a> has no hypervisor and therefore no steal, ever. For a competitive server it is the honest fix.</li><li><strong>Migrate away.</strong> If a host consistently shows double-digit steal at peak, no cvar or upgrade tier fixes an oversold node — change provider. See <a href="/tutorials/cheap-hosting-vs-real-vps">cheap hosting vs a real VPS</a>.</li></ul><h2>Common mistakes</h2><ul><li><strong>Blaming your config for peak-hour lag</strong> — if steal spikes at peak and your CPU% did not, the config is innocent. Read <code>%st</code>.</li><li><strong>Confusing steal with your own load</strong> — high <code>%us</code> is you needing a faster core; high <code>%st</code> is the host not scheduling you.</li><li><strong>Confusing steal with <code>%wa</code></strong> — <code>wa</code> is I/O wait (disk), a different problem entirely.</li><li><strong>Accepting "it's normal"</strong> — sustained double-digit steal is not normal; it is oversubscription. Get evidence and escalate or leave.</li></ul><h2>Verification</h2><p>Leave a sampler running across a full peak window and read the log the next day. A healthy result is <code>st</code> hovering near <code>0.0</code> even while the box is busy with your own work; an unhealthy one is <code>st</code> climbing into the high single or double digits precisely when the server lags. If it is the latter, attach the log to a support ticket — concrete <code>vmstat</code>/<code>sar</code> output showing sustained steal is far harder for a host to wave away than "my server feels laggy." If they will not fix it, you now know to size your next move toward a dedicated-vCPU plan or a real machine.</p> |
optimize-32-slot-server/en.md
A
| @@ -0,0 +1,14 @@ | ||
| 1 | +--- | |
| 2 | +title: "Making a 32-Slot Server Feel Smooth" | |
| 3 | +excerpt: "The rates, update ceiling, stable fps, plugin discipline and entity budget that let a full 32-player CS 1.6 server feel as tight as a 10-slot one." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "slots, performance" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A 32-slot server is the hardest CS 1.6 workload to keep smooth: four times the entity updates of an 8-player game, four times the snapshot size, and four times as many plugin forwards firing every tick — all on <a href="/tutorials/is-hlds-single-threaded">one CPU core</a>. Most 32-slot servers feel spongy not because 32 players is impossible, but because the admin never scaled the netcode and CPU budget to match. Here is what makes a full 32-slot box feel tight.</p><h2>1. Scale sv_maxrate to the snapshot size</h2><p>Every additional player enlarges each world snapshot, and at 32 players the snapshot is large. If <code>sv_maxrate</code> is left at a value sized for a small server, updates get truncated and everyone chokes. Raise the byte budget:</p><pre>sv_maxupdaterate 100 | |
| 10 | +sv_maxrate 30000 | |
| 11 | +sv_minrate 7500 | |
| 12 | +sv_maxupdaterate 100</pre><p>A 32-slot server wants <code>sv_maxrate</code> around <code>30000</code> or higher — or <code>0</code> for unlimited on a box with real bandwidth headroom. But do the <a href="/tutorials/bandwidth-math-cs16">bandwidth math</a> first: 32 players at 30 KB/s each is nearly 1 MB/s of upload just for this one server. If your uplink cannot sustain it, cap the rate lower and accept the trade-off rather than inducing loss.</p><h2>2. Hold a genuinely stable high fps</h2><p>At 32 players the server must emit 32 × up-to-100 updates per second, and it can only do that if it runs well above 100 fps with no dips. A server that holds 1000 fps at 8 players but collapses to 300 at 32 will choke every high-rate client the moment it fills. Target and verify a stable 1000 fps <em>under full load</em>, not empty:</p><pre>stats</pre><p>Read the <code>fps</code> column with the server full. If it sags as players join, the CPU is the bottleneck — see <a href="/tutorials/fix-server-fps-drops-with-players">fps drops with players</a> and <a href="/tutorials/stable-1000-fps-linux-server">stable 1000 fps</a>.</p><h2>3. Be ruthless about plugins</h2><p>Every AMXX plugin runs on the same single core as the game, and heavy per-frame or per-player plugins scale their cost by 32. A plugin that iterates all players every <code>PreThink</code> is running 32 times as often as on an 8-slot server. Audit what you load: disable eye-candy and per-frame effect plugins on a 32-slot box, and profile which ones cost the most (bisect by disabling half and watching fps — see <a href="/tutorials/profile-plugin-performance">profiling plugin performance</a>). A smooth 32-slot server runs a lean plugin set, not a kitchen sink.</p><h2>4. Budget entities and precache</h2><p>32 players plus their weapons, grenades, corpses and any effect entities push toward the engine's edict ceiling fast. Hitting it crashes the server or silently drops entities. Keep custom content lean, avoid maps that spawn hundreds of decorative entities, and watch the edict count — the failure mode and fix are in <a href="/tutorials/fix-max-edicts-too-many-entities">too many entities / max edicts</a> and the ceilings in <a href="/tutorials/precache-limits-performance">precache limits</a>.</p><h2>5. Put it on the right CPU</h2><p>Because the whole load is on one core, a 32-slot server lives or dies by single-thread speed. A high-clock modern core holds 32 players and 1000 fps comfortably; an old low-clock core will not, no matter how many cores the box has. If you are provisioning for 32 slots specifically, read <a href="/tutorials/best-cpu-for-cs16-server">the best CPU guide</a> and run <a href="/tutorials/hlds-vs-rehlds-explained">ReHLDS</a>, which carries a full server more efficiently than stock HLDS. Force the <a href="/tutorials/cpu-governor-performance">performance governor</a> so the core never downclocks mid-round.</p><h2>Common errors</h2><ul><li><strong>Smooth at 16, spongy at 32</strong> — <code>sv_maxrate</code> too small for the larger snapshot, or fps collapsing under load. Raise the rate and fix fps.</li><li><strong>Everyone chokes when it fills</strong> — server fps is below sv_maxupdaterate at full load. The core is saturated; lighten plugins or move to a faster CPU.</li><li><strong>Random entity errors on a busy map</strong> — edict ceiling. Trim entities; see the max-edicts guide.</li><li><strong>High loss instead of choke after raising maxrate</strong> — you exceeded real uplink bandwidth. Do the bandwidth math and cap accordingly.</li><li><strong>fps fine but feels laggy</strong> — jitter from a downclocking core or a heavy per-frame plugin. Force the governor and profile plugins.</li></ul><h2>Verification</h2><p>Fill the server (or use bots to 32) and read the numbers under real load:</p><pre>stats | |
| 13 | +sv_maxrate | |
| 14 | +sv_maxupdaterate</pre><p>Confirm <code>fps</code> stays high with 32 players, the rate ceilings are sized for the population, and a connected client shows zero choke on <a href="/tutorials/cs16-net-graph-guide">net_graph 3</a>. If it is tight at 32, you have scaled correctly; if it degrades only when full, the bottleneck is CPU or bandwidth, not any single cvar.</p> | |
| 0 | 15 |
