3 ms·

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

by tres 16y ago

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.

sparky 16y ago
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.
- tres 16y ago
  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.
- gaius 16y ago
  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.
lsc 16y ago
>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.
- tres 16y ago
  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.
  - lsc 16y ago
    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.

by tres 16y ago

sparky 16y ago

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.

tres 16y ago
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.
gaius 16y ago
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.

lsc 16y ago

>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.

tres 16y ago
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.
- lsc 16y ago
  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.