Garry's Mod Low FPS, Stutter and Server Lag
Most Garry's Mod performance advice fails at the first step, because it treats "my game runs badly" as one problem. It is two. Low frames per second is your own machine failing to draw the picture. Lag, rubber-banding and delayed hits are the server or the network failing to agree with you about the state of the world. Separate causes, separate fixes, and nothing you do to one helps the other.
Telling the two apart in thirty seconds
Stand still, touch nothing, and turn your view with the mouse. Rendering is entirely local: the server is not consulted when your camera rotates. If the camera moves in visible steps, you have a frames problem and it lives on your machine. If the camera is glassy smooth, your frames are fine whatever the rest of the session feels like.
Now walk forward. If you slide back to where you started, or a prop moves half a second after you pushed it, the picture is being drawn correctly and the world is arriving late. That is the server or the route to it.
Then ask the other players. A server fault hits everybody at the same instant. A client fault follows one person to every server they join.
The fastest wrong turn: buying more RAM, or a bigger server plan, to fix low frames. Frames are drawn on your computer. A server upgrade cannot raise them, and no honest host will tell you otherwise.
Symptom table
| Symptom | Which side | What to check |
|---|---|---|
| Low frames everywhere, including the main menu and single player | Client | Graphics settings, resolution, addon count, and whether you are on the 32-bit or 64-bit build. |
| Low frames only in one area of one map | Client, caused by the map | Load gm_construct as a control. If frames recover, the map is the cause. |
| Stutter on a fixed interval, every few seconds | Either | Does it hit everyone at the same instant? Yes means server Lua on a timer. No means your machine is loading assets. |
| Rubber-banding, you walk forward and snap back | Server or network | Your ping, packet loss, and whether the server holds its frame time under load. |
| Damage and physics resolve late, but the view is smooth | Server | Prop count, nextbot count, active player count, gamemode Lua. |
| Everyone lags at the same moment | Server | Server CPU. Something on the box is stalling the tick. |
| Only you lag, everyone else is fine | Your connection or your route | Wired instead of wireless, and your physical distance to the server region. |
Engine Error reading CMDLCache:: Out of memory | Client, and it is not a memory shortage | Address space, not RAM. See the 64-bit section below. |
Client side: what actually costs you frames
Addon count is a real and largely invisible cost. Garry's Mod loads every directory under garrysmod/addons/. There is no per-folder enable switch at the file system level, so a collection somebody subscribed to two years ago and forgot about is still being read today.
Prove it instead of guessing. Facepunch documents two launch parameters for exactly this: -noaddons, which "Temporarily disables folder/legacy addons", and -noworkshop, which "Temporarily disables Steam Workshop addons".
-noaddons -noworkshopIf frames recover, your content is the cause and you bisect the collection in halves until you find the offender. If nothing changes, stop blaming addons and look at settings and hardware.
The 64-bit change is directly relevant. The September 2026 update went live on 16 September 2026 at 15:00 UTC with 64-bit binaries for the Windows client, dedicated servers and Hammer. In the developers' own words it means "there's now less risk of running out of the 32-bit memory address space and subsequently crashing when playing on heavy servers or with a lot of addons installed". A 32-bit process cannot address more than roughly 4 GB no matter how much memory is installed, which is precisely why buying more RAM never fixed the CMDLCache:: Out of memory crash. The machine was never short of memory. The process was short of address space.
Map quality is a genuine cause. A dedicated server install ships with two maps, gm_construct and gm_flatgrass. Everything else is community content of wildly varying build quality, and a map compiled without proper visibility work makes your graphics card draw rooms you cannot see. If frames collapse on one map and hold up on gm_flatgrass, it is not your hardware.
Server side: what actually costs the operator
Source runs the game simulation on one thread. Server performance is therefore a single-thread CPU story, and slot count means little on its own.
- Slots versus simulation.
maxplayersis permission to fill the server, not a statement about what it can simulate. Thirty-two players standing in a lobby cost less than eight players building contraptions. - Physics props. Props are simulated server side. A sandbox server where players spawn thousands of props is a server CPU problem, and it reaches players as lag, never as low frames.
gmod_physiterationscontrols how hard the physics solver works per step: raising it buys stability in complicated contraptions and costs more CPU, so it can make lag worse rather than better. - Nextbots. Nextbots navigate using the navmesh system, and that pathfinding runs on the server. A player who spawns fifty of them is not hurting their own frames, they are eating the tick for everybody.
- The gamemode. The
gamemodeconvar decides how much persistent per-player state the server carries. A roleplay gamemode with jobs, entities and an economy is a different workload from sandbox at the same player count. - Addon Lua on every tick. Facepunch is explicit that code in
TickandThinkhooks runs many times per second. One addon looping over every player insideThinkcan cost more than the rest of the server combined. The documented habit isplayer.Iterator()rather thanplayer.GetAll(), which allocates a table on every call. - Hibernation. On an empty server,
ThinkandTickdo not run unlesssv_hibernate_thinkis set to 1. Setting it keeps timers advancing on an empty server, and keeps the server burning CPU when nobody is playing.
One honest correction: sv_pure, sv_downloadurl, sv_allowdownload, sv_loadingurl and host_workshop_collection govern content delivery, not simulation speed. They are the usual cause of a four minute join, which players report as lag because it feels like one. It is not.
Measure instead of guessing
- The Net Graph. The in-game overlay puts frames, ping and network traffic on one display, which is exactly the split this page is about. Facepunch has since improved it to show Lua net messages in their own colour.
- Server frame time, read from a client.
engine.ServerFrameTime()returns an estimate of the server's performance plus a standard deviation of the server frame rate. That deviation is the numeric form of "the server hitches": a rising figure means uneven ticks, not merely slow ones. - Benchmark a suspect addon.
SysTime()is precise enough for basic benchmarking. Run any measurement several times, because LuaJIT compilation and current server load both move the number. - Read real values.
findsearches the console commands andcvarlistprints every loaded convar.cvarlistoverruns the console buffer, so launch with-condebugand readconsole.txtin thegarrysmodfolder instead of trusting any guide about what a default is. - Slow startup. The
-timersparameter logs load timers toTimerLog.txt, which turns "the server takes forever to boot" into a list with numbers next to it.
When it is the host, and when it is not
Ping is dominated by physical distance and network route. A player in Sydney will not get a 30 ms ping to a server in Frankfurt, and no configuration change alters the speed of light. If your ping is high but perfectly steady, with no packet loss and no hitching, that is geography. The fix is a server in a closer region, not a bigger server.
It is the host when frame time degrades as players join, when every player hitches at the same instant, or when the box behaves badly with a small, clean addon set. It is not the host when your frames are low on the main menu, when your view is smooth but only your movement misbehaves, or when one player in ten has the problem.
Sizing that follows from all this
- Small sandbox for friends: single-thread CPU speed matters far more than core count or slot count.
- Prop-heavy sandbox: the ceiling is the physics tick. Slots past roughly sixteen are decoration if eight builders can already stall the server.
- Nextbots or a scripted gamemode: budget CPU per active player rather than per slot, and test with the real gamemode rather than sandbox.
- Memory: after the 64-bit update a server with a very large collection can genuinely use past 4 GB. Before it could not, whatever the plan said.
- Disk: Workshop cache and logs grow on a long-lived server, so leave headroom.
Facepunch publishes its own guidance on what is expensive in Lua and how to measure it: Optimization Tips.
Related Garry's Mod guides
- The September 2026 update and 64-bit binaries
- Server hardware requirements
- Startup flags and server.cfg
- Workshop collections and addons
- Nextbots and navmesh
- Maps and map quality
- Gamemodes
- Connection troubleshooting
Want single-thread CPU headroom and a region close to your players without sizing it yourself? Managed Garry's Mod hosting puts the server on fast cores in the region you pick.