Kristof,
Looking at your settings, I have the following comments:
wrapper.cpu.timeout=120
CP> I understand why you changed this one -- though I hope you don't have many GCs that take longer than 60-90 seconds. JRockit is very fast, even at full GCs, so if this is the case, than either your server is swapping, your heap is too small (I'd move up to 2200MB), or you're running too much in the system at once and need to throttle it, in order to increase performance. This may not seem intuitive, but if you throttle and reduce JVM heap memory usage, JRockit wlll be able to process
wrapper.startup.timeout=0
CP> This should be 60 - no reason to change.
wrapper.shutdown.timeout=0
CP> This should be 120. If WebLogic doesn't shutdown in 120 seconds, there is an issue and JSW should kill it. This setting ensures that WebLogic is always shutdown before the next one starts up and you don't end up with hung or zombie processes. wrapper.java.additional.22=-XXtlasize64k
CP> I honestly haven't had to use this one in the past. I've seen it referenced in a developer's blog in the past, but haven't had a system where it was necessary to utilize. (Henrik Stahl's Blog: June 2006 Archive)wrapper.java.additional.23=-XXlargeobjectlimit8k
CP> I honestly haven't had to use this one in the past. I've seen it referenced in a developer's blog in the past, but haven't had a system where it was necessary to utilize. (Henrik Stahl's Blog: June 2006 Archive)wrapper.java.additional.4=-Xgc
arallel
CP> I've had much better luck with "-Xgcprio:throughput", as this allows JRockit to dynamically switch GC algorithms while running -- to ensure that the JVM adapts to the current usage and load.
Honestly, I believe that your greatest gains would be from increasing the heap, and adjusting the workload so that the JVM heap doesn't get overwhelmed -- thus avoiding full GCs and GC memory lock issues; and thereby creating a much faster system.
Hope this helps!
--Chris