JVM Configurations
- Eric Dalquist
- Andrew Petro
- Martin Åhfeldt
Eric Dalquist at UW Madison has documented their work on tuning the JVM heap for uPortal uPortal Heap Tuning.
Some additional recommended settings:
# Set timeout values to something long (especially the ReadTimeout where you may wait on a long SQL or WebServices response) # to insure a thread doesn't wait indefinitely on a bad network connection. -Dsun.net.client.defaultConnectTimeout=20000 -Dsun.net.client.defaultReadTimeout=240000
Other observations:
- uPortal creates a large number of transient objects. There is a definite advantage to having a larger heap, say 4GB as a baseline setting (meaning you'd probably want around a 6 - 8 GB RAM machine though if you go with 6GB insure the OS is not paging with heavy load). I'd recommend 5GB heap with an 8GB machine. uPortal can run with as low as 2GB heap, but there are much more frequent full garbage collections and it definitely impacts uPortal's ability to handle larger numbers of users logging in during a short period of time and user response thereof.
- There is also an advantage especially with a larger heap (4GB+) to having new generation heap size to around 1/2 of overall heap size rather than the JDK 1.6/1.7 default sizing of around 1/3. With a smaller heap, it is probably better to have the larger tenured heap size to reduce the frequency of full GC cycles.
- CMS collector is very helpful to reducing the duration of full GC cycles. Performance testing generally shows a slight increase in CPU usage so it is generally worth it to avoid long (5+ second) pause times for full GC operations. If the machines are generally CPU bound, the tradeoff is not so clear (though we'd generally recommend adding another machine or carefully looking at your portlet and portal caching if heavily CPU bound).
Who | Hardware/Software | JVM | JVM Arguments |
|---|---|---|---|
Unversity of Madison - Wisconsin | J2SE 1.7 trying to get to Java 8 | Last updated here: 2016-07-12 # First option is env so it is visible in ps -Dmum.env=my-test # Memory Configuration -server -d64 # switch to 64bit server mode -Xmx4g # Set max heap size -XX:MaxGCPauseMillis=300 # GC Pauses up to 250ms aren't bad, have ergonomics try and keep pauses below this level -XX:+UseG1GC # use G1GC as garbage collection aglorithm # Set a large enough perm gen -XX:MaxPermSize=768m # Cache DNS lookups but not too long -Dnetworkaddress.cache.ttl=3600 # memory tweaks to avoid Hotspot Compiler Failure -XX:ReservedCodeCacheSize=128M # Log garbage collection -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy -Xloggc:/my/up/logs/gc.log | |
| Göteborg University developed by LDC, Lund University | Intel(R) Xeon(R) CPU X6550 4 cores @ 2.00GHz 12Gb RAM | java version 1.7.0_17 | -Xms2G |
Texas Tech University | RHEL, Dual Intel(R) Xeon(TM) 3.20GHz CPU 1Gb Ram, Tomcat 5.0.28 | Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode) | -Xms256m |
University of the West of England | Sun Fire V440, Solaris 8, 4 X 1284mghz, 16Gb Ram, Apache 2, Tomcat 5.0 | J2se 1.4.2_06 | -Djava.awt.headless=true |
Memorial University of Newfoundland | Sun Fire 880, Solaris 8, 4 x CPUs - 750 MHz | J2SE 1.4.1-b21 | -server |
University of British Columbia | Sun V440, SunOS 5.9, 4x1.3Hgz ?, 8Gb, Apache 2.0.55, Tomcat 5.5.7, mod_jk 1.2.15 | 1.5.0_06-b05 | -DmyUBC=prod2 |
Rutgers University | 4 x Sun Fire v240 2x1GHz 4 GB RAM, Solaris 8, Tomcat 5.0.28, Apache 1.3.33, mod_jk 1.3 | 1.5.0_05-b05 | # Use server hotspot compiler |
The University of Manchester | 6 x Dell PowerEdge 2850 running Tomcat on Debian Linux behind hardware load balancer using sticky sessions, 2 x Sun T2000 servers (High-Availability failover cluster) as database tier running MySQL | 1.5.0_14 |
|
University of Victoria, B.C. | RHEL 5_64, Dell PowerEdge r710, dual Intel(R) Xeon(R) CPU X5650 @ 2.76GHz (12 cores total), 24GB Ram, Tomcat 6.0.29 | 1.6.0_18 | -server |