All Things WebSphere

Concerns and issues relating to all versions of WebSphere Application Server

Thursday, August 23, 2012

Serviceability gem: Deadlock in WebSphere application server

If your application code in WAS is repeatedly running into a deadlock situations and you want to be forewarned, you can use the ThreadMXBean exposed by the JVM and call these methods

java.lang.management.ThreadMXBean.findDeadlockedThreads()
java.lang.management.ThreadMXBean.findMonitorDeadlockedThreads()

If either of the two threads returns a non null value programmatically call a system dump and dump whatever other state you need to diagnose the problem. You can view the contents of the system dump in Eclipse Memory Analyzer Tool.

The House MD equivalent for WAS :-) Kevin Grigorenko has an application deadlockWatch.war that you can use to take a javacore, if there is a deadlock in order to capture the state of the system at the time of the deadlock.

There is no way around having to figure out a proper interval which balances catching it versus the overhead of the check. The default in this app is a 5 minute interval (30000 ms) and you can change that with -Dcom.ibm.deadlockWatch.DeadlockWatcherThread.sleepTime=N (where N is in milliseconds). Source code is included in the application if you'd like to modify it yourself.

posted by Rohit Kelapure # 1:54 PM 0 Comments

Is there a limit to how big an HTTPSession object can be in WebSphere Application Server

For memory to memory session persistence you can go as big as you want although anything bigger than 10K is problematic.

If the sessions are being persisted to the database, then there is a possible limit. If you are using single-row, then if the session size is greater than 2MB - we can not store it and therefore if there is a failover, it will not be retrieved. Using a multi-row schema allows the attributes to be stored in separate rows and so the overall size of the session object can be > 2MB. The smaller the better as far as replicating sessions.

I would recommend viewing this doc as it has some information about performance for various session sizes for both database and memory to memory replication: ftp://public.dhe.ibm.com/software/webservers/appserv/was/WASV8_SessionReplication_Performance_v1.0.pdf

* Credit to WAS Session subject matter expert Robert Goff

posted by Rohit Kelapure # 1:29 PM 0 Comments

Tuning WebSphere Application Server on Linux on System z

To better utilize, virtualize and optimize your WAS zLinux environment to serve more applications and users please go through the following white papers and best practice documents to squeeze the last bit of performance from WAS on zLinux

1. Idle WebSphere Tuning Considerations
This was a study done specifically on zLinux to help with swapping of JVMs when they are idle
http://ibm.co/jUcb9M

2. Match 31-bit WebSphere Application Server performance with new features in 64-bit Java on System z
Solve 31-bit virtual memory crowding issues without sacrificing performance by using heap compression and large pages
https://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/whitepaper/systemz/java_websphere/performance

3. Linux on System z, an end-to-end view: from Sizing to Performance Analysis to Capacity Planning
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100908

4. Architecting z/VM and Linux for WebSphere V7 on System z
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101803

5. Sharing a WebSphere Application Server V8 installation among many Linux for IBM System z servers
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102145

* Thanks to Mike Everett and David Hare, WAS performance experts for providing these links

posted by Rohit Kelapure # 1:15 PM 0 Comments

Tuesday, August 14, 2012

Monitoring and Operational best practices in WebSphere Application Server

Operational best practices for WebSphere from kelapure

posted by Rohit Kelapure # 8:48 AM 0 Comments