Hacker News Reader

Comment by btmorex | Hacker News Reader

I'd say VPSs are great if you're CPU bound, okay if you're memory bound, and terrible if you're disk IO bound.

Basically, CPU time is an abundant resource that's easily partitioned, but can be shared. So, you're guaranteed your share, but you often actually get more than your share.

Memory is strictly partitioned. You always get your share, no more, no less.

Disk is almost impossible to partition fairly (performance, not space). Furthermore, the more active disk users there are the worse the total performance is, so if you're unlucky enough to have a neighbor that uses a lot of disk IO than you effectively get double screwed.

What would be interesting is if someone came up with a VPS with dedicated disk resources, but as far as I know no one has done that.

View on HN

Disk is almost impossible to partition fairly (performance, not space)

I strongly suspect this is a platform-specific complaint. As in, if you are running your Linux VMs on a z-Series from IBM this is manageable. It's just a question of what your customers are willing to pay for...

For your better quality VPS providers, memory isn't really an issue because memory is dedicated. For your old time OpenVZ/Virtuozzo low-end box, that's not the case. You can oversell every resource on an OpenVZ box... Back in the day SW-Soft was claiming you could provision hundreds of VPSs on a 32 bit server. I never saw anything close to that, but I've seen some amazingly oversold servers trying to keep up with disk I/O.

One of the nice things about Xen is that disk I/O can be controlled somewhat because each domU has a specific process in dom0 for disk access. So you can ionice things & provide a somewhat more controlled access to the disk.

Memory capacity is typically dedicated (e.g., Linode), but memory bandwidth is difficult to allocate statically, and can be a huge problem even if you're fine on capacity. For example, a simulator I like to run has a 50-60MB working set, much larger than on-chip cache but well under my allocated 512MB of RAM. However, other concurrent users can disproportionately use up DRAM bandwidth, depending on their access pattern and the OS scheduler.

I've never seen a hardware node get anywhere near saturating the bus before disk I/O became an issue. So yes, there is a potential for saturation; however, I'd be really happy if that were my capacity bottleneck.

Again this is a platform specific complaint, back in the day IRIX solved this with GRIO on their Xbow active backplane. This technology will make it into Linux PCs eventually I expect.

>One of the nice things about Xen is that disk I/O can be controlled somewhat because each domU has a specific process in dom0 for disk access. So you can ionice things & provide a somewhat more controlled access to the disk.

My experience? it's easy to make one customers's I/O suck with such tools, but they work for shit when it comes to fairly balancing everyone's I/O.

As far as I can tell, the best practice is to monitor everyone's usage, and if someone goes above some pre-set threshold, to make their I/O suck using ionice or what have you.

But that's a long way from solving the problem.

Yeah, for certain. I guess I just really, really like the ability to have some control. Even if it isn't solving the problem. Back when I was working for a shop doing OpenVZ, all we could do is shrug our shoulders & make our best guess as to what was causing the problems.

Yeah, I know what you are saying. I started on FreeBSD Jails; and god damn, that was /hard/ - the heavy disk users would wipe out everyone else's cache, and so for the light users, when they logged in? the system would behave as if it did not have any pagecache. Moving to Xen, even without doing any I/O limiting, was world changing, simply because heavy users could not overwrite the pagecache used by light users.

Recently added to Microsoft's virtualisation solution is dynamic memory allocation. You give each virtual machine an amount of memory for startup and a maximum value and a priority, and now you can over-allocate resources quite nicely. It does however require the guests to have Enterprise level licenses (for no other reason than to encourage you to upgrade)

Reply on news.ycombinator.com