How to Reduce Game Server Lag: Tickrate, RAM, and Network

What actually causes server lag

The four main causes are distinct from each other. Treating them all as "ping problems" wastes time on the wrong fix.

Key diagnostic question: is it just one player lagging, or everyone simultaneously? If one player, it is almost certainly their connection. If everyone, it is the server.

What tickrate actually is

A game server runs a loop: read player inputs, simulate physics and game logic, send updated state to all players. The number of times this loop runs per second is the tick rate.

Network lag vs server lag

These are different problems. Confusing them wastes time on the wrong fix.

Run net_graph 1 in the GMod console. The sv value is server tick time. If it is consistently above 30ms on a 33-tick server, the server is struggling to keep up with its own tick rate.

Latency from UK players to our Germany servers is typically 15-40ms. If a player sees 200ms ping, it is their routing, not the server location.

RAM and CPU causes

How addons cause lag and how to find them

Every server-side addon in GMod runs Lua code. The worst offenders use hook.Add("Think", ...) or hook.Add("Tick", ...) to run expensive operations 33 times per second. Multiplied across dozens of addons, this is where server performance disappears.

Using the GMod profiler

-- Start profiling (run in server console)
lua_run gm.Profiler.Start()

-- ... let the server run for 1-2 minutes ...

-- Stop and view results
lua_run gm.Profiler.Stop()

The profiler output shows which hooks consume the most CPU time per tick. Common offenders: frequent database queries, large table scans in Think hooks, and event scripts that do unnecessary work when nothing relevant has happened.

Fixing Think hook lag

-- Expensive: runs 33x per second
hook.Add("Think", "myCheck", function()
    -- expensive database query
end)

-- Better: runs once per second
timer.Create("myCheck", 1, 0, function()
    -- same expensive query
end)

Practical steps to fix server lag

1. Check the profiler first. Do not disable addons randomly. Use gm_profiler to find which hooks are actually expensive before making changes.
2. Replace Think hooks with timers. timer.Create running once per second instead of 33 times cuts the overhead by 97%.
3. Limit physics objects. Set sbox_maxprops to a reasonable number. Unlimited props cause physics overload.
4. Schedule daily restarts. A restart at low-traffic hours resets Lua garbage, clears accumulated memory, and keeps the server stable. Most panel schedule configurations support this.
5. Audit your addon list. An addon installed six months ago that nobody uses is still running code every tick. Remove it.
6. Watch for "Server is running too slow!" in the console. This confirms CPU is the constraint.
7. For Rust: reduce world size if possible, or lower server.tickrate (default 10) to 5-7 on a CPU-limited server.
8. For Minecraft: use Paper's recommended JVM flags for garbage collection. Default GC settings are not optimised for server use under player load.

What your host can and cannot control

Lag caused by a slow Lua script is not fixed by upgrading your plan. More RAM or CPU helps if those resources are the bottleneck, but bad code is bad code regardless of hardware. The Zeros Host panel includes Server Vitals with live CPU and RAM graphs so you can see whether the issue is hardware or application-level code.

Frequently asked questions