On 05/18/09 09:59, Jerry Jelinek wrote:
Devin Ceartas wrote:
The problems this may cause me are largely theoretical at this point,
as I'm just beginning to ramp my OpenSolaris use up.
My concern is conserving RAM, which full vs. sparse zones may or may
not effect, I don't know, and with ease of management. My use case is
running multiple instances of the same underlying web application for
multiple clients. Keeping the core portions of the web app in common
should help in maintaining it. Using sparse zones seemed like an
easier solution than re-architecting the app to refactor the common
parts into a webservices component.
The webapp components are relatively small, so I'm not overly worried
about storage space.
Overall the idea of stable, secure containment which is lighter weight
than full virtualization is attracting me to OpenSolaris, so I imagine
it will be a win in efficiency regardless f the sparse/full question.
Thanks for the write-up. It is helpful for us to
know what peoples concerns are for the sparse vs. whole
root configurations. As you point out, even with
whole root zones, you do realize all of the other
efficiencies of the zones model. I don't think we've
collected any data on the memory sharing differences
of sparse vs. whole root. It would depend on how many
common pages there were across the zones. I think our
guess is that the memory sharing benefits of sparse zones
are relatively small in most cases.
That is my guess as well, even though I measured it briefly about four
years ago (there difference in memory usage between sparse and whole
root was less than I had expected!) The text can be shared, and for most
applications the text is relatively small, compared to the data, stack,
heap, or whatever has to be a private copy per process, let alone per
zone. On a 1GB system that may be sufficient to make a service run
poorly or not at all, while on larger systems it is probably noise. Web
servers, Java, databases (dare I say almost all applications?) are going
to generally consume mostly private space.
My own concern is management, the ease of that, and simplicity. I can
get around only have ipkg zones (native, whole root equivalent) by
managing where I install applications I would like to easily and quickly
have in all the zones. However, that is only if I can control where an
application installs, or figure out how to get it where I want it. It
also requires me to have a zone configuration with separate file system
mount(s), so for a simple system a more complex installation. Not
unmanageable or impossible, just requiring more work. The last step is
probably normal for larger installations, especially those able to run
multiple versions of an application in different zones on the same system.
I have been doing all on Solaris next testing using Nevada, as all the
tools I know work, and my understanding of installation and
configuration applies to that as well as Solaris 10. Now I am playing
with 2009.06 and some 'simple' things don't work as expected. I couldn't
copy a sysidcfg file into <zonepath>/root/etc/ as that is no longer
mounted after an install. The 'correct' operation is to detach a newly
created zone, copy the file in, and attach. I was surprised how long the
attach took! Scripts will definitely have to change.
As an experienced zone user I have a lot of things to re-learn, from
Automated Install all the way through basic zone configuration.
zones-discuss mailing list
zones-discuss mailing list