Postgres daemon uses 100% of CPU for several minutes despite indexing deactivated

[ytzemih]

JabRef version

Latest development branch build (please note build date below)

Operating system

GNU / Linux

Details on version and operating system

JabRef 6.0--2024-11-13--5f1dd59 Linux 6.1.0-26-amd64 amd64 Java 23.0.1 JavaFX 23.0.1+4

Checked with the latest development build (copy version output from About dialog)

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

I can't exactly replicate this issue, it occurs a few times a day. The following steps might increase the likelihood to stimulate the issue:

1. I've generally deactivated "fulltext search" or background features in the preference pane.
2. Use (global) search and leave search term in the search field (might be an optional step).
3. Add a new entry to a large DB OR edit the comments field and other field of an existing entry.
4. Save file.

I'm using top to see that there is a postgre instance spun off and to check its CPU load. This issue has not occurred under JR5.x.

Appendix

Log File

78754 xxx     25   5  235792  56520  50536 R  99.7   0.4   7:35.39 postgres

[ytzemih]

When killing the postgre instance (needed, otherwise my laptop will die), I'm getting about 10-15 of such exceptions thrown:

2024-11-14 13:47:06 [pool-2-thread-2] org.jabref.logic.search.retrieval.BibFieldsSearcher.search()
ERROR: Error during bib fields search execution: org.postgresql.util.PSQLException: This connection has been closed.
	at org.jabref.merged.module@6.0.6575/org.postgresql.jdbc.PgConnection.checkClosed(Unknown Source)
	at org.jabref.merged.module@6.0.6575/org.postgresql.jdbc.PgConnection.prepareStatement(Unknown Source)
	at org.jabref.merged.module@6.0.6575/org.postgresql.jdbc.PgConnection.prepareStatement(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.logic.search.retrieval.BibFieldsSearcher.search(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.logic.search.retrieval.BibFieldsSearcher.isMatched(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.logic.search.IndexManager.isEntryMatched(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.gui.groups.GroupNodeViewModel$SearchIndexListener.lambda$listen$1(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.logic.util.BackgroundTask$2.call(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.logic.util.BackgroundTask$2.call(Unknown Source)
	at org.jabref@6.0.6575/org.jabref.gui.util.UiTaskExecutor$1.call(Unknown Source)
	at javafx.graphics@23.0.1/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

I don't know why such a comprehensive search is triggered when just editing some entry fields... I've not been using search, but I realise that my global search is non-empty. Apparently, it seems to be the search update is again triggered to often. I realise that there is a related issue with JR5, right?

[ytzemih]

Perhaps it helps to distinguish two search triggers,

1. one when a user requests a search (that should be immediate)
2. one when some update is made in the DB (that should be delayed to a bunch of updates)

[ytzemih]

I'm getting this behaviour quite often. So, just reporting further observations:
There are up to 5 threads pool-2-thread-x with x=1..5. Now, killing postgre immediately throws 100s of these errors within a second:

2024-11-26 17:08:00 [pool-2-thread-5] org.jabref.logic.search.retrieval.BibFieldsSearcher.search()
ERROR: Error during bib fields search execution: org.postgresql.util.PSQLException: This connection has been closed.

Before my CPU kept spinning, which suggests to me a classical DB deadlock situation (spinlocks) created by several (5?) java postgre calls not being synchronized (that is, not being properly monitored). It seems reasonable to start having a look there.

[koppor]

Before my CPU kept spinning, which suggests to me a classical DB deadlock situation (spinlocks) created by several (5?) java postgre calls not being synchronized (that is, not being properly monitored). It seems reasonable to start having a look there.

Can you help us with that? Our contributor developing that feature disappeared.

[ytzemih]

@koppor Sorry to hear that and thanks for asking.

First of all, can you or anybody else confirm that there is a bug?

I'm not familiar with the JR code base, nor it's architecture, which means, it'd take me a while to isolate the problem and make informed decisions. From February onward, however, I'd have time to take have a look into this issue if this helps you?