|
| Re: Memory comsumption with eclipselink (2.7) [message #1860151 is a reply to message #1860101] |
Wed, 19 July 2023 17:01  |
 Chris Delahunt
Messages: 54
Registered: December 2021 |
Member |
|
|
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 https://wiki.eclipse.org/Introduction_to_Cache_(ELUG), 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 https://wiki.eclipse.org/EclipseLink/FAQ/How_to_disable_the_shared_cache%3F . 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,
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.02730 seconds
] 
Search
Help
Register
Login
Home
