Direct answer
A restart temporarily clearing lag does not prove the JVM needs a daily restart. It can reset accumulating entities, plugin caches, scheduled queues or memory, masking the underlying source.
How to check it
- Record uptime and exactly when tick lag first becomes noticeable after reboot.
- At healthy uptime and again during slow uptime, collect comparable spark profiles and memory/GC reports.
- Check whether chunk loaders, farms, entities or scheduled plugin tasks accumulate over time.
- Correlate worsening performance with backup jobs, database maintenance and player peak hours.
What to change
- Fix the accumulating workload where the profile points, such as an entity leak or duplicate repeating task.
- Review plugin updates and known issues before changing JVM flags.
- Keep a graceful maintenance restart plan only as a temporary mitigation, including backups and clear player notice.
Software and version notes
Restarting can reclaim memory and clear tasks but may hide bugs; an unclean forced reboot can also damage stored data. Heap usage and actual post-GC live memory are not the same metric.
Practical example: Example: MSPT rises after several hours because a plugin adds repeated tasks that are never cleaned up. A restart makes the graph look healthy but the same growth returns. Two spark profiles—shortly after restart and shortly before the next slowdown—can reveal whether plugin tasks or entities are accumulating.
Verify the result
- Compare late-uptime profiles before and after the targeted fix.
- Aim for stable MSPT over longer uptime, not merely a fast first hour.