Load Runner Example

This topic shows an example of a 50-user run of loadrunner.

These internal longevity tests were run under unusually heavy load for approximately one hour.

See Also
Memory Manager Configuration Settings
Memory Manager Error and Log Messages
Live Collaboration Server Memory Management
Run Heap Partial GC Full GC Native High Notes
1 128m 257 359 77m Increase load on system, native highwater too low
2 128m 357 137 180m Why such a decrease in Full GC? *
3 256m 156 321 180m Full GC too high
4 256m 123 259 159m Full GC still too high
5 640m 310 4 150m Looks good
* Results of this run are questionable.

1st run - java heap set to 128m 

java -verbosegc -XX:+DisableExplicitGC -Xss512k -Xms128m 
-Xmx128m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2 
-Xconcurrentio -XX:MaxPermSize=64m -native

2nd run - java heap set to 128m

java -verbosegc -XX:+DisableExplicitGC -Xss512k -Xms128m 
-Xmx128m -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2 
-Xconcurrentio -XX:MaxPermSize=64m -native

3rd run - java heap set to 256m

java -verbosegc -XX:+DisableExplicitGC -Xss512k -Xms256m 
-Xmx256m -XX:NewSize=128m -XX:MaxNewSize=128m 
-XX:SurvivorRatio=2 -Xconcurrentio -XX:MaxPermSize=128m -native

4th run - java heap set to 256m perm size changed

java -verbosegc -XX:+DisableExplicitGC -Xss512k -Xms256m 
-Xmx256m -XX:NewSize=128m -XX:MaxNewSize=128m 
-XX:SurvivorRatio=2 -Xconcurrentio -XX:MaxPermSize=64m -native

5th run - java heap set to 640m 

java -verbosegc -XX:+DisableExplicitGC -Xss1024k -Xms640m 
-Xmx640m -XX:NewSize=317m -XX:MaxNewSize=317m 
-XX:SurvivorRatio=2 -Xconcurrentio -XX:MaxPermSize=128m -native

From these test iterations you can see that 128 and 256m java heaps are too small. Partial GC's are OK, Full GCs should be avoided.

Sizing the heap to 640m gives the ratio of Partial to Full GC's that we are looking to achieve.Ideally, we would collect more datapoints and run the tests over a longer period of time. So we have:

  • Free = 100m
  • Java Heap = 640m
  • Native available = ~ 3.2 g (4 g process limit (or physical RAM free) - Free - Java Heap)

3.2g is probably too large a value and would allow runaway queries/expands to consume CPU resources. Allowing for a suitable multiple of high water of ~3, the MX_MEMORY_SYSTEM_LIMIT is set to 640m. Because the sample we are running is using a subset of potential operations in the app, a judgement needs to be made with respect to the high water number. If the development system that is being analyzed is only using 1/10 of the potential user load of the production system, a higher multiplier might be more appropriate.