The impact of software on processor capacity is the topic Albert Leigh addresses in his blog entitled "Co-locating Multiple Instances of WebSphere on Scalable Sun Servers." He uses the SPECjAppServer 2004 benchmark to discover just how many WAS instances are required to drive various Sun servers to full utilization.

Leigh's results are shown below:

• On a T2000 (1 CPU, 8 Cores/4 Threads (32 processors)), 1 WAS instance
• On a T5120/T5220 (1 CPU, 8 Cores/8 Threads (64 processors)), 2 WAS instances
• On a T5140/T5240 (2 CPU's, 8 Cores/8 Threads (128 processors)), 4 WAS instances
• On a T5440 (4 CPU's, 8 Cores/8 Threads (256 processors)), 7 WAS instances

Though he concedes that not every application has the same workload demand as every other, Leigh does suggest that his results are useful as a guideline for such exercises as capacity planing.

The author also suggests that results such as these would be useful in helping enterprise customers leverage their high capacity systems, most of which typically exceed software capabilities and require the deployment of many software instances to increase system utilization levels.

Several considerations figure in providing a reliable and scalable system environment for co-locating multiple WebSphere instances on scalable Sun servers, Leigh continues, listing them as follows:

• "JVM Ergonomics: I have discussed about it in my previous blog entry.

• JVM tuning with proper Heap sizing and appropriate GC policy: You should do finer tuning of each JVM instance while keeping all co-existing instances on the system in mind. We describe about JVM tuning in our IBM Redbook, Chapter 9.4, pp. 346-376, and our IBM Impact 2008 presentation on WAS Performance Management on Solaris.

• Partitioning the system with Dynamic Systems Domain on enterprise class servers, Logical Domain on CMT servers, Solaris Containers on all Solaris 10 systems, and xVM (in the near future) as described in our Redbook Chapter 5.

• Isolating Processor and Memory Consumption: Dileep Kumar's blog entry and our Redbook [Chapter 5.4 (pp. 142-149)] and the IBM Impact 2008 presentation on WAS Deployment Best Practices on Solaris.

• Isolating Interrupt Processing: prstat -i

• Distributing Network Load: ifconfig

• Increasing certain kernel parameters such as rlim_fd_cur for setting file descriptor limit and segkpsize for kernel stack segment size. If you have hundreds of JVM's on a system, look into this setting. In Solaris 10, each lwp uses 32KB of kernel stack virtual address space - 24K of stack plus an 8K redzone. The default kernel stack segment size is 2GB for 64-bit kernels, and this limit is reached with 64K lwp's. You can increase the limit by setting segkpsize in /etc/system. It has units of 8K pages, eg to set the limit to 4 GB use: set segkpsize = 0x80000

• Leverage Dynamic Caching services (DynaCache) in WAS"

Leigh concludes that users should also make sure other things like proper WAS Thread Pool Settings collectively. If you take the inventory of all configuration settings and tuning parameters of the co-existing software and provide adequate settings not exceeding the physical capacity, your systems will be more reliable and scalable. Most of these best practices have been documented in a Redbook, he notes.

More Information

Leigh\'s complete blog

Java Virtual Machine Specification, Second Edition [...read more...]

		fullsource
Print Email Current Profile Archive Blog Generate newsletter