Hytale Server Performance Guide: View Distance, RAM and Lag Fixes
Hytale server lag has a few well-understood causes, and most of them trace back to two things: how many players and entities the server is simulating, and how much of the world it keeps loaded around them. The official Hytale Server Manual says it directly: resource use depends heavily on player behaviour, CPU load tends to come from high player or entity counts, and memory use comes mainly from a large loaded world area.
This guide turns that into a routine you can follow. It starts with what the manual states, then covers view distance, memory flags, the pre-trained AOT cache, and a symptom-based way to diagnose lag from the ChicagoServers panel. Hytale has been in Early Access since January 13, 2026, and performance behaviour changes with updates. Figures from hosting providers and community guides (sizing tables, default values, plugin names) are marked as such, because they are not official and some conflict with each other.
- Official: the minimum is 4 GB of RAM with Java 25, on x64 or arm64. CPU load follows player and entity counts, and RAM follows view distance and the loaded world area.
- Official: the recommended maximum view distance is 12 chunks (384 blocks), and the manual puts the default at 384 blocks against Minecraft's 160. View distance is described as the main driver of RAM use.
- Heavy garbage collection that pushes CPU up is the manual's described symptom of memory pressure. The manual's suggestion is to experiment with Java's
-Xmxvalue. - The shipped AOT cache (
HytaleServer.aot) speeds up boot by skipping JIT warmup. It is a startup feature, not a tick-rate fix. - On the panel, watch CPU, Memory and Players at the top of the server page, the Analytics tab over time, and the Console and Troubleshoot tabs when something goes wrong.
On this page
What drives CPU and RAM
The manual's requirements section gives the baseline: at least 4 GB of memory and Java 25, on x64 or arm64 hardware. Beyond that it is deliberately general, and the shape of the advice is more useful than any single number:
| Resource | What drives it (per the manual) | What that means in practice |
|---|---|---|
| CPU | High player or entity counts | More players, more mobs and more active content mean more work per tick. Lag that tracks player count points here. |
| RAM | Large loaded world area; view distance is the main driver | Raising view distance loads far more world around every player. Memory use grows with the area, not just the player count. |
| Garbage collection | Memory pressure | When the Java heap is too small, the server spends CPU cleaning it up, so CPU rises even though players have not changed. |
The manual also describes the threading model: each world runs on its own main thread and off-loads parallel work into a shared thread pool. One consequence is that a single busy world cannot be spread across cores arbitrarily, while several worlds can run on separate threads. Community comparisons of hardware tend to say that fast individual cores matter more than a large core count, but that is a community opinion, not a documented rule.
View distance: the biggest lever
The manual calls view distance the main driver for RAM usage and recommends a maximum of 12 chunks (384 blocks). It also compares Hytale's default of 384 blocks (about 24 Minecraft chunks) with Minecraft's default of 10 chunks (160 blocks), and warns to expect higher RAM use with default settings, so tune the value to your expected player count.
Community guides add two details, which you should confirm on your own server. First, they name the setting MaxViewRadius and report that it lives in the server's top-level config.json; hosting guides report a default of 32 chunks, which does not match the manual's 384-block figure, so read the value in your own file. Second, they point out that the cost is not linear: a circle that is twice as wide covers roughly four times the area, so doubling the radius loads roughly four times as much world. That follows from the geometry, which is why view distance is such a large lever.
"MaxViewRadius": 12- The manual points to some community-made plugins that cover status queries, metrics and dynamic view-distance limits. They are optional, community-made and may not match your server version, so read their pages and the mods guide before adding one.
- Lower the value first, then raise it only if your players are happy and your CPU and Memory readings stay comfortable.
- Lower view distance helps both RAM and the amount of world each player makes the server simulate and send, which is why it is often the first fix for a server that feels slow once several players are exploring.
Remember that files like config.json are read at startup and rewritten by in-game actions. On a managed server, edit with the server stopped, save, and start it again. If you do not see the setting in your file, or your Startup and Configs tabs offer it as a field, use that instead and ask support if it is unclear.
JVM memory flags
Hytale's server is a Java program, so memory is governed by the JVM's heap settings. The manual's only direct guidance here is to experiment with different -Xmx values to set explicit limits, and it describes a typical symptom of memory pressure as rising CPU usage caused by garbage collection.
The manual also documents a jvm.options file for custom JVM arguments, placed next to the launcher script, with one argument per line and lines starting with # as comments. Its example contains:
# jvm.options
-Xms2G
-Xmx4G
-XX:+UseG1GC| Flag | What it does |
|---|---|
-Xms | Starting heap size |
-Xmx | Maximum heap size |
-XX:+UseG1GC | Selects the G1 garbage collector (in the manual's example) |
Community guides commonly set -Xms and -Xmx to the same value so the heap does not resize during play, and advise leaving a few gigabytes of system memory free for the operating system rather than giving Java everything. Those are common JVM practices rather than Hytale rules, and the specific heap sizes in hosting guides are their own suggestions.
The AOT cache flag
The manual's launch command includes an AOT cache flag:
java -XX:AOTCache=HytaleServer.aot -jar HytaleServer.jar --assets Assets.zipThe manual explains that the server ships with a pre-trained AOT cache, HytaleServer.aot, which improves boot times by skipping JIT warmup. That is a statement about startup. It will make restarts quicker, which is useful if you restart on a schedule, but it is not a way to raise tick rate or lower steady-state memory use. Keep the flag in the launch command and do not expect it to fix lag in the middle of a session.
Diagnose lag from the ChicagoServers panel
Open the server on panel.chicagoservers.co. These are the places to look, using the generic tools every game on the panel has:
- Top of the server page. CPU, Memory and Players show live use. CPU is measured in cores, where 1.00 means one full core busy. A CPU reading stuck near full while the player count is low is a different problem from one that climbs with each player who joins.
- Analytics. Shows players and CPU over periods from 24 hours up to 90 days, which lets you match lag complaints to busy times, new mods or a view distance change.
- Console. Shows live server output. Look for repeated errors, warnings about a specific mod, or a flood of messages that appears when lag starts.
- Troubleshoot. Lists crashes and failed starts from the last 14 days with likely causes, and shows who dropped, which separates a crashing server from a lagging one.
Community guides mention in-game commands for checking tick rate and latency (/ping and world performance commands such as /world perf are the names reported), but the official manual does not document them, so treat them as optional and confirm with /help on your build.
| Symptom | Likely cause | What to try |
|---|---|---|
| Steady slowness as players join | CPU limited by players and entities | Lower view distance, trim mods, reduce entity-heavy content |
| CPU high with few players | Memory pressure and garbage collection, or a mod | Check Memory, test with mods removed, ask support about the heap |
| Short freezes at regular times | Scheduled work such as backups or restarts | Move the schedule away from peak hours; compare timings on Analytics |
| Lag when players explore new areas | Terrain generation and chunk loading | Lower view distance; expect more load while new terrain is created |
| Everyone drops at once, ticks look fine | Network or connection problem | Check Console and Troubleshoot; see DDoS protection if traffic spikes |
| Slow only after adding a mod | Mod overhead or conflict | Remove the newest mod and retest; add mods one at a time |
Reduce load without ruining the server
Work through these in order, changing one thing at a time so you know what helped:
- Take a backup
Open Backups and run Back up now before changing configs or removing mods.
- Lower view distance
Move toward the manual's recommended maximum of 12 chunks, or lower on a busy server, restart, and compare CPU and Memory at the same player count.
- Audit mods
Remove or disable mods in groups to find the one causing trouble. See the mods guide.
- Check world settings
Each world has its own
config.jsonunderuniverse/worlds/. The manual lists fields such asIsTicking,IsSpawningNPC,IsSavingChunksandIsUnloadingChunks. A community guide advises keeping chunk unloading on so the server can free memory for inactive chunks. Changing spawning or ticking changes gameplay, so make those edits deliberately, with the server stopped. - Move scheduled work off-peak
In Schedules, put restarts and backups at the hours with the fewest players. Times on the panel are Chicago time.
- Ask about memory
If Memory is persistently high and CPU rises with garbage collection, the heap or plan may be too small for your world. Ask support what limits apply to your server.
The Early Access caveat applies here as well. Performance characteristics change between Hytale updates, so a setting that worked well last month may be worth testing again after a major update.
Running this on ChicagoServers
A ChicagoServers Hytale server runs in a Chicago facility with 40Gbps DDoS protection included, and the panel gives you live CPU and Memory, Analytics, Console and Troubleshoot to watch while you tune. If you are unsure whether a slowdown is your world, a mod or the server itself, 24/7 support can look at the readings with you. Before changing any world or config, a backup from the backups guide routine is cheap protection.
Frequently asked questions
What view distance should a Hytale server use?
The official Server Manual recommends a maximum of 12 chunks (384 blocks) and notes the default is much higher than Minecraft's. It describes view distance as the main driver for RAM use. Start at or below 12 and lower it if the server struggles with many players.
How much RAM does a Hytale server need?
The official minimum is 4 GB of memory with Java 25. Beyond that the manual gives no per-player figures. Memory use depends mainly on view distance and the amount of loaded world, so test with your own players and watch the Memory reading on the panel.
Why is my Hytale server lagging?
Common causes are too many players or entities for the CPU, a view distance that is too high, memory pressure that causes heavy garbage collection, a mod, or scheduled work such as backups. Check CPU, Memory and Players on the panel, then the Console and Analytics tabs, and change one thing at a time.
Does the AOT cache improve server performance?
The manual says the shipped HytaleServer.aot cache improves boot times by skipping JIT warmup. It is a startup feature, so it makes restarts quicker rather than raising tick rate during play.
Can I set Xmx on a ChicagoServers Hytale server?
On the panel, launch flags and server limits are staff-only, and the plan sets the memory available. If you think the heap needs changing, contact 24/7 support. The manual describes experimenting with Xmx and a jvm.options file for people running the server themselves.
Do mods slow down a Hytale server?
They can. Plugins run inside the server process and add their own work, and conflicting mods can cause errors or lag. Remove mods in groups or add them one at a time to find the cause, and check each mod's page for performance notes.