27 Jan, 2012, Zeno wrote in the 1st comment:
Votes: 0
According to some people in this thread, I/O lag is pretty normal (and expected) on a VPS. So once again, I'm running into that problem.

Someone suggested moving files to shared memory (RAMdisk). Any experience in this?
28 Jan, 2012, Davion wrote in the 2nd comment:
Votes: 0
Zeno said:
According to some people in this thread, I/O lag is pretty normal (and expected) on a VPS. So once again, I'm running into that problem.

Someone suggested moving files to shared memory (RAMdisk). Any experience in this?


Ya know, it may just be simpler to thread your I/O lookups. The reason I say this, and dismiss the RAMdisk idea, is it may end up being tossed into swap anyways and you'd encounter the same problem.
28 Jan, 2012, Kline wrote in the 3rd comment:
Votes: 0
Given the price you pay for the resources you're getting a much better value than I am. However, I will say I've never experienced I/O lag on my current host (prgmr) using only the 512mb package. I previously used a VPS on DreamHost since the price was a steal…But incredible I/O lag. Htop actually showed all cores on the CPU spiking out routinely. They did find a user seriously thrashing the box with processes and disk hits, and moved me, but overall they moved me multiple times and messed up many things along the way which is why they lost my VPS business :).

The only lag I've ever noted to happen on my current VPS at prgmr was when one of their routers was dropping packets. Took some time and effort to prove to them it was a network issue (somewhere) and not "my slice" having problems.
28 Jan, 2012, Tyche wrote in the 4th comment:
Votes: 0
Doesn't operating system file-cacheing pretty much obsolete* ram-disks?

* Except in scenarios where there is no real disk present.
28 Jan, 2012, drifton wrote in the 5th comment:
Votes: 0
I would honestly look at storing all data in ram over having a ram disk with a seperate thread responsable for writing updates to the data to disk.

pros, is you only have to block write access on the data while the data is saving
you don't have to worry about overhead of accessing the ramdisk, while probably isn't much you still have to deal with it. you are less likely to need redundant data in memory.

cons
your mud needs to have the ability to load all the data into memory
it takes more memory in general then a mud with disk caching but probably less then mud + ram disk
there is a good probablity that you'd have to rewrite a large portion of your mud file handling inorder to acomplish this and in all reality probably only really practical for an object oriented languages at least as far as it being for a rewrite
Random Picks
0.0/5