One of the biggest advantages to using Xen is that malloc()'ing
processes that need to spawn children are able to do so in cache. This
gives the dom-u performance that a non virtualized server would enjoy.
By purposefully having them skid to disk, no matter how fast that disk
is, you're telling your kernel to release the "virtual" memory
immediately as it is file based and treated just like dentry. SQL, Web ,
Email, All services will need to fork upon every connection. This not
only slows down everything, it lessens the life of your hardware makes
everything considerably warmer and really opens your servers to denial
of service attacks.
You also risk DB corruption, (not to mention inode corruption [are you
using ext3? I hope not, or you're looking to start grepping for your
data using strings you hope exist in the files you lost] ). Just wait
until a dom-u is being hammered and dom-0 experiences an unorderly
shutdown, hope you've polished up on your regex to find your data :)
So, you're in essence, shooting your services in the foot no matter how
you go about it, unless you create your own swap system and teach your
kernel the difference.
Why not just have dom-0 look at slabs, loads , etc on the dom-u's and
balloon as needed, or setup a simple Xen virtualized Open SSI cluster?
Why shoot your OS in the foot intentionally when other means exist to
accomplish what you want to do? I just don't get it.. All your doing is
not only retarding Xen, but also your guest OS's and their services ..
for what purpose?
--Tim
On Fri, 2006-09-08 at 10:47 -0700, Tom Brown wrote:
> On Fri, 8 Sep 2006, Luke Crawford wrote:
>
> >
> > First off, let me say that I think virtuoso-style RAM oversubscription is a
> > bad idea.
>
> <snip> I'm not going to argue, I build all my xen boxes with lots of
> ram... but I made a similar proposal in response to a similar thread a
> while back about using tmpfs and sparse swap files in dom0:
>
> http://lists.xensource.com/archives/html/xen-users/2006-05/msg00961.html
>
> > the problems with this setup are unavoidable in a shared-ram setup. The
> > thing
> > is, UNIX is designed to eat all available ram.
>
> yes, but UNIX knows the difference between ram and swap, it will _not_ eat
> all available swap unless it has to, it _will_ make use of
> whatever "real" memory it has available.
>
> > The other problem is one of business model; if you give heavy users better
> > service than light users, and you charge the same for both, in a rational
> > market, all the light users would switch to a provider where they didn't
> > have
> > to subsidize the heavy users. you would be stuck with only the heavy users,
> > with nobody left to subsidize the system.
>
> yeah, but if there was a real business model behind this, there would be
> enough RAM. The challenge is interesting and worth thinking
> about, but should not exist in a real business world... But that isn't to
> say people won't do it. There are idiots and a*holes all over the planet
> that will take your money and give you trash or trash-service for it.
>
> -Tom
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home