Your server fps sags under load and you suspect a plugin, but which one? The honest starting point: stock AMX Mod X does not 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.
You cannot spot a regression without a baseline. Under a realistic load (bots or a real population), read the server fps repeatedly:
stats
Note the steady fps 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 fps measurement first — a moving target makes bisection meaningless.
The core technique: disable half your plugins, watch fps, and follow the half that changes it. amxx pause stops a plugin executing its forwards immediately for the current map, without editing files:
amxx plugins amxx pause someplugin.amxx
Pause roughly half your loaded plugins, re-read stats, 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 the crashing-plugin guide, applied to fps instead of crashes.
Two listings tell you the state of everything so you bisect deliberately, not blindly:
amxx plugins meta list
amxx plugins shows each AMXX plugin as running, paused or bad load. meta list shows the Metamod modules (the heavier native code beneath AMXX) — a badly behaving Metamod plugin sits below AMXX and will not show as an .amxx, so if pausing every AMXX plugin does not help, the cost is in a Metamod module or the mod DLL itself.
Bisection finds the plugin; understanding why lets you fix it. The expensive plugins are almost always the ones doing work every frame or every player, every tick: a plugin hooking client_PreThink / FM_PlayerPreThink 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 DeathMsg 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.
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 stats 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.
meta list), the mod DLL, or a genuine CPU/engine bottleneck.amxx pause only lasts the current map; comment its line in plugins.ini to disable it durably.After identifying and disabling or fixing the culprit, load the server to full population again and confirm the fps baseline is restored and stable:
stats amxx plugins
The fps 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 HLDS at 100% CPU and low server fps on Linux.