Why trust this guide
By Victus Cloud · Reviewed by Victus Cloud · No individual author claimed. Verify paths, versions, and backups before changing a live service.
Evidence-led, product-agnostic
First identify which kind of ‘lag’ you have
Players use one word for several failures. Low server TPS makes mobs, redstone, block actions, and commands advance slowly for everyone. High network latency delays communication for an affected route or player while the server may tick normally. Packet loss creates bursts, rubber-banding, or disconnects. Low client FPS makes rendering stutter even when the server and network are healthy. Startup, save, or chunk-generation pauses are workload events rather than a permanent capacity verdict. Diagnose the layer before buying more RAM or changing ten settings.
| Observation | Likely layer | Confirm with |
|---|---|---|
| All players see slow mobs and delayed commands | Server tick workload | MSPT/TPS and a profiler during the event |
| One region or ISP is affected; TPS remains healthy | Network path or packet loss | Timestamped ping/path tests from affected players |
| One player has choppy visuals but actions register | Client rendering | Client FPS, mods, render settings, another device |
| Pauses happen only while exploring new terrain | Chunk generation/storage/CPU work | Profiler plus reproduction in generated vs new chunks |
| Failure aligns with backup, map render, or restart | Scheduled task | Panel schedule, console timestamps, disk activity |
Do not infer plan behavior
Victus CPU allocation, network filtering, metrics, locations, and backup scheduling differ by current service and plan. Verify the panel and plan. A panel graph is evidence, but its percentage scale may describe the service limit rather than an entire physical host.
Capture a precise incident window
Write down the start and end time with timezone, affected players, dimensions and coordinates, actions underway, recent changes, and whether the problem stopped without intervention. Save the full console log and avoid restarting until you have collected safe diagnostics; restarting can erase the condition and rotate logs. If the server is unresponsive or data is at risk, recovery takes priority—stop it through the supported panel control rather than repeatedly sending commands.
- Reproduce one symptom with a known player and location.
- Check tick time and server logs during that exact minute.
- Correlate panel CPU, memory, storage, and network views if your plan exposes them.
- Run a short profiler for the incident, not an hours-long capture by default.
- Change one cause, repeat the same test, and compare the evidence.
Interpret TPS and MSPT correctly
Minecraft targets 20 ticks per second, which gives each tick 50 milliseconds. MSPT is the more direct measurement: sustained work above that budget forces TPS down. A displayed TPS of 20 can hide reduced headroom, and a single spike can be harmless. Look at sustained values, high percentiles, and what happened at the time. Command names and metrics differ among Paper, other server software, plugins, and versions.
mspt
tps
versionRun commands in the server console or with appropriate in-game permission. Do not install a profiler in the middle of an outage without understanding its compatibility. Current Paper versions include tooling and support the spark profiler ecosystem; follow the documentation for your exact build. Profiling has overhead, so use a focused duration and stop it when the representative event is captured. Review or redact player names, IP addresses, coordinates, plugin secrets, and URLs before sharing reports publicly.
spark profiler start --timeout 60Read a profile as a map of time, not a blame list
A profile attributes sampled execution time to call stacks. Start at the server tick and expand the busiest paths during the slow window. A plugin name high in a tree may mean the plugin is expensive, or simply that it is processing an unusually large world condition. Compare a healthy capture. Look for entity ticking, block entities, chunk generation or loading, redstone, pathfinding, synchronous database or web calls, world saves, garbage collection, and map rendering.
- Entity-heavy path: inspect counts and locations, then test the farm or mechanic rather than deleting all entities.
- Chunk-generation path: compare existing terrain, pre-generate within a chosen border, and control exploration distance.
- Plugin path: update from the official source, inspect configuration, and reproduce with the plugin disabled on a copy.
- Garbage-collection path: inspect live heap and allocation pressure before changing flags or memory.
- Save or storage path: compare timestamps, world size, free space, backup jobs, and errors; do not assume the storage medium.
Test common causes with reversible changes
View distance controls chunks sent to players, while simulation distance controls how far game logic actively ticks; exact behavior varies by version and software. Lowering them can reduce work but changes gameplay, so record old values, change modestly, and retest at peak. Entity activation, hopper behavior, mob caps, and redstone settings can help in specific cases, but copying a generic optimization file can break mechanics. Prefer documented defaults and understand every changed key.
For plugins, make a backup and use a staging copy or maintenance window. Update one suspect, test, then roll back if needed. For farms or dense regions, teleport to and away from the location while profiling. For generation, compare travel inside pre-generated terrain and beyond it. For scheduled tasks, temporarily move the job to another safe time rather than deleting backups. Evidence should connect the intervention to the same reproducible symptom.
When TPS is healthy, investigate the route
Ask several affected and unaffected players for timestamped tests to the server address. Basic ping can show latency and loss but some networks deprioritize ICMP, so do not treat it as a perfect game-traffic test. A path trace can show where latency begins, but intermediate hops may ignore probes while forwarding traffic normally. Compare patterns across players and networks. Do not post a server IP or player IP publicly if it should remain private.
# Windows
ping -n 30 your-server.example
tracert your-server.example
# Linux/macOS
ping -c 30 your-server.example
traceroute your-server.exampleIf one home connection is affected, test a wired connection, stop local saturation, and compare another network. If many players on different providers show the same change at the same time while TPS is healthy, provide Victus support with service identifier, timestamps, player regions and providers, destination, and redacted test output. Avoid claiming a specific attack or host fault without evidence; filtering events, transit changes, local congestion, and application traffic can look similar from a single perspective.
Treat memory graphs and crashes separately
A rising-and-falling Java heap is normal. A memory limit event, out-of-memory stack trace, or process kill needs its own investigation. Adding RAM may address genuine pressure but will not normally reduce a CPU-bound tick path. Conversely, reducing memory to force frequent collection can create pauses. Keep the server's configured heap within its service limit with room for non-heap/native use, and rely on panel startup controls where they manage allocation.
Build an actionable support bundle
A useful report states expected and actual behavior, exact UTC timestamp, duration, software/build, plugin/mod changes, current distances, peak players, full relevant log, profiler link or export with privacy review, and network evidence when appropriate. Say what you already tested and what changed. Do not send passwords, API tokens, database strings, or unredacted personal information. A short, evidence-rich report is easier to route than ‘server lagging.’
Close the incident by documenting the confirmed cause, change, before/after measurement, rollback path, and follow-up. If no single cause is proven, say so. Capacity decisions should follow repeated representative measurements, not the temporary improvement after any restart. That discipline prevents placebo tuning and keeps the next operator from repeating the same investigation.