AsyncSave 0.1.1 - Write Chunk Data Asynchronously [953]

AsyncSave - Write Chunk Data Asynchronously:
Version: v0.1

This Bukkit mod overrides the chunk saving method and changes it to write to disk asynchronously, using threads. This greatly speeds up disk writes, especially on multicore systems and RAID storage, and goes a long way to reducing lag.

Since this is a mod rather than a plugin, it will probably not work with any RB other than 953. I will do my best to update as quickly as I can when new RBs come out.

Warning:
Asynchronous writes means the data does not immediately make its way to disk. There is still the chance a bug, crash, or power loss could damage your world. I strongly suggest only using this mod if you back up your world regularly. Incremental backups would be good too, since there's a chance world damage could go unnoticed until your server restarts.

Installation:
Download AsyncSave.jar to your main Bukkit directory (NOT plugins). Modify your start.cmd/start.sh/whatever you use to launch Bukkit to something like the following:

Code:

java -Xincgc -Xms512M -Xmx1024M -cp AsyncSave.jar:craftbukkit-0.0.1-SNAPSHOT.jar org.bukkit.craftbukkit.Main nogui

(Use ; instead of : for Windows servers.)

Download:
Download disabled, could sometimes lead to chunks being saved in the wrong place.
Will be back when (if?) I can figure out a fix.

Source:
I'm not going to redistribute the modified Minecraft code.
However, 99% of the code is in my own class, which can be downloaded here:
AsyncRandomAccessFile.java
You're welcome to use it in your own projects.

Changelog:
Version 0.1.1

• Changed seek() to run immediately if queue is empty. Saves waiting on queue flushes when only reading.
• Slightly faster thread synchronization.

Version 0.1

• First working version.

TODO:

• It's not as asynchronous as I'd like, it flushes out the queue before any read from the same file. I'd like to switch this to tracking what's "dirty" and only flushing if it's needed, or better, fulfilling the read from the write queue.
• Going async at a higher level would help speed things up. In particular, offloading the compression to a thread would be a nice touch. On the other hand, it would also mean messing up more Notch code.

 

You have to post this in the tools section As it's not really a plugin. But nice one! Will probably be using this

 

I'll be keeping an eye on this

 

hmmmm so it needs to be in the start .bat, what if you run McMyAdmin?

 

moved, the title does not have to have version and type tags

 

My mistake.

I don't know, I don't use McMyAdmin. At some point I'll have to grab it to see, I guess, unless someone else knows how to change the start command?

Thanks. Took out the type tag, going to leave in the version since it will almost certainly only work for the one version.

Have some ideas to fix my thread problem, now to see if they work...

Edit:
Well, as most things, getting a good night's sleep makes them much easier.
First actually working version posted.

 

Tried to use however did not work, not even with the suggested start-up line. (Using 953)

 

Did it give any errors or anything? Or just do nothing?

 

Caused a never ending spew of errors which I had to force a kill on java. I'm not sure if it logged.

 

Any chance you could paste one here? It works fine for me, so would really help in fixing the problem if I had at least a vague clue what was going wrong.

Edit:
Ok, I think I may have seen what you're seeing, looks like something may be wrong with the new seeking in 0.1.1... going to take down that version as it's possible that bug might overwrite chunks.

Edit 2:
Ohh, I think I see... it's not strictly that, it's that Minecraft is opening the region files more than once and the asyncness is interfering with each other... hmm. This could be more of a problem than I thought.

 

Sounds like a wonderful idea but not willing to risk it as it seams like this plugins is heavily buggy still.

 

At the moment it's too buggy for me to even have it up for download. And, I'm having a horrible time figuring out why. Even with rewriting it to use a single write queue for multiple copies of the same file, and have the queue hold atomic seek-write operations, it keeps ending up with chunks being saved in the wrong spot. So, yeah... don't hold your breath on this one.

 

/me holds his breath and his head turns blue.

Anyway seriously, this seems brilliant for bigger servers.
I'd love it if you were capable of making it stable.