@Transactional annotation lead to a huge memory allocation during creation String representation of Method uses for logging only [SPR-16492] #21035
Labels
in: data
Issues in data modules (jdbc, orm, oxm, tx)
status: duplicate
A duplicate of another issue
type: enhancement
A general enhancement
Alexander Fedorov opened SPR-16492 and commented
Hello Team,
we have faced a very intensive CPU consuming. One of the reason is very high GC activity.
GC activity could be splitted into two points:
Minor GC could be tuned with help of investigating of memory allocation events inside new TLAB.
Major GC could be tuned with help of investigating of memory allocation events outside TLAB.
We use JMC and JFR API for aggregating memory allocation events.
It looks like
Memory allocation events inside new TLAB
!allocation_inside_TLAB.jpg|thumbnail!
Memory allocation events outside TLAB
!allocation_outside_TLAB.jpg|thumbnail!
Where higlighted categories are:
Hotspots looks like:
!allocation_inside_TLAB_hotspots2.jpg|thumbnail!
Reg. to transaction we have same bad code that designed for logging that will never used:
Simplest way is reimplement with wrapping into if (logger.isDebugEnabled()) { all code lines that related to created java objects ( including string ) for logging.
Attached my version of [^TransactionAspectSupport.java]
Main changes are:
I will pull request little bit later.
in progress..
Affects: 4.3.14
Attachments:
Issue Links:
@Cacheable
annotation lead to a huge memory allocation from the side of OperationCache equals/hashCodeThe text was updated successfully, but these errors were encountered: