Monday Apr 27, 2009

Solaris Containers & 32-bit Java Heap allocation

A note from Steve Dertien at PTC:

Jeff,

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.

# uname -a
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).

# uname -a
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? Whole-root 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.

The 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 sharing some directories, like /usr and /lib. Sparse-root zones have their own private file areas for directories like /etc and /var. Whole-root zones increase configuration flexibility but increase resource usage. They do not use shared 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
       |--Pool--|Pset|-------Memory-----|

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.

SPARSE/SHARED ZONE

# zonecfg -z edc-sne info

zonename: edc-sne

zonepath: /home/edc-sne

brand: native

autoboot: true

bootargs:

pool:

limitpriv:

scheduling-class:

ip-type: shared

inherit-pkg-dir:

        dir: /lib

inherit-pkg-dir:

        dir: /platform

inherit-pkg-dir:

        dir: /sbin

inherit-pkg-dir:

        dir: /usr

net:

        address: 132.253.33.85

        physical: e1000g0

        defrouter: 132.253.33.1

WHOLE ZONE

# zonecfg -z edc-sne2 info

zonename: edc-sne2

zonepath: /home/edc-sne2

brand: native

autoboot: true

bootargs:

pool:

limitpriv:

scheduling-class:

ip-type: shared

net:

        address: 132.253.33.86

        physical: e1000g0

        defrouter: 132.253.33.1

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:

add inherit-pkg-dir

set dir=/sbin

end

I 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 to have more absolute control over the configuration.

Best Regards,
Steve

Tuesday Feb 26, 2008

Jumpstart: ERROR: could not load the media (/cdrom)

During a "Solaris 10 8/07 s10s_u4wos_12b SPARC" jumpstart install, the jumpstart client complained:

cat: cannot open /cdrom/.cdtoc
cat: cannot open /cdrom/.cdtoc
expr: syntax error
expr: syntax error
cat: cannot open /cdrom/.cdtoc
expr: syntax error
ERROR: could not load the media (/cdrom)

It turned out that my /etc/dfs/dfstab entry was not pointing the the correct level of the hierarcy.

The correct entry is:

share -F nfs -o ro,anon=0 /export/home/sol_10_807_sparc

The incorrect entry is:

share -F nfs -o ro,anon=0 /export/home/sol_10_807_sparc/Solaris_10

Root of the problem was that "/export/home/sol_10_807_sparc/.cdtoc" was not visible via NFS.

# cat /etc/bootparams
scnode2.mydomain.com  root=scnode1:/export/home/sol_10_807_sparc/Solaris_10/Tools/Boot install=192.168.87.53:/export/home/sol_10_807_sparc boottype=:in sysid_config=192.168.87.53:/export/home/jumpstart install_config=192.168.87.53:/export/home/jumpstart rootopts=:rsize=8192 ns=[192.168.201.25]:dns[255.255.252.0]


Friday Jul 13, 2007

Fino's Additions for wt.properties

While running a Windchill 8.0 Sizing Study on Solaris, changes and additions to Windchill property files reduced the CPU load and improved the average response time.  

http://blogs.sun.com/taylor22/entry/finos_additions  

[Read More]

Wednesday May 30, 2007

FAQ for Windchill on Solaris

I work in Sun's "ISV Engineering" team.  Our responsibilities include working with Sun's key ISV partners to port, tune and optimize industry leading applications on Sun's hardware and software stack, and to ensure that the latest solutions from the ISV's are certified on the latest products from Sun. One of the applications that I focus on is Windchill from  PTC.  As such, I am in frequent contact with PTC's R&D, Global Services, QA and customers, all of whom bring varying degrees of Solaris expertise.  This is a collection of questions and answers.

 http://blogs.sun.com/taylor22/entry/faq_for_windchill_on_solaris

[Read More]

Friday May 25, 2007

JVM Tuning for Windchill

    The World Wide Web is full of articles that cover Java Tuning. With so much information available, it is hard for a Windchill Administrator to know where to start. Which approaches are useful? Which articles and options apply to Windchill? How to get started? What are the right settings for Windchill?

    Why is this so hard? The best Java options depend on the hardware that is used for the Windchill server and the usage patterns of the Windchill users. One of the fundamental questions that needs to be answered by every Windchill administrator is: “Is memory being used efficiently?” Every Windchill installation will need to customize –Xmx, which sets the maximum size of the Java heap. The default value is 64MB1., much too small for Windchill. Unfortunately, there is not one correct answer for every installation. When a well written Java program performs poorly, there are two typical causes. Either the Java heap size is two small causing an excessive amount of garbage collection, or a Java heap size that is so big that portions are paged to virtual memory. Either problem can be severe, so finding a balance is important. In conjunction with setting the right heap size, every administrator will need to set the size of the Eden (young), survivor, and tenured (old) generations2. Also, there are a large number of other Java options, some that help Windchill, some that have minimal impact, and some that only apply to JVM releases that are not supported by Windchill3.

    This article will focus on Java 1.4.2. Windchill 8.0 M020, released in May 2006, was tested with the Sun Microsystems Java Software Developer Kit version 1.4.2_09 for Solaris 9 and 10. The Support Matrix notes that higher versions in the 1.4.2_xx series are also expected to work.

http://blogs.sun.com/taylor22/entry/jvm_tuning_for_windchill 

[Read More]
About

user12620111

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today