Monday Dec 14, 2009

JDK 6 Performance Update, WAS v7, Fix Pack 7, and the G1 Collector

The Fix Pack 7 release for WebSphere Application Server v7 includes the JDK 6 SR6 update. It will update Java to Java SE 6 Update 16.

If you have not upgraded your WebSphere application environment to JDK 6, here are the reasons that you should upgrade to the latest. You will see many improvements with performance, stability and scaleability. In addition to these benefits, Fix Pack 7 with SR6 includes the new garbage collector known as the Garbage First or G1 Collector. It is concurrent and parallel with more predictability and better useability. It splits the heap into regions and young and old generational spaces are organized in sets of regions. This eliminates the need to fine tune "NewSize/MaxNewSize". G1 also provides incremental compaction in those regions by "evacuating" the regions that are full and fragmented...

[Read More]

Wednesday Mar 25, 2009

Solaris Network Tuning for WebSphere Application Environment

This blog entry clarifies the recommendation of Solaris network tuning discussed in WAS v6.1 on Solaris 10 Redbook (Ch 2.2 p.25) and WAS v6.1 ND Tuning Guide.

[Read More]

Tuesday Feb 10, 2009

Updating WebSphere, Java and Solaris for Better Performance and Reliability

Keeping your WebSphere application environment on Solaris updated with the recommended Fix Packs and Service Releases from IBM and Solaris update releases and patches is a key to better performance and reliability. For example, if you have WebSphere Application Server v6.1 with Fix Pack 5, you may find slowness in the garbage collection process using the throughput collector (ParallelGC).[Read More]

Friday Jun 15, 2007

A SMF Service Manifest for WebSphere Application Server on Solaris 10

Service Management Facility (SMF), introduced in Solaris 10, enables a unified model for services and service management on each Solaris system. It is a core part of the Predictive Self-Healing technology available in Solaris 10, which provides automatic recovery from software and hardware failures as well as administrative errors.

One of my colleagues at Sun, Bob Netherthon, has a very nice slide deck on SMF here.

Since many of our customers asked, I have created a basic service manifest and simple instructions for WebSphere Application Server (WAS) as an example.


  1. Put the service manifest file named "was61.xml" to a temporary directory /tmp.
  2. Put the service method file named "svc-was61" in /lib/svc/method/svc-was61.
  3. Edit this service method file to reflect the correct WAS path information, etc.
Follow the steps below.
    bash-3.00# chmod 755 /lib/svc/method/svc-was61
    bash-3.00# svccfg import /tmp/was61.xml
    bash-3.00# svcadm enable was61
    bash-3.00# svcs -l was61
    fmri         svc:/application/was61:was_server1
    name         WebSphere Application Server v6.1
    enabled      true
    state        online
    next_state   none
    state_time   Thu Jun 14 18:23:17 2007
    logfile      /var/svc/log/application-was61:was_server1.log
    restarter    svc:/system/svc/restarter:default
    contract_id  1819
    dependency   require_all/error svc:/milestone/network:default (online)
    dependency   require_all/none svc:/system/filesystem/local:default (online)
    dependency   optional_all/error svc:/system/filesystem/autofs:default (online)

Once you do "svcadm enable was61", WAS should start if the configuration is valid. The log file is located at: /var/svc/log/application-was61:was_server1.log.

If the service need to be removed, do the following:

    bash-3.00# svcadm disable was61
    bash-3.00# svccfg delete was61


Note that in the manifest, the exec_method was defined using the service method (e.g. external shell script: exec="/lib/svc/method/svc-was61 start"). This could be a WAS command itself (e.g. exec="/opt/IBM/WebSphere/AppServer/profiles/AppSvr01/bin/ start"). The service method is a good way to separate the WAS start up/shutdown commands because if you need to change the profile or WAS location for this application service, you just need to modify in the service method script rather than having to re-configuring the service manifest.

In the case you have multiple WAS profiles, applications or versions, this manifest can also be used as a template to create new service manifests (e.g. was61_tradeapp1, was602_storeapp1, etc.).

You can also add other dependencies in the service manifest that the WAS services rely upon (e.g. another standalone application that your application requires to be co-located on the same system or a JMS provider that must be started before the WAS services, etc.).

Another good practice is to have the WAS processes to be started by a non-root user, which you can configure accordingly like this example for Apache.

Best of all, look at OpenSolaris website for:

Finally, you should include useful and concise comments in the service manifest and methods for ease of maintenance.


Mostly pertaining to Cloud Computing, Application Infrastructure, Oracle Exastack, Exalogic, Solaris, Java and Sun servers for the enterprise!


« June 2016