Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » Memory comsumption with eclipselink (2.7)
Memory comsumption with eclipselink (2.7) [message #1860101] Mon, 17 July 2023 20:32 Go to next message
Vicente Rossello is currently offline Vicente RosselloFriend
Messages: 4
Registered: April 2016
Junior Member
We've been into this problem since the beginning, but it's becoming more and more evident.

We can see that memory is full of eclipselink objects, probably coming from BatchFetchPolicy. The problem is that we are caching entities in memory and storing in the http session entity objects (fetched with a readonly hint, but it's not enough).

A histogram looks like:

num #instances #bytes class name (module)
1: 88265106 2118362544 java.lang.String (java.base@21-ea)
2: 19041274 1827962304 org.eclipse.persistence.internal.identitymaps.WeakCacheKey
3: 42912270 1799083296 [Ljava.lang.Object;
4: 8603249 1450352160 [B
5: 31112410 1244496400 org.eclipse.persistence.internal.indirection.QueryBasedValueHolder
6: 13003414 832218496 org.eclipse.persistence.indirection.IndirectList
7: 20557624 657843968 java.util.concurrent.ConcurrentHashMap$Node
8: 39143214 626291424 java.util.concurrent.atomic.AtomicInteger
9: 19217737 614967584 java.lang.ref.WeakReference
10: 10002283 480109584 org.eclipse.persistence.internal.sessions.ArrayRecord
11: 12457027 398624864 com.tr2.model.Money
12: 16600842 398420208 java.util.ArrayList
13: 9237670 295605440 java.util.Hashtable$Entry
14: 11740845 281780280 java.time.LocalDate
15: 11311805 271483320 java.lang.Double
16: 502813 258635720 [Ljava.util.concurrent.ConcurrentHashMap$Node;
17: 10633379 255201096 org.eclipse.persistence.indirection.ValueHolder
18: 15550256 248804096 java.lang.Integer
19: 6530959 208990688 java.util.HashMap$Node
20: 1995111 207491544
21: 3221828 180422368 org.eclipse.persistence.internal.indirection.BatchValueHolder
22: 2206486 175504232 [Ljava.util.HashMap$Node;
23: 7199154 172779696 java.time.LocalDateTime
24: 6979931 167518344 java.lang.Long
25: 6805261 163326264 org.eclipse.persistence.internal.identitymaps.CacheId
26: 6633824 159211776 java.time.LocalTime
27: 2184947 157316184 org.eclipse.persistence.indirection.IndirectMap
28: 3102541 154098608 [Ljava.util.Hashtable$Entry;
29: 6241238 149789712 javax.xml.namespace.QName
30: 3084274 148045152 java.util.HashMap
31: 2868415 137683920 com.tr2.model.FacilityI18N
32: 980320 117638400 com.tr2.entity.Payment
33: 347870 117518920 Ljdk.internal.vm.FillerArray;
34: 2335156 112087488 org.eclipse.persistence.indirection.IndirectSet

I can't rework at this point the whole application and only work with DTO objects. I need help on how can we alliviate the situation. We don't work with a L2 cache, just the L1 and we work with short lived entity managers (we are using Tomee aplication server).

We would be happy to pay for professional support coming from someone that can provide tips or steps on how to mitigate a bit the situation (a rewrite or move everything to DTO's is not an option).

Re: Memory comsumption with eclipselink (2.7) [message #1860151 is a reply to message #1860101] Wed, 19 July 2023 17:01 Go to previous message
Chris Delahunt is currently offline Chris DelahuntFriend
Messages: 43
Registered: December 2021
From the numbers, you've got a lot of objects referencing other objects (2184947 IndirectMaps, 2335156 Indirectsets, 13003414 IndirectLists). Those are quite a few 1:M and M:M relationships that are likely sitting around in your cached objects eating up space unnecessarily long, with your cached object references preventing garbage collection from occurring on ElipseLink's cache references to those same objects - java.lang.ref.WeakReference and org.eclipse.persistence.internal.identitymaps.WeakCacheKey are in your top 10 for size and number of objects which are directly tied to the identity strategy used in the server session cache (l2). This might appear to be high (and it is), but is likely saving your application from other issues and resource problems that would occur depending on how you have setup your own cache - If you have a large number of M:M relationships for instance, the L2 cache is reducing the number of instances in your application. Ie if Employee1 and Employee2 share Project1 and Project2, and you cache Employee1 and Employee2 - without an identity map, they would hold different instances of Project1 and Project2.

IMO you are better off not having your own internal caching strategy and just doing a find by ID type query when needed. This will use the L2/L1 cache when it is there, and go to the DB when it is not. GC then can clear out unused references when no longer in the app when they go out of the EclipseLink cache (weak references are used for identity so that they are not GC'd, even if out of the cache, while the app is still using them).

Details are in, but if you trust your own caching is all that is needed, you can disable the L2 cache and identity map using the No Identity Map setting, or via JPA settings as described here . This really should be carefully used though, as without DTOs ensuring what is fetched is isolated and complete, your read-only settings and A->B->A' references may cause duplicate A instances to be built and held in your cache (since circular references won't have cache/identity maps available to resolve them, they will be fetched from the DB when accessed).

Best Regards,

Previous Topic:refreshIdentityMapResult - refresh cache only when new version
Next Topic:DatabaseException is always logged to server.log
Goto Forum:

Current Time: Fri Dec 01 14:20:06 GMT 2023

Powered by FUDForum. Page generated in 0.02657 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top