Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent ef6a965ac3
commit 004dd9139c1ea3cc675ec66a4795039f7652b0fb
2 changed files
with 20 additions and 0 deletions
dedicated-vs-vps-performance/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Dedicated Server vs VPS for CS 1.6 Performance" | |
| 3 | +excerpt: "The real performance difference between a dedicated server and a VPS for CS 1.6, when shared hosting is fine, and when steal-free dedicated hardware is worth the cost." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "vps, hardware" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The dedicated-versus-VPS question for CS 1.6 comes down to one word: <strong>steal</strong>. A VPS shares physical cores with other tenants through a hypervisor, so under contention your single-threaded server can be denied the CPU it needs. A dedicated server has no hypervisor and no neighbours, so it never loses a cycle to anyone. Everything else — price, flexibility, management — flows from that one architectural difference. Here is how to decide which you actually need.</p><h2>1. The core difference</h2><table><thead><tr><th></th><th>VPS</th><th>Dedicated</th></tr></thead><tbody><tr><td>CPU cores</td><td>Shared vCPUs, scheduled by the host</td><td>Full physical cores, all yours</td></tr><tr><td>Steal time</td><td>Possible, worse on oversold nodes</td><td>None, ever</td></tr><tr><td>FPS consistency</td><td>Varies with neighbours</td><td>Rock-steady</td></tr><tr><td>Price</td><td>Cheap, pay per slice</td><td>Higher, whole machine</td></tr><tr><td>Flexibility</td><td>Resize/redeploy in minutes</td><td>Fixed hardware, slower to change</td></tr></tbody></table><h2>2. Why steal is the whole story</h2><p>CS 1.6 is <a href="/tutorials/is-hlds-single-threaded">single-threaded per server</a>, so it needs one core to be available the instant a frame is due. On a VPS, when a neighbour spikes, the hypervisor may hand your core away for a slice of time — that is <a href="/tutorials/cpu-steal-time-vps">steal</a>, and it shows as evening lag that tracks the clock rather than your player count. A dedicated box has no one to steal for, so its <a href="/tutorials/measure-server-fps">server FPS</a> holds flat at peak. For a competitive server where hit registration must be consistent, that consistency is the product.</p><h2>3. When a VPS is the right call</h2><p>A VPS is not a compromise for most servers — it is the sensible default when:</p><ul><li>You run a <strong>public / casual</strong> server where a few ms of jitter at peak is invisible to players.</li><li>You want to <strong>start small and cheap</strong> and scale later.</li><li>You value being able to <strong>resize or redeploy</strong> in minutes.</li><li>You pick a host with <strong>low steal</strong> — a good VPS on a non-oversold node performs indistinguishably from bare metal for one or two servers.</li></ul><p>The failure mode is not "VPS" — it is a <a href="/tutorials/cheap-hosting-vs-real-vps">cheap oversold VPS</a>. A quality VPS with a fast core and near-zero steal runs a smooth server.</p><h2>4. When dedicated earns its cost</h2><p>Go dedicated when:</p><ul><li>You run a <strong>competitive / match</strong> server where consistent tick and hit-reg are non-negotiable.</li><li>You host <strong>many servers</strong> and want guaranteed cores per instance without fighting neighbours — see <a href="/tutorials/multiple-cs16-servers-one-vps">packing many servers</a>, which is far more predictable on owned cores.</li><li>You have measured <strong>persistent steal</strong> on VPS plans and no host will fix it.</li><li>You want to set the <a href="/tutorials/cpu-governor-performance"><code>performance</code> governor</a> and <a href="/tutorials/cpu-affinity-taskset-hlds">pin cores</a> — things you fully control only on bare metal.</li></ul><h2>5. The middle ground: dedicated-vCPU VPS</h2><p>Many providers now sell a tier variously called "dedicated CPU" or "CPU-optimized" — a VPS whose vCPUs map to reserved physical cores that are not shared. This gives you near-dedicated steal behaviour (effectively zero by design) at a price between a shared VPS and a whole machine, while keeping VPS flexibility. For a competitive single server it is often the sweet spot: you get the consistency that matters without paying for a full box you will not fill. Confirm the plan genuinely pins cores — ask, and then measure steal to verify.</p><h2>6. Control you gain on bare metal</h2><p>Beyond steal, a dedicated machine hands you low-level tuning that a VPS simply does not expose. You can set the <a href="/tutorials/cpu-governor-performance">CPU frequency governor</a>, disable deep idle C-states, place NIC interrupts on a dedicated core, and <a href="/tutorials/cpu-affinity-taskset-hlds">pin each server to its own core</a> — all of which shave jitter off a high-FPS server. On a typical VPS, <code>scaling_governor</code> may not even exist because the host owns frequency policy, so those levers are off the table. For most public servers this control is not worth the price difference; for a lag-sensitive competitive server it is part of what you are paying for. Weigh it honestly: if you would never touch a governor or an IRQ affinity mask, you are not buying anything the extra money on bare metal unlocks, and a good <a href="/tutorials/cheap-hosting-vs-real-vps">low-steal VPS</a> is the smarter spend.</p><h2>Common mistakes</h2><ul><li><strong>Assuming VPS = bad</strong> — a good VPS with low steal is fine for most servers. The enemy is oversubscription, not virtualization.</li><li><strong>Paying for dedicated you don't need</strong> — a casual public server does not benefit enough to justify a whole machine. Match the tier to the need.</li><li><strong>Buying a shared VPS for a competitive server</strong> — peak-hour steal will bite exactly when the match matters. Use dedicated or a dedicated-vCPU plan.</li><li><strong>Not measuring</strong> — decide with <code>%st</code> from a trial, not with the label on the plan.</li></ul><h2>Verification</h2><p>Whichever you choose, prove it before you commit the community to it. On a trial VPS, run <code>vmstat 1</code> and <code>top</code> through an evening peak and read the <code>st</code> column — near zero means the shared plan is good enough; sustained double digits means you need dedicated or a dedicated-vCPU tier. On a dedicated box, confirm steal is a flat <code>0.0</code> (it will be) and that your <a href="/tutorials/measure-server-fps">server FPS</a> holds steady at peak population. The decision is not ideological — it is whatever keeps <code>%st</code> at zero and FPS flat for the money you want to spend.</p> |
precache-limits-performance/en.md
A
| @@ -0,0 +1,11 @@ | ||
| 1 | +--- | |
| 2 | +title: "Precache Limits (Models, Sounds, Generic) and Performance" | |
| 3 | +excerpt: "The engine's hard ceilings on precached models, sounds and generic files, the exact overflow errors they throw, and how to stay under them while keeping load times and memory sane." | |
| 4 | +category: "optimization" | |
| 5 | +tags: "precache, limits" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Precache is how the GoldSrc engine registers, at map load, every model, sound and file it might need to send to a client. The engine has <strong>hard ceilings</strong> on how many of each it can register, and crossing one does not degrade gracefully — it crashes the map load with a specific error. Every admin running custom content or heavy mods eventually meets these limits, so it pays to know exactly where they are and how to live under them.</p><h2>1. The ceilings you are working against</h2><p>The engine reserves a fixed number of slots for each precache category. The historically documented limits are:</p><table><thead><tr><th>Category</th><th>Registered with</th><th>Approx. limit</th></tr></thead><tbody><tr><td>Models</td><td><code>precache_model</code></td><td>512 (<code>MAX_MODELS</code>)</td></tr><tr><td>Sounds</td><td><code>precache_sound</code></td><td>512 (<code>MAX_SOUNDS</code>)</td></tr><tr><td>Generic files</td><td><code>precache_generic</code></td><td>512 (<code>MAX_GENERIC</code>)</td></tr><tr><td>Events</td><td><code>precache_event</code></td><td>bounded, separate pool</td></tr></tbody></table><p>These include everything the map and every loaded plugin registers together — the map's own models plus every model a mod or plugin precaches. On a heavy zombie or fun server it is the <em>plugins</em>, not the map, that blow the budget.</p><h2>2. The errors an overflow throws</h2><p>When you exceed a ceiling the map fails to load with one of these, which is exactly what people paste into search:</p><pre>Host_Error: PF_precache_model_I: Model <name> failed to precache because it was > MAX_MODELS | |
| 10 | +Host_Error: PF_precache_sound_I: Sound <name> failed to precache | |
| 11 | +SZ_GetSpace: overflow</pre><p>The model and sound errors name the specific file that pushed you over — useful, but that file is only the last straw, not the culprit. The real problem is the total count. The dedicated fixes are in <a href="/tutorials/fix-model-overflow-precache">model overflow</a> and <a href="/tutorials/fix-sound-slots-overflow">sound slots overflow</a>.</p><h2>3. Reduce the count, do not chase the file</h2><p>Because the error names the last file, the instinct is to remove that one file — but then the next one over the line simply fails instead. Attack the total:</p><ul><li><strong>Cut custom content you do not use.</strong> Half-configured mods precache models and sounds for features you never enabled.</li><li><strong>Share models between entities and classes.</strong> Ten zombie classes pointing at three shared models cost three slots, not ten.</li><li><strong>Precache only what is actually used on this map.</strong> A plugin that unconditionally precaches its whole asset set on every map wastes slots on maps that never use them.</li></ul><h2>4. Precache costs load time and memory too</h2><p>The ceilings are the hard wall, but precache has a soft cost as well. Everything precached is loaded into memory at map start and contributes to the load time and per-instance RAM. On a box <a href="/tutorials/many-servers-one-box">running several servers</a>, each instance holds its own copy of everything it precaches, so a bloated precache list multiplies across instances and can exhaust RAM long before CPU is the problem. A lean precache list loads faster and leaves more memory for the OS and neighbours.</p><h2>5. Order and duplicates</h2><p>Precaching the same model twice does not consume two slots — the engine returns the existing index — but sloppy code that precaches in a loop or precaches conditionally in the wrong forward can register far more than intended. Precache in <code>plugin_precache()</code> (the correct forward, called before the map spawns entities), not lazily at runtime, where a precache of a never-before-seen file can crash a live server rather than just failing at load. This is also why adding a model mid-map is dangerous.</p><h2>Common errors</h2><ul><li><strong><code>MAX_MODELS</code> on map load</strong> — total precached models exceed 512. Cut and share models; the named file is just the last one.</li><li><strong>Sound precache fails</strong> — over the sound ceiling. Remove unused custom WAVs, especially from half-enabled mods.</li><li><strong><code>SZ_GetSpace: overflow</code></strong> — a message or resource list grew past the engine buffer, often from too many resources announced to clients at once. Reduce custom content.</li><li><strong>Removed the named file, a different one now fails</strong> — you are at the ceiling; removing one file just promotes the next. Reduce the total count.</li><li><strong>Precache crashes a live server, not at load</strong> — something precached at runtime instead of in <code>plugin_precache()</code>. Move it to the precache forward.</li></ul><h2>Verification</h2><p>Load your heaviest map with every plugin enabled and confirm it reaches gameplay with no <code>Host_Error</code> precache line in the console or <a href="/tutorials/measure-server-fps">logs</a>. If it loads clean, you are under the ceilings; to know your margin, count the custom models and sounds your mod registers and keep a comfortable buffer under 512 each so a future map addition does not tip you over. For the entity-count ceiling — a related but separate limit — see <a href="/tutorials/fix-max-edicts-too-many-entities">too many entities / max edicts</a>.</p> | |
| 0 | 12 |
