CoolThreads - CMT Tuning and Resources

BEA Weblogic

BEA Weblogic Configuration Notes

The tuning of Weblogic varies slightly with the version being used

We recommend using the latest release BEA 9.0 which enables Sun's latest JVM 1.5.0_06. If migration to BEA 9.0 is not possible then use BEA 8.1 SP with JVM 1.4.2_08.

Use libumem for BEA:

LD_PRELOAD_32=/usr/lib/libumem.so.1 startWebLogic.sh

Given below are settings used for applications that services JSP and has about 10 EJBs each with a cache size of about 10000 entries and servicing NN simultaneous requests

JVM 1.5.0_06 Options:

-server -XX:+AggressiveHeap -XX:ParallelGCThreads=4 -Xmx3g -Xms3g -Xmn800M -XX:LargePageSizeInBytes=4m -XX:-BindGCTaskThreadsToCPUs -XX:MaxTenuringThreshold=3 -XX:SurvivorRatio=20 -Xloggc:/tmp/gc.log -Dweblogic.SocketReaders=10

JVM 1.4.2_08 Options:

-server -XX:+UseParallelGC -XX:+AggressiveHeap -XX:ParallelGCThreads=4 -Xms3g -Xmx3g -Xmn800m -Xss128k -XX:LargePageSizeInBytes=4m -XX:-BindGCTaskThreadsToCPUs -XX:PermSize=128m -XX:MaxTenuringThreshold=3 -XX:SurvivorRatio=20 -Xloggc:/tmp/gc.log -Dweblogic.SocketReaders=10

Watch the Garbage Collection (GC) activity via log file (/tmp/gc.log if using the above JVM options) to see if GC is an issue. Tune heap size if necessary (-Xmx, -Xms) to reduce Full GC and or to reduce time spent in Full GC.

You can use these additional parameters to get details about GC activity.

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps-XX:-TraceClassUnloading

Run multiple BEA instances if necessary.

Tune worker thread pools to better balance execute queues in the applications. To manually tune the worker threads in BEA 9.1, set the following in config.xml

<use81-style-execute-queues>true</use81-style-execute-queues>

Enable native io in config.xml

Tune JDBC parameters depending on application

jdbc connection pool size statement-cache-size

Other tunables

keep-alive timeout accept-backlog socket-reader-timeout number of socket readers

BEA 8.1 Tuning Guide

http://e-docs.bea.com/wls/docs81/perform/index.html
http://e-docs.bea.com/wls/docs81/perform/HWTuning.html

Other URL

http://dev2dev.bea.com/pub/a/2002/10/subramaniam.html
http://dev2dev.bea.com/cs/user/view/cs_msg/257

IBM Websphere

IBM Websphere Configuration Notes

TCP related tunings:

ndd -set /dev/tcp tcp_conn_req_max_q 16384
ndd -set /dev/tcp tcp_conn_req_max_q0 16384
ndd -set /dev/tcp tcp_xmit_hiwat 400000
ndd -set /dev/tcp tcp_recv_hiwat 400000
ndd -set /dev/tcp tcp_cwnd_max 2097152
ndd -set /dev/tcp tcp_ip_abort_interval 60000
ndd -set /dev/tcp tcp_rexmit_interval_initial 4000
ndd -set /dev/tcp tcp_rexmit_interval_max 10000
ndd -set /dev/tcp tcp_rexmit_interval_min 3000
ndd -set /dev/tcp tcp_max_buf 4194304

WebSphere Application Server 6.0.2
JDK 1.4.2_XX(Supported version)

initialHeapSize= eg. 2048
maximumHeapSize= eg. 2048
-server
-Xnoclassgc
-Xmn1024m At least 50% of the heap size; more may be better try and adjust accrodingly
-XX:-UseAdaptiveSizePolicy
-XX:MaxTenuringThreshold=4
-XX:+UseParallelGC
-XX:ParallelGCThreads= either equal to number of cpu or on multi core systems set it to somewhere between .5-1xNumber of cores.
-XX:+AggressiveHeap

EJB Cache Size = 37543
HTTP Channel maximum persistent requests = -1
HTTP Channel readTimeout/writeTimeout = 6000/6000
HTTP Channel persistentTimeout = 3000

WebSphere Application Server 6.1
JDK 1.5.0_06

Minimum heap size=2880 MB Maximum heap size=2880 MB
initialHeapSize="2880" maximumHeapSize="2880" verboseModeGarbageCollection="true
-server -Xmn780m -Xss128k -XX:-ScavengeBeforeFullGC -XX:+UseParallelGC
-XX:ParallelGCThreads=24 -XX:PermSize=128m -XX:MaxTenuringThreshold=16
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelOldGC
-Dcom.ibm.ws.pm.batch=true -Dcom.ibm.ws.pm.deferredcreate=true
-Dcom.ibm.CORBA.FragmentSize=3000 -Dcom.ibm.ws.pm.useLegacyCache=false
-Dcom.ibm.ws.pm.grouppartialupdate=true
-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
-Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XML11Configuration
EJB Cache Size = 37543
HTTP Channel maximum persistent requests = -1
HTTP Channel readTimeout/writeTimeout = 6000/6000
HTTP Channel persistentTimeout = 3000
Web Container threads (Minumum/Maximum) = 56/56
ORB threads (Minumum/Maximum) = 40/40
Default threads (Minumum/Maximum) = 15/15
Java process changed to run in FX class using:
/usr/bin/priocntl -s -c FX -m 59 -p 59 -i pid

Tuning Websphere Application Server 6.1 for UltraSPARC T2 Systems

JBoss On Solaris Best Practices

Memory options

Memory requirements are very closely tied to your application, but below are some reasonable default options that should give you a good starting place. This will set up the JVM with 1 GB of memory:

-Xms1024m -Xmx1024m -XX:+UseParallelGC -XX:ThreadStackSize=128k

Turn off extraneous logging and tomcat dev mode

JBoss, by default, is designed to be simple for a developer to use. When you are ready to deploy your application, you should turn off some of the features that are most useful in development.

1. Edit $JBOSS_HOME/server/default/deploy/jbossweb-tomcatXX.sar/conf/web.xml and turn off tomcat debug mode. There are also some other tuning variables that may or may not benefit your specific application. These options are well documented inside the web.xml file.
2. Turn down logging by editing $JBOSS_HOME/server/default/conf/log4j.xml. JBoss uses Log4j which allows you a great flexibility to control logging. The default logging mode is INFO, but you can set it to a lower level such as ERROR to keep writes to disk to a minimum.
3. Change the deployment scanner time. By default this is set to 5 seconds. This is great for development, but in production you will probably want to set this higher. Maybe 5 or 10 min? You can change this setting by editing the file $JBOSS_HOME/server/default/conf/jboss- service.xml. The scanner options are well documented there.

Use JDK 1.5

If at all possible, you should use JDK 1.5. The garbage collector has been significantly improved and you will often see immediate performance gains. If you can only use JDK 1.4 in your environment, you should change the RMI GC interval. In our experience, the default of 1 minute is much to short for most applications. This will cause a full GC every minute!

The following options are the default in recent JBoss releases:

-Dsun.rmi.dgc.client.gcInterval=3600000
-Dsun.rmi.dgc.server.gcInterval=3600000

These options set the GC interval to 1 hour, which is much more reasonable in most cases. The option -XX:+DisableExplicitGC will also prevent the RMI GC's from occurring every minute.

Remove unused services

If you aren't using some services that JBoss provides you should remove them to free up resources. This is a more advanced topic, but this page has a detailed description of how to do this.

Java SE 5.0

Tuning Java SE 5.0 for optimal performance

Sun Java System Application Server

Sun Java System Application Server Configuration Notes

Use Sun Java System Application Server 8.2 version. If you are using Sun Java System Application Server 8.1 then we need patch 119167-02 along with Java SE 1.5.0_06.

Use libumem for the appserver:

LD_PRELOAD=/usr/lib/libumem.so asadmin start-domain

Java options -server -XX:+AggressiveHeap -Xmx2560m -Xms2560m -XX:LargePageSizeInBytes=256m -XX:ParallelGCThreads=8 -Xss128k May have to tune the GC with -XX:ParallelGCThreads.

May need multiple instances depending on application.

If you log HTTP access or your application is using XA transactions or MDBs, then separate the access logs, transaction logs and imq files onto as many disks as possible. Mount the disks with these options: nologging,directio,noatime. If you run multiple instances of the application server, move the logs for each instance onto separate disks as much as possible. If the disk becomes a bottleneck then use application server 8.2 feature to write txlogs to a database. If you are using more than one network interface, then you will need to make sure that all the network interrupts are not going to the same core.

Put the appserver processes into the FX scheduling class.

Tune the thread pool to match the needs of the application. Size the HTTP Thread pool and ORB Thread pool as small as possible for better throughput. Start with 20-30 threads and add more if you see CPU starvation. Size the HTTP acceptors (acceptor-threads) to match the machine. A general rule of thumb to follow is have one acceptor thread per core.

Turn off JSP recompilation.

Disable access logs, dynamic reloading and autodeploy features. Change the application server log level to WARNING.

References

• SJSAS 8.1 Installation Guide
• SJSAS 8.1 Administration Guide
• SJSAS 8.1 Performance Tuning Guide
• Java Performance