Solaris Containers & 32-bit Java Heap allocation
By user12620111 on Apr 27, 2009
A note from Steve Dertien at PTC:
We’ve solved the memory issue with zones. The issue is impacted by the kernel version on the server and the zone type that they have created.
What we’ve discovered is that older kernel versions do not adequately support the larger heap sizes in a whole zone configuration. The kernel version can be output using uname –a as follows.
SunOS mlxsv016 5.10 Generic_137111-04 sun4v sparc SUNW,T5240
With that particular version you can allocate a JVM with a 2Gb heap in the global zone and in a sparse zone. In a whole zone you will not be able to allocate the full 2Gb to the JVM. The output of a JVM failure will look like the following in this case:
./java -Xmx2048m -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
This issue is resolved when you upgrade the kernel to a newer version. The Sun servers at PTC are using a newer version of the kernel and therefore we’re not experiencing this issue. For Windchill support on Solaris zones (whole or sparse) we should indicate that the customer must be on this kernel version or newer (assuming this does not regress).
SunOS edc-sunt5120 5.10 Generic_137137-09 sun4v sparc SUNW,SPARC-Enterprise-T5120
I don’t know if there are newer kernel versions but we should probably put a customer document together that states when running Windchill in a Solaris zone of any kind that the kernel must be patched to this level or higher and how to test for this condition. [Jeff adds: See http://blogs.sun.com/patch/entry/solaris_10_kernel_patchid_progression] Also, this issue does not exist with the 64bit JVM when the –d64 option is supplied to the command.
This is the definition of a whole zone versus a sparse zone (lifted from here: http://opensolaris.org/os/community/zones/faq/)
Q: What is a global zone? Sparse-root zone?
zone? Local zone?
A: After installing Solaris 10 on a system, but before creating any zones, all processes run in the global zone. After you create a zone, it has processes that are associated with that zone and no other zone. Any process created by a process in a non-global zone is also associated with that non-global zone.
Any zone which is not the global zone is called a non-global zone. Some people call non-global zones simply "zones." Others call them "local zones" but this is discouraged.
default zone filesystem model is called "sparse-root." This model
emphasizes efficiency at the cost of some configuration flexibility.
Sparse-root zones optimize physical memory and disk space usage by
directories, like /usr and /lib. Sparse-root zones have their own
areas for directories like /etc and /var. Whole-root zones increase
configuration flexibility but increase resource usage. They do not use
filesystems for /usr, /lib, and a few others.
There is no supported way to convert an existing sparse-root zone to a whole-root zone. Creating a new zone is required.
Wikipedia also indicates that the penalty for a Whole-zone is mitigated if the file system that the zone is installed on is a ZFS clone of the global image. This means that the system will only require additional file system space for data that uses different blocks. Essentially two copies of the same thing occupy only one block of space instead of the traditional two. For those that are concerned about the consumed disk space for whole zones, that can be mitigated using the ZFS file system.
Instructions for creating a sparse zone are outlined rather well here: http://www.logiqwest.com/dataCenter/Demos/RunBooks/Zones/createBasicZone.html
Instructions for creating a whole zone are outlined rather well here: http://www.logiqwest.com/dataCenter/Demos/RunBooks/Zones/createSelfContainedZone.html
The major difference is in the second step. A sparse zone uses the “create” command while a whole zone uses “create -b”. Jeff Taylor also sent a link to a nice tool called Zonestat (http://opensolaris.org/os/project/zonestat/). The output of the tool does a great job at showing you the distribution of resources across the zones. The command below assumes that you placed the zonestat.pl script into /usr/bin as it does not exist by default.
# perl /usr/bin/zonestat.pl
Zonename| IT|Size|Used| RAM| Shm| Lkd| VM|
global 0D 64 0.0 318M 0.0 0.0 225M
edc-sne 0D 64 0.0 273M 0.0 0.0 204M
edc-sne2 0D 64 0.0 258M 0.0 0.0 190M
==TOTAL= === 64 0.0 1.1G 0.0 0.0 620M
One last detail. To get the configuration of a zone we should ask customers for the output of their zone configuration by using the zonecfg utility from the root zone. The commands that will work the best is either “zonecfg -z <zone_name> info” or “zonecfg -z <zone_name> export”. We need to carefully evaluate any capped-memory settings or other settings defined in the zone to determine if those are also causing any potential issues for Windchill. The output of that command will indicate whether the zone is a sparse or whole zone as the inherit section is likely not there in a whole zone.
# zonecfg -z edc-sne info
# zonecfg -z edc-sne2 info
The export command will allow use to create the zones internally for our own testing purposes and they should contain the create command that was leveraged, but it’s misleading. If you use the standard “create” command it will automatically create the required inherited properties. But the export command will use “create –b” and you will see several of the following instead:
currently do not have an opinion as to whether we want to
advocate a Whole vs. Sparse zone. It seems a Whole zone creates more
independence from the global zone. This may be necessary if you want
have more absolute control over the configuration.