Necesse Server Performance and Lag Fixes
Necesse performance depends on the actual world, settlement activity, players, Java runtime, storage, and network. There is no defensible universal “50 settlers equals X RAM” table. Measure the server during the workload that is actually lagging, then change one variable.
Find the bottleneck first
| Symptom | Evidence to collect |
|---|---|
| Every player sees delayed actions | Server CPU, memory, Java process, disk latency, and UDP packet loss. |
| Only one player stutters | That client's FPS, connection, and local hardware. |
| Lag appears around a settlement | Reproduce with settlers, production, storage, and raids active; record process load. |
| World saves or loads slowly | Storage latency, free space, backup/archive jobs, and save size. |
RAM and Java
Necesse runs on Java. If you manage the process yourself, the JVM's -Xmx option can cap heap size, but the correct value depends on the current world and server package. Do not promise that -Xmx4G or -Xmx6G is an official requirement. Leave memory for the operating system, file cache, backups, and other services.
# Example only: choose a cap after measuring the real workload
java -Xms1G -Xmx4G -jar Server.jar -nogui -world MyWorld -port 14159On managed hosting, the panel or container may control the JVM memory. Compare the plan's usable memory and CPU, not only the advertised slot count; see the cost guide.
Supported server controls
-pausewhenempty 1can pause an empty server; use0when continuous simulation is required.-logging 1/0controls logging according to the current server package.-zipsaves 1/0controls the documented save packaging option.-slotssets the configured player capacity; it is not a CPU or RAM control.
Do not add unloadSettlements, maxSettlersPerSettlement, raidFrequency, or WorldThreads to a generic config file unless the current official package explicitly documents that option. Use the launch-flag reference.
Settlement and world practices
- Keep paths, storage, and production layouts understandable so you can reproduce a problem.
- Reduce simultaneous heavy activity on a test copy to identify whether the settlement or network is the trigger.
- Keep adequate free disk space and avoid running large backups during the busiest session.
- Schedule maintenance from evidence, not a claim that Java must be restarted every 24 or 48 hours.
Update and backup discipline
- Back up the active save path before an update or configuration change.
- Update server and clients to compatible builds.
- Reproduce the issue on the updated build with one change at a time.
- Keep logs and the pre-change backup if the issue persists.
See server setup, backup and restore, and the v1.3.2 update checklist.
Want managed resources, updates, and backups? Host Necesse with Supercraft.