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

Reply via email to