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

Performance issues with owl tools #57

Open
3 tasks
dwagmuse opened this issue Aug 22, 2024 · 2 comments
Open
3 tasks

Performance issues with owl tools #57

dwagmuse opened this issue Aug 22, 2024 · 2 comments

Comments

@dwagmuse
Copy link
Contributor

Description

Running workflow with a relatively large model seems to take a rather long time in owl load and some tasks do not appear to release memory after they complete.

We have a workflow for a model that, when converted to owl, is about 300MB of owl text. I'm able to run the workflow in a container to monitor performance. It took about 1.25 hours to run as shown in this chart.

Screenshot 2024-08-21 at 8 27 37 PM

In addition to the fact that owl-load seems to take nearly 300% cpu and runs for 50 minutes I also note that the reasoning step did not appear to release any memory when it finished -- memory consumption just kept going up. In this case everything functioned as intended but seemed to consume more time and memory than seems necessary. The largest memory growth occurred during the reasoning step (not surprising) but was not released when that task finished (unexpected, since the task is done).

In this workflow the steps prior to reasoning (e.g., oml2owl) are using earlier versions that run as JavaExec tasks in gradle rather than as gradle plugins. That may explain why those earlier steps do appear to release memory.

Steps to Reproduce

Steps to reproduce the behavior:

  • Step 1
  • Step 2
  • Step 3

Expected Behavior

It should not take that long to load the database and we should be able to recover memory from finished gradle tasks.

Additional Context

Enter any other details such as dependencies, environment, examples, etc.

Relevant screenshots

If applicable, add screenshots to help illustrate the issue.

@dwagmuse
Copy link
Contributor Author

A quick google search suggests that the memory leak issue is not unique to opencaesar. This issue notes that memory consumption has been an issue in gradle since 7.6 and may be improved in 8.3. However, it may also have something to do with how large objects are saved/referenced in plugins after then finish but are still in gradle memory.

@dwagmuse
Copy link
Contributor Author

dwagmuse commented Aug 22, 2024

Tried upgrading to gradle 8.10 and that does not seem to make much difference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant