---
title: "Profiling Plugin Performance (Which Plugin Eats Your CPU)"
excerpt: "AMX Mod X has no built-in per-plugin profiler by default, so here is the honest toolkit: bisection with amxx pause, reading meta list and stats, and isolating the plugin that is dragging your fps down."
category: "optimization"
tags: "plugins, profiling"
image: ""
read_time: "8 min read"
---
<p>Your server fps sags under load and you suspect a plugin, but which one? The honest starting point: stock AMX Mod X does <strong>not</strong> ship an always-on per-plugin CPU profiler that hands you a milliseconds-per-plugin table. So the reliable technique is empirical — bisection — supported by the visibility tools the engine and AMXX do give you. This is the method experienced admins actually use to find the plugin eating a core.</p><h2>1. Establish a clean fps baseline</h2><p>You cannot spot a regression without a baseline. Under a realistic load (bots or a real population), read the server fps repeatedly:</p><pre>stats</pre><p>Note the steady <code>fps</code> figure with your full plugin set loaded. This is the number bisection will move. If you do not have a stable way to read it, set up <a href="/tutorials/measure-server-fps">fps measurement</a> first — a moving target makes bisection meaningless.</p><h2>2. Bisect with amxx pause</h2><p>The core technique: disable half your plugins, watch fps, and follow the half that changes it. <code>amxx pause</code> stops a plugin executing its forwards immediately for the current map, without editing files:</p><pre>amxx plugins
amxx pause someplugin.amxx</pre><p>Pause roughly half your loaded plugins, re-read <code>stats</code>, and see whether fps recovers. If it does, the culprit is in the paused half; unpause them and pause the other half to confirm. Then bisect within the guilty half — pause a quarter, then an eighth — until one plugin, when paused, restores your fps. That plugin is your CPU hog. This is the same divide-and-conquer used to find a crashing plugin in <a href="/tutorials/find-crashing-plugin">the crashing-plugin guide</a>, applied to fps instead of crashes.</p><h2>3. Read what is loaded and running</h2><p>Two listings tell you the state of everything so you bisect deliberately, not blindly:</p><pre>amxx plugins
meta list</pre><p><code>amxx plugins</code> shows each AMXX plugin as <code>running</code>, <code>paused</code> or <code>bad load</code>. <code>meta list</code> shows the Metamod modules (the heavier native code beneath AMXX) — a badly behaving Metamod plugin sits below AMXX and will not show as an <code>.amxx</code>, so if pausing every AMXX plugin does not help, the cost is in a Metamod module or the mod DLL itself.</p><h2>4. Reason about what makes a plugin expensive</h2><p>Bisection finds the plugin; understanding <em>why</em> lets you fix it. The expensive plugins are almost always the ones doing work <strong>every frame or every player, every tick</strong>: a plugin hooking <code>client_PreThink</code> / <code>FM_PlayerPreThink</code> and looping all players, running per-frame glow or knockback math, or doing string work in a high-frequency forward. A plugin that only fires on <code>DeathMsg</code> costs almost nothing; one that runs on every server frame costs 32× more on a full 32-slot server than an empty one, which is why the problem only appears under load. Match the plugin you found to how often its forwards fire.</p><h2>5. Confirm the fix, do not guess</h2><p>Once you have a suspect, prove it: pause it on a full server, confirm fps recovers and stays recovered for several minutes, then unpause and confirm fps drops again. That before/after is the proof — a one-off <code>stats</code> reading is too noisy. If the plugin is essential, look for a lighter replacement or a configuration that reduces its per-frame work (raise its task interval, disable its effects) rather than running it as-is. Some AMXX builds expose additional debug/JIT diagnostics, but the pause-and-measure loop above needs no special build and is what most admins rely on.</p><h2>Common errors</h2><ul><li><strong>Pausing every plugin barely changes fps</strong> — the cost is not in an AMXX plugin. Look at Metamod modules (<code>meta list</code>), the mod DLL, or a genuine CPU/engine bottleneck.</li><li><strong>fps recovers after pause but the plugin is essential</strong> — it is doing heavy per-frame work. Reduce its frequency or replace it, do not just live with it.</li><li><strong>Bisection results are inconsistent</strong> — the load is not steady (players joining/leaving). Use a fixed bot count so the baseline holds.</li><li><strong>Paused plugin comes back next map</strong> — <code>amxx pause</code> only lasts the current map; comment its line in <code>plugins.ini</code> to disable it durably.</li><li><strong>Expecting a built-in profiler table</strong> — stock AMXX does not provide one; bisection is the honest method.</li></ul><h2>Verification</h2><p>After identifying and disabling or fixing the culprit, load the server to full population again and confirm the fps baseline is restored and stable:</p><pre>stats
amxx plugins</pre><p>The <code>fps</code> figure under full load should now sit at or near your target, and the guilty plugin should be paused, removed, or reconfigured. Re-run the bisection occasionally after adding new plugins — the cheapest time to catch a CPU-hungry plugin is right after you install it, not after players complain. For fps problems that survive removing every plugin, the issue is engine or hardware; work through <a href="/tutorials/fix-hlds-100-cpu">HLDS at 100% CPU</a> and <a href="/tutorials/fix-low-server-fps-linux">low server fps on Linux</a>.</p>
