jabref icon indicating copy to clipboard operation
jabref copied to clipboard

v5.2 High RAM utilisation followed with high CPU use when field formaters and autosave are enabled

Open alfureu opened this issue 4 years ago • 9 comments

JabRef 5.2--2020-12-24--6a2a512 Windows 10 10.0 amd64 Java 14.0.2

  • [ ] Mandatory: I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

I accidentally left open JabRef with 2 files open over the weekend. When I got back to the computer on Monday I noticed that JabRef uses 8GB out of 32GB RAM, and every 2-3 minutes the CPU bursts into 100% use making even the basic music listening to stutter. For the record, the CPU is an i7-7700HQ, so not that weak. I think this is something the devs should look into, especially the RAM use, as I believe the CPU use is just the consequence of it. I believe it should not happen with a stable version of the app.

Steps to reproduce the behavior:

  1. Turn on JabRef
  2. Leave it open for longer period of time
  3. Observe an ever-increasing RAM use

alfureu avatar Mar 22 '21 11:03 alfureu

After 24h of having the JabRef open, with occasional spies to 80% CPU...

image

alfureu avatar Mar 26 '21 06:03 alfureu

Do you observe the same with the current development version?

Siedlerchr avatar Mar 26 '21 07:03 Siedlerchr

testing... give me a couple of days pls

alfureu avatar Mar 27 '21 11:03 alfureu

Well, just started the developmental version

JabRef 5.3--2021-03-26--badffe9 Windows 10 10.0 amd64 Java 14.0.2 JavaFX 16+8

and what is immediately noticeable is that it is much more memory hungry, see below:

image

Starting the stable v5.2 stable version it started around ~300MB of RAM, the developmental version starts outright at ~1.2GB. I will keep testing further on...

alfureu avatar Mar 27 '21 11:03 alfureu

I can confirm now that after approx. 24h of running JabRef 5.3--2021-03-26-badffe9 the RAM use is very high:

image

As you can see, as a result of this there is a considerable higher CPU use as well. Please note I am not running any tasks on JabRef, I basically just opened the app and kept it open for 24 hours with three .bib files open.

alfureu avatar Mar 28 '21 08:03 alfureu

I think I was able to identify the culprit. On one of the .bib files the Field Formatters were set to enabled. As soon as I disabled it, after 24+h the RAM use remained ~700MB. I think it is therefore related to issue #7265

What is happening, as far as I can identify, is that as soon as Field Formatters are turned on a .bak file is created, and somehow the autosave option keeps ramping up the RAM usage over longer period of time, no idea why. Maybe this will be helpful for further investigation if anybody runs into similar issues.

alfureu avatar Apr 03 '21 20:04 alfureu

Thanks, we are currently in the progress of fixing issues with the save and autosave options, will keep an eye on it

Siedlerchr avatar Apr 03 '21 20:04 Siedlerchr

meta-issue: #8906

ThiloteE avatar Jun 17 '22 16:06 ThiloteE

To do:

  • [ ] test with commit 6a7139566b555903daafa2913d10431a5f02d704,
    • there was a bug in "save" that had the potential to change the database --> if so, then field formatters could potentially have been triggered to re-format the new changed database --> then again, autosave could potentially have triggered upon changes of the field formatters --> never-ending loop that leads to high cpu/ram
    • This commit also introduced pauses of 31 seconds between autosaves. Now, field formatters should hopefully have the time to finish, before the autosave kicks in, which theoretically would decrease peak cpu/ram load https://github.com/JabRef/jabref/blob/6a7139566b555903daafa2913d10431a5f02d704/src/main/java/org/jabref/logic/autosaveandbackup/AutosaveManager.java#L27

ThiloteE avatar Aug 17 '22 08:08 ThiloteE