I’ve had this behavior going back a year now - I get excessive and literally doubled save activity during the hourly rdiff-backups. Let me paste a log snippet from the server.log:
2014-12-05 12:00:53 [INFO] CONSOLE: Disabled level saving…
2014-12-05 12:00:53 [INFO] CONSOLE: Forcing save…
2014-12-05 12:00:53 [INFO] CONSOLE: Save complete.
2014-12-05 12:01:03 [INFO] CONSOLE: Disabled level saving…
2014-12-05 12:01:03 [INFO] CONSOLE: Forcing save…
2014-12-05 12:01:03 [INFO] CONSOLE: Save complete.
2014-12-05 12:01:10 [INFO] CONSOLE: Enabled level saving…
That happens every time the rdiff-backup process is initiated.
What I’ve checked:
- If I use the MineOS GUI to disable backups, I get zero rdiff-backups run, and zero of the above activity.
- The “autosave ticks” in Bukkit.yml is set to zero (disabled)
- There are no hourly cron jobs running
- There are no plugins or other 3rd-party code elements running a save procedure
MineOS: 0.6.0
CraftBukkit: 1.7.9-R0.2
Linux: Debian 7
I might let this go, except that the back-to-back saveoff/save-all/saveon cycles are starting to cause lag when they hit, and it is becoming an issue. Yes, I could just setup a cron job to manually rdiff-backup, then disable backups in MineOS. I’m looking for a more elegant solution, if there is one.
EDIT: I should point out, I’ve changed the backup interval to 30 minutes, and now 2 hours. The behavior is the same.
Can you post your /var/log/mineos.log? It actually will explain in greater detail the actions being taken behind the scenes.
Keep in mind, simply because Minecraft is committing save data to the HDD doesn’t mean that you’re experiencing double backups (and your restore point listings can confirm this).
Is it possible you have backups and archives set? And then you turned them both off for testing? Because if you have daily backups and archives, you are expected to have those redundant lines (a force save for each action). The fact that the logs are 10 seconds away from eachother supports this idea (because there is a forced 10 second commit delay to make sure all caches are flushed etc.)
That said, the most likely cause then for your lag is the actual creation of the archive, because making archives requires all of your world’s data to be read, compressed, and saved into a file: this is simply a side-effect of performing these actions while other processes may need CPU time and HDD bandwidth.
Hi hexparrot,
Thank you for your reply. When I turn off backups, all save activity stops - unless it’s time for the singular daily backup. I recently changed backups to run every two hours, mostly because there’s not enough server activity to justify once per hour.
My mineos.log file: http://pastebin.com/zdnGhDHV
My concern is the performance hit during backups. I understand the hit to performance during archives, these run at midnight and players aren’t usually online, so no problem.
Well, as the log shows, there is only one backup that is occurring:
[05/Dec/2014:10:00:44] [glacier] backup return code reports success; sleeping 3sec
[05/Dec/2014:12:00:53] [glacier] commit
[05/Dec/2014:12:00:53] [glacier] commit command received by process; sleeping 10sec
[05/Dec/2014:12:01:03] [glacier] backup (Server Up: True)
[05/Dec/2014:12:01:10] [glacier] backup return code reports success; sleeping 3sec
[05/Dec/2014:14:00:20] [glacier] commit
Two commits occur, but that won’t cause any noticeable difference in performance hits.
Here’s how it plays out:
At 12:00:53, a commit occurs.
Let’s say, for example, there’s 50mb of substantive world changes that need to be committed by the server. There will be unavoidable performance impact here (although unavoidable doesn’t mean crippling).
Ten seconds later, a second commit occurs. At this point, there’s likely 0kb of world change, and thus there should be zero performance impact of this commit.
A quarter of a second later, the actual backup occurs, which will then incur another performance hit, which again, is variable in impact.
But TL;DR, despite two commits, you’ll only suffer as much impact as is required by world changes. In fact, 50 commits would have no appreciable difference from 2, aside from just being log-spammy.
If you’re finding that there really is a noticeable performance hit during backups, you might consider plugins that commit live-world data to disk at frequencies more often (but even this I don’t think is very necessary).
Ok, I understand now. Thank you very much for your replies, and especially for MineOS.
You’re very welcome. Please don’t hesitate to start up any new threads if anything like this raises questions in the future!