The Effect of Statement Pool's Cache Hit Ratio on

the Full GC
A simple test program was created to assess the effect of cache
hit ratio on the full GC. One cache hit ratio was set to 100% while
the other was set to 50%. When the same amount of load was
applied, the results presented in Table 1 and 2 were obtained.
In both cases, the occurrences of young GC were very similar but the
results for the full GC was different. When the cache hit ratio was
100%, full GC occurred only once, because the number of objects
promoted to the old area during young GC was small. When the ratio
was 50%, full GC occurred 4 times because the number of statement
objects promoted to the old area during young GC was high, as the
objects were cached in the statement pool, then removed from the
pool in LRU way, then cached again at the next request.
Table 1. Cache hit ratio = 100%.
...

OC

OU

YGC

FGC

FGCT

GCT

...

10688.0

6940.9

532

0.190

1.274

...

10688.0

6940.9

532

0.190

1.274

Table 2. Cache hit ratio = 50%.

...

OC

OU

YGC

FGC

FGCT

GCT

...

10240.0

7092.7

554

0.862

2.253

...

10240.0

7412.0

555

0.862

2.255

I would like to add one more thing. When the cache hit ratio is 50%, it
violates the 2nd category of weak generational hypothesis I
introduced previously. When low cache hit ratio causes frequent pool
registration and subsequent removal, it means the statement object
generated in the young area is being referenced in the pool from the
old area, which leads to additional strain during GC because the card
marking technique is used to manage the references separately.

In Conclusion
In Lucy (NHN's internal Java Framework), the maxStatements value for
statement pooling in Oracle and MySQL is 500. In most cases, 500
should be enough. However, when more SQL is being used, increasing
the default value to meet such demand would be a way to improve
the system efficiency (when using $(String replacement) for query on
iBatis for the reason of table partitioning and the like, the number of
queries must be multiplied by the number of partitioned tables).
However, when the default value is higher than necessary, this leads
to a different problem. A higher value means more memory usage
and higher likelihood of an Out Of Memory (OOME) occurrence.
In a situation where the number of SQLs are 10,000 and the number
of connections are 50, then the total size of statement objects is
about 250 MB. (500 byte * 50 * 10,000 = 250 MB). It should be easy
to determine the likelihood of OOME occurrence by checking the Xmx
configuration for the service in use.
What strategy do you follow to determine the correct number of
statements to be pooled? Share your experience in the comments
below.
By Dongsoon Choi, Senior Engineer at Game Service Solution Team,
NHN Corporation.