How to Reduce Lag on an Eco Server
Eco servers slow down as worlds fill with objects, water and industry, and most of that work runs on one CPU core. Here is how to find where your lag comes from, which settings and habits fix it, and when an upgrade is the real answer.
If one player is stuttering and everyone else is fine, look at their PC or connection first. If everyone rubber-bands together, it is usually server-side.
Old worlds accumulate storage, loose items, claims, flowing water, factories, laws, chat history and modded content. That adds simulation work and more data to keep in memory and on disk.
Use the built-in performance report and profiler so you know if the bottleneck is simulation, memory build-up, or save and backup spikes. Guesswork usually wastes time.
World size and build height cannot be trimmed back on an existing save. If those choices are too ambitious, the real fix is planning the next season better.
Tell server lag from client lag and network lag first
Before changing configs, work out where the slowdown actually lives. Eco can feel similar from the player side even when the cause is completely different. The fastest rule is this: if everyone reports the same hitch at the same moment, suspect the server. If one player has trouble alone, suspect their machine or route to the server.
| Symptom | Likely cause | First check |
|---|---|---|
| One player gets stutter, slow UI or poor loading, but others do not | Client lag | Check that their PC is up to spec, ask them to close the mini-map, and remember that hosting on the same PC you play on means meeting both the client and server requirements. |
| One player has delay or rubber-banding mainly because they are far away geographically | Network lag | Check server location first. Distance adds latency even if the server itself is healthy. |
| Everyone rubber-bands or actions feel delayed at the same time | Server lag | Run a performance report and note whether it happens during busy factory hours, save times, backup times or after long uptime. |
| Short hitches happen at regular intervals | Usually disk or save-related server lag | Compare the timing with saves and backups. If they line up, look at storage performance and SSD use before touching simulation settings. |
| Server feels worst right after a restart when many players join together | Load-in surge on server CPU and disk | Check simultaneous loading pressure and review MaxUsersLoadingAtSameTime. |
For local hosting, there is one extra trap: a machine can be good enough to run the game client or the server on its own, but not both together. The official client minimum is 8 GB RAM and recommended is 16 GB RAM; the default 72×72 server requirement is 4 GB RAM on top of needing a capable CPU. If the same box does both jobs, both sets of demands matter.
Why Eco servers lag as the world ages
Eco is not just tracking player positions and a few building pieces. The server is simulating an ecosystem: plants and animals, pollution, water behaviour, world objects such as crafting tables and storage, plus laws, economy and other persistent state stored in a database. A lot of that work is effectively bottlenecked by one CPU core. The official guidance is plain: the process only uses a single CPU core for the critical work, so higher CPU frequency matters more than having lots of extra cores.
| Cause | Main CPU core | RAM | Disk |
|---|---|---|---|
| Loose items, stockpiles, crafting stations | Yes | Partly | Partly |
| Flowing water and small water blocks | Yes | – | – |
| Elevator and transport exploits | Yes | – | – |
| Old chat history | – | Yes | – |
| Tooltip cache (MaxTooltipCacheSize) | – | Yes | – |
| Saves, backups and the law database | – | – | Yes |
| Verbose inventory logging | Yes | – | Yes |
Main-thread CPU: the usual limit
- World objects: every machine, stockpile, storage container and crafting station adds ticking and state checks. More objects means more work per tick on the main simulation thread.
- Plants, animals and pollution: these systems need regular updates. The more settled and developed the world becomes, the more there is to evaluate.
- Flowing water: large areas of active flow, or lots of tiny water blocks players created, force repeated updates. That is why unnatural water messes can hurt far more than a normal river.
- Inventory-moving exploits: fast stockpile transport or “elevator” setups trigger constant inventory transfers. That creates a lot of repetitive server work and can produce crushing lag around industrial districts.
- Excavators and large automated work areas: they can create bursts of object changes and inventory movement that hit the simulation hard.
RAM: what builds up in memory
- More players, chat history, caches and persistent world state all live in memory while the server runs.
- Tooltip cache: a larger cache keeps responses snappy, but it uses RAM. A smaller one saves memory at the cost of slower tooltip responses.
- Long uptimes: if the server feels better after a restart and worse again later, memory build-up is part of the story even if it is not the only issue.
Disk and database: where saves and economy data matter
- Saves and backups: Eco writes the world to disk regularly. If storage is slow, players feel it as hitches.
- Heavy database access: the law and economy systems are one reason SSD storage is strongly preferred.
- Verbose logging: extra logging writes more to disk and burns CPU handling it.
World size and build height multiply everything
A bigger map gives you more space, but also more potential simulation area, more places for players to spread out, and more total objects to persist over a season. Build height does the same vertically. Once the world is created, those choices are mostly locked in, so they are planning decisions as much as performance decisions.
Measure before changing anything
If you tweak settings before measuring, you can easily fix the wrong thing. Eco gives you enough built-in tools to separate CPU pressure, memory pressure and save-related disk stalls.
/performance /profiler cpu /profiler memory /profiler results /manage save /manage maintenance 06:00, Restart for updates, Restart
/performance: runs a server performance report and dumps it to files. Use it while players are online and the problem is actually happening, not during a quiet period./profiler cpu: captures a CPU profile. This needs dotTrace installed. Use it when everyone is rubber-banding, actions are delayed, or industrial areas feel far worse than wilderness./profiler memoryor/profiler dump: captures a memory dump. This needs dotnet-dump. The dump file is about as large as the RAM currently in use, so make sure there is enough free disk space first./profiler results: use this to retrieve the finished profiler output.
What to look for in plain English
- If the server only hitches around saves or backups, the issue is probably storage speed or storage contention, not a simulation setting.
- If performance degrades steadily over uptime but clears after a restart, memory build-up or long-lived state is involved.
- If lag is worst in built-up settlements, factories and storage yards, world object load is usually the main-thread problem.
- If lag started right after adding or updating a mod, test the mod stack before changing world settings.
One practical trick is to run /manage save when the server is otherwise calm. If players feel the same hitch pattern during that manual save as they do during normal lag spikes, you have a storage clue straight away.
World size and build height: the choice you cannot fix mid-season
World dimensions are set in WorldGenerator.eco, and they only apply to a new world. That means world size is a wipe decision, not a live tuning knob. If the current map is too ambitious, no config tweak will truly make it small again.
| World size | Area | Official note | Performance meaning |
|---|---|---|---|
| 72×72 | 0.52 km² | Small, default, recommended for single player and co-op | The safest baseline for stable simulation and modest hardware. |
| 100×100 | 1 km² | Medium, often used for small public servers | A common public-server compromise if your community actually needs more room. |
| 160×160 | 2.56 km² | Large, largest from Host a World | Reasonable only if the hardware is ready and the extra space will really be used. |
| 172×172 and 200×200 | 2.96 and 4 km² | Work on above-average servers but are not recommended; no meaningful impact on ecology | Often a poor trade: more world to carry, little practical gain. |
| 224×224 up to 400×400 | 5 to 16 km² | Can work on strong servers and clients but will likely not perform well | Only for very specific cases, with clear expectations about performance cost. |
| Over 400×400 | Over 16 km² | Extremely likely to be unstable | Not a sensible target for a normal community server. |
WorldWidth and WorldHeight must be equal and divisible by 4. If you are planning the next world and want a moderate step up from default, a 100×100 map is the usual point where you gain room without committing to a very large sim.
"WorldWidth": 100, "WorldHeight": 100
Build height matters too. MaxBuildHeight defaults to 160. Values above 160 heavily increase hardware usage on the server, the hard limit is 320, and it cannot be lowered after world creation. That means “just in case” vertical headroom is expensive if the community never uses it well.
Planning rule for the next season
- If the current world already slows down badly as towns mature, do not solve it by choosing an even larger map next time.
- If players mostly cluster together anyway, default or medium usually performs better than a sprawling world.
- If your current build height is above the default and the server struggles, bring it back to default on the next wipe unless there is a strong reason not to.
World hygiene fixes your players can help with
Some of the best fixes are social, not technical. Eco servers stay healthier when players understand which habits create lots of extra simulation or inventory churn.
- Clean up loose items: items on the ground are extra world entities the server has to track. Less clutter means less object overhead, less memory use and usually smoother busy areas.
- Stop stockpiles overflowing: do not queue crafting that has nowhere to put the output. Overflow causes pointless item handling and more inventory work for the server.
- Reduce artificial flowing water: small water blocks and large player-made flow systems create repeated updates. Removing them cuts main-thread simulation work, though players lose decorative or mechanical water builds.
- Use excavators with restraint: they can generate heavy bursts of changes. If lag appears during big extraction sessions, stagger the work instead of running everything at once.
- Dismantle stockpile “elevator” or transport exploits: ultra-fast inventory-moving setups look clever but often create exactly the kind of repeated transfer spam that tanks server performance.
- Keep claims sensible: claims are persistent world state. Very fragmented or excessive claim usage adds overhead and can encourage sprawling builds that produce even more objects.
How to communicate this without annoying the community
Frame it as server health, not as random restrictions. Tell players what the server is paying for: more main-thread CPU around object-dense builds, more memory for persistent state, and more disk work when saving all of it. A short rules post about loose-item cleanup, water abuse, overflow crafting and transport exploits is usually enough if you explain the reason.
You will know these changes helped when the worst industrial areas stop being dramatically worse than normal terrain, tooltips respond more quickly near storage clusters, and everyone reports fewer shared hitch moments.
Safe config edits and the settings most likely to matter
Eco config files live in Configs as .eco files, and each has a .template version. The .template files are overwritten on update, so copy the one you want and remove .template to make your own file. Also note that the server writes settings back to the .eco files when it shuts down, so if you edit a file while the server is running, your changes will be overwritten. Stop the server first, or change the setting in /serverui and click File -> Save.
Settings worth checking
WorldObjects.eco→ParallelWorldObjectTicks: default is false. This is experimental and can significantly increase performance, but it may cause crashes and inconsistency. Use it only if your evidence points to world object ticking on the main thread, and only after you are happy with backups.
"ParallelWorldObjectTicks": true
EcoSim.eco→AnimalBehaviorLodding: keep this true. It reduces animal tick frequency when no player is observing them, saving CPU with little downside.Performance.eco→MonitorStability: keep this false unless you are actively diagnosing stability. It has a high performance impact because all clients send an RPC every 10 seconds.Performance.eco→VerboseLogsOfInventoryChangeSets: keep this false. It creates high CPU and disk overhead by logging a lot of inventory activity.Performance.eco→MaxTooltipCacheSize: default is 1000. Lowering it can reduce RAM use, but tooltip responses become slower because the server must rebuild more tooltip data instead of serving it from cache.Network.eco→Rate: default is 20, range 1-60. This controls how often the server sends updates to clients. Raising it can feel more responsive but costs more bandwidth and some CPU; lowering it saves bandwidth but movement and updates can feel less immediate.Network.eco→MaxUsersLoadingAtSameTime: default is 20. If restart rushes cause trouble, lowering this can spread the load at the cost of slower entry for queued players.Storage.eco→SaveFrequency: default is 60 seconds. If hitches line up with that cadence, the issue is likely disk-related.Backup.eco→BackupFrequencyInHours: default is 0.5. Again, if players feel spikes on that rhythm, check SSD performance and storage contention before changing anything else.
Use /chat clearhistoryolderthan <days> if chat history has grown old and heavy. It reduces memory usage and may improve server performance, with the obvious trade-off that very old chat is no longer available.
Scheduled restarts: useful maintenance, not a magic fix
Restarts are normal for Eco. Hosts commonly advise restarting at least daily, and many communities restart 4 times a day or more. That helps clear memory build-up and resets long-lived server state, which is why an aging world often feels crisp again immediately after a restart.
What restarts do not fix: an oversized world, poor storage performance, abusive water builds, a bad mod, or a district full of object-heavy exploits. If lag returns quickly after every restart, the server still has a structural problem to solve.
Daily automatic restart scheduling lives in Maintenance.eco. AutoShutdownHour defaults to -1, which means disabled. The example below sets the restart to 05:00 server time.
"AutoShutdownHour": 5
The default countdown warnings are 60, 45, 30, 15, 5, 3 and 1 minutes. You can also schedule a manual maintenance restart from chat when you need to patch, remove a bad mod or clear a degraded session.
Mods: a common cause after updates and a hidden cause over time
Mods in Mods/UserCode are compiled at server start. One compile error is enough to stop the server starting at all, so after updates, treat the mod stack as suspect until proven healthy.
- Mods that add lots of animals or placeable objects increase the exact things Eco is already sensitive to: more ticking, more persistent state, more save data.
- Mods made for older versions can misbehave after a game update even if the server still starts.
.override.csfiles replace core files and must be recreated after each update, so they deserve special attention when trouble appears after patch day.
If performance worsened right after a mod change, test one step at a time: remove the newest suspect, restart, compare behaviour, then continue. Do not change five config settings and three mods at once or you will never know which change actually mattered.
Tune it, or upgrade it?
Use this table once you have some evidence. The right spend for Eco is usually not “more of everything”; it is targeted at the specific resource the server is actually saturating.
| If you see this | Tune first | Upgrade focus | Why |
|---|---|---|---|
| Everyone lags in dense towns, factories and storage yards | World cleanup, remove inventory-moving exploits, review mods, consider ParallelWorldObjectTicks carefully | Higher single-core CPU clock | Eco’s critical simulation work is mostly limited by one busy core. |
| Hitches line up with saves, backups or mass login moments | Check SaveFrequency, backup cadence and MaxUsersLoadingAtSameTime | SSD storage | Writes, reads and database access are the pain point, not pure simulation. |
| Server gets worse over long uptime and improves after restart | Schedule regular restarts, clear old chat history, review cache-heavy choices and mods | More RAM if the world size justifies it | Memory build-up is part of the slowdown. |
| Only far-away players complain | Check location and route first | Closer server location | Lower latency helps responsiveness even when the server itself is healthy. |
| Hosting and playing on the same machine feels rough | Reduce local load and separate client and server if possible | Stronger CPU and enough RAM for both client and server needs | The same PC must satisfy both sets of requirements at once. |
For Eco, the shopping list is simple: high single-core clock, SSD storage, enough RAM for your chosen world size, and a location close to your players. If you are comparing rented plans, our Eco server hosting comparison focuses on those practical points.
If your reports point to a genuine hardware limit, prioritise CPU speed first, then SSD storage and RAM sized sensibly for the world you actually plan to run.
Compare the best Eco server hostsEco server FAQ
Why is my Eco server lagging?
Usually because the server is simulating too much on its main thread, or because saves, backups or database work are stalling on storage. Old worlds accumulate world objects, loose items, claims, water problems and modded content, so the load rises over time. First confirm it is server-side by checking whether everyone feels it together.
Does a bigger world make Eco lag?
Yes, it can. Bigger worlds and taller build limits give players more space to spread objects and industry, which means more state to simulate and save. The important part is that world size changes only apply to a new world, so a bad size choice is really fixed at wipe time.
How much RAM does an Eco server need?
For the default 72×72 world, the official server requirement is 4 GB RAM and 1 GB disk, with an SSD recommended. Requirements vary with world size, and if you host and play on the same PC you also need to satisfy the client requirement, which is 8 GB RAM minimum and 16 GB RAM recommended.
How often should I restart an Eco server?
At least daily is common advice, and many servers restart 4 times a day or more. Restarts help clear memory build-up and keep long sessions from getting progressively worse. They are maintenance, though, not a substitute for cleaning up a bloated world or fixing a bad mod.
Is ParallelWorldObjectTicks safe to turn on?
Safe is the wrong word. It is explicitly experimental: it can significantly improve performance, but it may also cause crashes and inconsistency. Use it only after backups are in order and only when your measurements suggest world object ticking is the real bottleneck.
More server lag guides
Our Eco host comparison, plus lag guides for other survival and building games.
Config names, defaults and commands are from the official Eco server documentation. Cleanup and restart advice comes from Eco hosts’ own knowledge bases.
