Shallow vs retained heap - Page 2

Question

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

~s.o.s~ 2,560 Failure as a human Team Colleague Featured Poster · Answer 1 · 2013-07-12T13:20:20+00:00

You have already established that the 'disconnect after certain idle time' setting works for bonecp. Now you need to analyze your code to see why is it taking up multiple connection objects for a single request (assuming that what's happening here). You don't need 4 test clients for this. Fire up your app and without sending across requests check how many connection objects are created. After that just send across a single request and then check how many connection objects you have.

It's quite possible that bonecp initializes all the connections eagerly resulting in a full pool. So basically from this point it's either:

Your app isn't releasing connections in a timely manner
Your bonecp configuration is causing the eager initialization of the entire pool

newbie14 0 Posting Pro · Answer 2 · 2013-07-12T18:38:39+00:00

Like you said below is the capture when the app is fired up without any connection to it yet.

11 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8" occupy 748,352 (14.94%) bytes.

Biggest instances:

•com.mysql.jdbc.JDBC4Connection @ 0xf670e550 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6738ec8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf675de60 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67889f8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67ad7c8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6810d50 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6835bd8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf685d1a8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6881f48 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68a6de0 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68cbb48 - 68,032 (1.36%) bytes. 


Keywords
com.mysql.jdbc.JDBC4Connection
sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8

Next I just make one single connection just with one data only I can see the connection increase to 13.

13 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8" occupy 884,336 (16.19%) bytes. 

Biggest instances:

•com.mysql.jdbc.JDBC4Connection @ 0xf670e550 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6738ec8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf675de60 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67889f8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67ad7c8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6810d50 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6835bd8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf685d1a8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6881f48 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68a6de0 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68cbb48 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6b839d0 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68f0940 - 67,952 (1.24%) bytes. 
These instances are referenced from one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]", loaded by "<system class loader>"

Keywords
com.mysql.jdbc.JDBC4Connection
java.util.concurrent.ConcurrentHashMap$Segment[]
sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8

Details »

Then I purpose make a second connection and the it remains to be 13.

~s.o.s~ 2,560 Failure as a human Team Colleague Featured Poster · Answer 3 · 2013-07-12T20:50:27+00:00

This might be just how bonecp manages the pool i.e. create connections eagerly though that still doesn't explain in the increase from 11 -> 13 given that it already had 11 connections to spare. I suggest you hit the bonecp forums since I'm not aware of how bonecp works to comment on this behaviour.

newbie14 0 Posting Pro · Answer 4 · 2013-07-14T12:56:50+00:00

I have hit the bonecp forum and will wait for their answer. Beside that on my production server which have been running I notice there is a slight increase in the memory especially on the resident memory and I am also monitoring the perm generation which also show some small increase over few days. What does all this pattern leads to?