Optimizing GMod Tickrate, Addons, and Map Rotation to Reduce Lag: The Ultimate Performance Guide

Garry's Mod lag is almost always one of three things: tickrate set higher than the server can sustain, too many props and entities, or an addon doing work every tick. Memory is rarely the cause, which is why buying a bigger plan so often changes nothing.

Source runs its simulation on one thread. That single fact explains most of what follows.

Tickrate is a budget, not a quality setting

Tickrate is how many times per second the server simulates the world. Higher feels sharper, and higher costs CPU on every tick whether anything interesting is happening or not.

The trap is that tickrate multiplies everything else. A physics-heavy Sandbox server that copes at a lower tickrate can fall over at a higher one with no other change, because each prop is now being simulated more often.

• Sandbox is physics-heavy. Props, constraints and ragdolls all cost per tick, and players build more of them over time.
• TTT and DarkRP behave differently. Round-based gamemodes have spikes at round start; roleplay servers accumulate entities over hours.
• Raise tickrate only after the server is stable at the lower one. It is the last tuning step, not the first.

Props and entities are the real cost

On any long-running Sandbox or DarkRP server, entity count is the thing that grows without anyone deciding to grow it.

• Prop limits exist for a reason. A server with no cap will find its limit the hard way, usually during a build session.
• Constrained contraptions cost more than loose props. Physics constraints are solved every tick, and a large welded contraption is far more expensive than the same number of separate props.
• Cleanup on a schedule. Automatic prop cleanup between rounds or on a timer is the single most effective change on most servers.
• Ragdolls and gibs accumulate. They are cheap individually and not cheap in the hundreds.

Addons: the usual suspect nobody checks

An addon that runs work on every tick costs you sixty-plus times a second forever. Most do not advertise this.

• Add addons in small batches, so when performance drops you know what caused it.
• Be suspicious of anything that reacts to events anywhere on the map, rather than near a player.
• Workshop collections are downloads for every joining player. A large collection is a barrier to people joining as much as a load on the server. Sandbox build servers feel this most: see Sandbox mastery.

The same principle decides mod choice in Factorio: what does it cost per tick, and does everyone need it installed too.

Diagnose before you upgrade

Work through it in this order, because the cheap fixes are also the most likely:

1. Count entities. If the number climbs all day, that is the problem.
2. Turn off addons in batches and watch whether the floor lifts.
3. Lower tickrate one step and see if the stutter goes.
4. Check memory last. If it is not full and not sawtoothing, RAM is not your constraint.

This is the same order that applies to Minecraft tick lag, where more memory also fails to fix a CPU-bound server. Different game, identical mistake.

Our Garry's Mod server hosting exposes tickrate and addon management from the panel, so testing a lower tickrate takes a restart rather than a support ticket.

When the plan genuinely is too small

Memory is the constraint when you see the server killed rather than slowed: crashes on map change, or failure to load a large Workshop collection at startup. That is a real reason to move up a tier. A server that runs fine and stutters during builds is not.

If you are running a build server for six friends, the smallest plan and a prop limit will serve you better than a larger plan with no limit at all.