bug #7900
closedExcessive heap consuption in RegistrationWorkingsetEditor with big workingsets
100%
Description
Adding a new name to the registration workingset Kulikovskiy, M., Lange-Bertalot, H., Metzeltin, D. & al. - Lake Baikal: Hotspot of endemic diatoms I. in Taxonomy - biogeography - diversity. 23. (http://api.cybertaxonomy.org/phycobank/app/registration#!workingset/5d29277e-a527-4a26-8685-1a7a6cb2e3de) fails on the production server due to excessive heap consumption after pressing the save button in the name editor.
The problem happens after the name is saved during the reloading of the workingset:
A differential comparison of the heap before and during the reloading of the workingset shows that especially the amount Team
objects is increasing excessively.
1 minute after saving +25.000 Team objects
3 minutes after saving +109.000 Team objects
Comparing the objects in memory from 3 minutes and 1 minute after saving reveals that only the amount of Team objects is increasing that much!
The allocation analysis shows that all Team
Objects have been created in the call to the RegistrationWorkinsetService
There are 423 Teams in the database but in the test above more than 100.000 Team objects have been created evene after 3 minutes.
Files
Related issues
Updated by Andreas Kohlbecker about 4 years ago
- File mem-diff-2.png mem-diff-2.png added
Updated by Andreas Kohlbecker about 4 years ago
- File mem-diff-1.png mem-diff-1.png added
- Description updated (diff)
Updated by Andreas Kohlbecker about 4 years ago
- File mem-diff-1-2.png mem-diff-1-2.png added
Updated by Andreas Kohlbecker about 4 years ago
- File Allocations-of-Teams.png Allocations-of-Teams.png added
- Description updated (diff)
Updated by Andreas Kohlbecker about 4 years ago
- File mem-getCollectorAndFieldNumber.png mem-getCollectorAndFieldNumber.png added
- File mem-getCollectorAndFieldNumberXX.png mem-getCollectorAndFieldNumberXX.png added
It seems as if the DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber()
is causing the massive memory usage. In this method new Team
instances are created. Replacing this method by a empy implementation which only returns an empty string solves at least the memory issue:
In contrast to the above graph the getCollectorAndFieldNumber()
will create a massive load of Teams which can not be garbage collected:
Updated by Andreas Kohlbecker about 4 years ago
- % Done changed from 0 to 20
The root cause for the problem is the RegistrationWorkingsetPresenter.onDoneWithTaxonnameEditor()
method in which a write enabled transaction is committed at the wrong time. The commit takes place after reloading the registration workingset which causes the whole workingset to be reloaded in the writable transaction since the RegistrationWorkingSetService
misses the transaction propagation type being set to Propagation.REQUIRES_NEW
in @Transactional(readOnly=true)
. With REQUIRES_NEW
a new read-only transaction would be created even if the service is called in a writable transaction.
Despite having pinned down the root cause to these two findings it is still quite irritating that the DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber()
can impose such a massive load on the heap even if it is only returning plain strings.
Updated by Andreas Kohlbecker about 4 years ago
- Status changed from New to Resolved
Updated by Andreas Kohlbecker about 4 years ago
- Copied to bug #7904: DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber() creates temporary Team objects which can not be garbage collected. added
Updated by Andreas Kohlbecker about 4 years ago
The DerivedUnitFacadeFieldUnitCacheStrategy.getCollectorAndFieldNumber()
is actually the root cause for the massive memory allocation as pointed out in #7904
Updated by Andreas Kohlbecker about 4 years ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100
the symptom as described in this issue is no longer reproducible.