Apache Tomcat Version 7.0.69

jruby 9.1.0.0 (2.3.0) 2016-05-02 a633c63
Java HotSpot(TM) 64-Bit Server VM 25.91-b14 on 1.8.0_91-b14 +jit [linux-x86_64](Packaged by Warbler)

JVM settings are:
-XX:InitialHeapSize=2147483648 -XX:+ManagementServer -XX:MaxHeapSize=2147483648 -XX:MaxNewSize=536870912 -XX:NewSize=536870912 -XX:+PrintAdaptiveSizePolicy -XX:+PrintClassHistogram -XX:+PrintCommandLineFlags -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintStringDeduplicationStatistics -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC

We are using Sinatra as the framework.

Expected Behavior

Under JRuby 1.7.18 with about 748M of heap we get:

• JVM is given around 700M of heap.
• Predictable, consistant, response times for the application queries to external data sources. Response times are typically 3 to 7 seconds.
• Typical sawtooth memory / GC pattern of frequent small collections with occasional larger collections. The only full GC is at startup.

Actual Behavior

Under JRuby 9.1.0.0 with 2G of heap we get:

• Long response times for queries to the same data sources. Times more than double to greater than 14 seconds. Requests start getting timeouts.
• GC collection behavior becomes erratic with mixed long and short collections. Many Full GC start happening, particularly as the run length
  increases. This happens with default GC settings and with G1.

Attached are PDF with graphs of the behavior.

After we stopped our test we got a 2G heap dump that shows a retained size of 1.3 G with about 1/2 of that retained by org.jruby.ext.openssl.X509Store. Off the top of my head that seems large. Any suggestions on how to look deeper at the dump would be welcome.

Application GC with JRuby 1.7
Dash Ramp 2.1-1.7.pdf

Application GC with JRuby 9.1
Dash Ramp 2.1-9.1.pdf