Memory footprint RelationalDescriptor [message #501422] |
Wed, 02 December 2009 09:50 |
Ana Oleski Messages: 22 Registered: July 2009 |
Junior Member |
|
|
Hi,
I'm analyzing the memory footprint of a server application (eclipselink 1.1.2, no JPA) which has about 900 persistent classes. The biggest dominator object according to Eclipse MAT is a RelationalDescriptor.
I've calculated the retainedSet for all objects of the RelationalDescriptor class and came up with 578.425.856 bytes.
There are among others 745.853 UnitOfWorkQueryValueHolder objects, quite a lot of business objects. See attached file.
I think we might have the problem described in https://bugs.eclipse.org/bugs/show_bug.cgi?id=289771 namely that our expressions have entity objects as parameters and, since expressions are cached by default in eclipselink, we end up referencing UnitOfWorkValueHolders, UnitOfWorks, the whole lot.
My question is: can the expression cache problem explain all those objects? Or do relational descriptors point somehow to the normal eclipselink cache too . We use the SoftReference setting with 100 entries pro class.
If I want to calculate the retained set of the eclipselink cache, where should I best start (which class)?
Ana
P.S. can't attach file, here are the contents
Class Name | Objects | Shallow Heap
------------------------------------------------------------ ------------------------------------------------------------ ---------------------
| |
org.eclipse.persistence.internal.indirection.UnitOfWorkQuery ValueHolder | 745.853 | 89.502.360
org.eclipse.persistence.indirection.IndirectList | 583.182 | 60.650.928
java.lang.Object[] | 1.021.006 | 46.120.032
org.eclipse.persistence.internal.sessions.ObjectChangeSet | 189.389 | 33.332.464
org.eclipse.persistence.internal.identitymaps.UnitOfWorkCach eKey | 212.090 | 23.754.080
org.eclipse.persistence.indirection.ValueHolder | 542.125 | 21.685.000
org.eclipse.persistence.internal.identitymaps.CacheKey | 189.389 | 21.211.568
java.lang.Long | 619.884 | 19.836.288
java.util.HashMap$Entry | 309.557 | 17.335.192
int[] | 224.292 | 16.736.936
java.util.GregorianCalendar | 74.672 | 13.142.272
org.eclipse.persistence.internal.indirection.BackupValueHold er | 261.520 | 12.552.960
org.eclipse.persistence.internal.helper.NonSynchronizedVecto r | 246.296 | 11.822.208
sun.util.calendar.Gregorian$Date | 75.218 | 10.229.648
de.bkm.bes.kontosystem.konto.BoSaldoBausparkonto | 7.113 | 8.763.216
de.bkm.bes.finanzierungsystem.vorgaben.in.rolle.produkt.BoRe lation_Finanzierungsvertragsauflage_ZulaessigeProdukte| 43.322 | 8.664.400
char[] | 70.872 | 8.525.784
java.lang.reflect.Method | 38.635 | 6.490.680
de.bkm.bes.kontosystem.konto.BoKontobewegungBausparen | 12.510 | 5.604.480
de.jdpe.bof.bo.pm.BoId | 94.207 | 5.275.592
de.bkm.bes.finanzierungsystem.vorgaben.in.rolle.produkt.BoFi nanzierungsvertragsauflagenprodukt | 43.322 | 4.505.488
java.util.Vector | 92.987 | 4.463.376
de.bkm.bes.produktsystem.produkt.BoRelation_Hauptprodukt_Kom binationsprodukt | 19.736 | 4.262.976
java.util.ArrayList | 82.337 | 3.952.176
java.util.HashMap | 46.500 | 3.720.000
byte[] | 74.672 | 3.584.256
de.bkm.bes.produktsystem.produkt.BoBauspargeschaeftskomponen te | 8.778 | 3.581.424
java.lang.String | 70.892 | 3.402.816
de.bkm.bes.produktsystem.produkt.BoKonditionenGueltigkeit | 22.040 | 3.350.080
java.util.HashMap$Entry[] | 48.205 | 3.254.792
java.util.concurrent.locks.ReentrantLock$NonfairSync | 54.144 | 3.032.064
java.util.concurrent.ConcurrentHashMap$Segment | 54.144 | 3.032.064
java.util.Hashtable$HashtableCacheHashEntry | 51.172 | 2.865.632
org.eclipse.persistence.internal.helper.ConcurrencyManager | 50.336 | 2.818.816
de.bkm.bes.produktsystem.produkt.BoKGKHypothekendarlehen | 5.282 | 2.366.336
de.bkm.bes.kontosystem.konto.BoKontobewegungDarlehen | 4.428 | 1.912.896
de.jdpe.bof.bo.tm.BotTimestamp | 44.355 | 1.774.200
de.bkm.bes.kontosystem.konto.BoSaldoDarlehenskonto | 2.364 | 1.720.992
de.bkm.bes.kontosystem.konto.rules.BoRelation_Buchungsvorsch rift_Umsatzkennzahl | 8.920 | 1.641.280
org.eclipse.persistence.mappings.DirectToFieldMapping | 10.237 | 1.637.920
de.jdpe.bof.bo.tm.BotPeriod | 39.578 | 1.583.120
org.eclipse.persistence.internal.sessions.DirectToFieldChang eRecord | 28.035 | 1.569.960
de.bkm.bes.finanzierungsystem.vorgaben.BoStatus_Finanzierung svertragsauflage | 6.708 | 1.502.592
de.bkm.bes.produktsystem.produkt.BoFinanzprodukt | 15.168 | 1.456.128
de.bkm.bes.finanzierungsystem.vorgaben.BoRelation_Finanzieru ngsvorgaben_ZulaessigeAuflagen | 6.708 | 1.341.600
java.util.concurrent.ConcurrentHashMap$HashEntry[] | 54.144 | 1.312.440
Total: 46 of 14.927 entries | 7.142.589 | 578.425.856
------------------------------------------------------------ ------------------------------------------------------------ ---------------------
[Updated on: Wed, 02 December 2009 09:55] Report message to a moderator
|
|
|
Re: Memory footprint RelationalDescriptor [message #501733 is a reply to message #501422] |
Thu, 03 December 2009 15:58 |
|
Are you having memory issues?
If you are, you can confirm if the issues is the expression cache by using the workaround mentioned in the bug,
Iterator it = session.getDescriptors().values().iterator();
while(it.hasNext()) {
ClassDescriprtor desc = (ClassDescriptor)it.next();
desc.getQueryManager().setExpressionQueryCacheMaxSize(0);
}
If your memory issues goes away, then this was the cause.
Otherwise, you need to figure out what is holding onto your memory. For the object cache, you could try setting the type to WEAK, or decreasing the size, or setting shared to false.
James : Wiki : Book : Blog : Twitter
|
|
|
Powered by
FUDForum. Page generated in 0.02941 seconds