Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Postgre daemon uses 100% of CPU for several minutes despite indexing deactivated #12190

Open
2 tasks done
ytzemih opened this issue Nov 14, 2024 · 2 comments
Open
2 tasks done
Labels
Milestone

Comments

@ytzemih
Copy link

ytzemih commented Nov 14, 2024

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
Copy link
Author

ytzemih commented Nov 14, 2024

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 [email protected]/org.postgresql.jdbc.PgConnection.checkClosed(Unknown Source)
	at [email protected]/org.postgresql.jdbc.PgConnection.prepareStatement(Unknown Source)
	at [email protected]/org.postgresql.jdbc.PgConnection.prepareStatement(Unknown Source)
	at [email protected]/org.jabref.logic.search.retrieval.BibFieldsSearcher.search(Unknown Source)
	at [email protected]/org.jabref.logic.search.retrieval.BibFieldsSearcher.isMatched(Unknown Source)
	at [email protected]/org.jabref.logic.search.IndexManager.isEntryMatched(Unknown Source)
	at [email protected]/org.jabref.gui.groups.GroupNodeViewModel$SearchIndexListener.lambda$listen$1(Unknown Source)
	at [email protected]/org.jabref.logic.util.BackgroundTask$2.call(Unknown Source)
	at [email protected]/org.jabref.logic.util.BackgroundTask$2.call(Unknown Source)
	at [email protected]/org.jabref.gui.util.UiTaskExecutor$1.call(Unknown Source)
	at [email protected]/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
Copy link
Author

ytzemih commented Nov 14, 2024

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)

@koppor koppor added the search label Nov 14, 2024
@koppor koppor added this to the 6.0-alpha milestone Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants