kitodo / kitodo-production

Kitodo.Production is a workflow management tool for mass digitization and is part of the Kitodo Digital Library Suite.
http://www.kitodo.org/software/kitodoproduction/
GNU General Public License v3.0
62 stars 63 forks source link

Memory leak if working status of multiple processes is changed #4571

Open m-kotzyba opened 3 years ago

m-kotzyba commented 3 years ago

Selecting multiple processes and changing their status (via "Mögliche Aktionen" --> "Bearbeitungsstatus runtersetzen") allocates a lot of memory over time and do not deallocates it in the end:

Before: 001

Afterwards: 002

Scenario context: During Migration (Kitodo 2.X --> 3.3) and the included generation of "Übergeordnete Vorgänge", several "Übergeordnete Vorgänge" have processes which are all finished. To trigger the status finished also for these "Übergeordnete Vorgänge", the status of at least one of its "untergeordnete Vorgänge" has to set down and up afterwards. While this issue is solved in Kitodo 3.3.1, the memory leak still exists.

matthias-ronge commented 3 years ago

Thanks for reporting an apparent memory leak. That is something we should investigate. However, higher-level processes should actually have no tasks at all, so this also shows that something is going wrong during the process migration (see #3307). I want to suggest that this issue focus on the memory leak.

I suspect that the large amount of memory is acquired by Hibernate, as it loads objects dynamically (so-called lazy loading). The objects are loaded the first time they are accessed (here all processes with all their tasks) but are not automatically removed from memory when they are no longer used. There is a question and answer on StackOverflow. But that's only a guess so far.

matthias-ronge commented 1 year ago

After looking on this from the distance, I don’t think this is a memory leak. Java does allocate memory, as long as the limit (-Xmx) isn’t yet reached. If the limit is reached, the garbage collector is run, to remove no longer used objects from memory, but the memory is not compacted or freed again. It will remain occupied as long as the JVM lives. This is the default behaviour of Java. The JVM will then use the free parts of the memory to create objects again, until it is full, then run the garbage collection again, and so on.

If there was a memory leak, doing this operation again and again would lead to an out of memory error. But I did never hear that this happened to anybody, so we can quite safely assume that there is no memory leak.

m-kotzyba commented 1 year ago

You are right, I indeed never experienced a classic "out of memory error" and hence, it may not be a memory leak. However, as far as I remember, when the majority of the memory was occupied by the system, the task to "change the status of multiple processes" took very long and I had to restart the system in the meantime.