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

Memory leak in mk-session #468

Open
zan-xhipe opened this issue Mar 26, 2021 · 1 comment
Open

Memory leak in mk-session #468

zan-xhipe opened this issue Mar 26, 2021 · 1 comment

Comments

@zan-xhipe
Copy link

I think I have found a memory leak in clara when calling mk-session. I have been trying to find a memory leak in one of our services. I eventually found that the leak was from mk-session. This service creates lots of rules dynamically so initially I assumed it was that. I saw the :cache option in mk-session and thought that we were probably caching all those dynamically created rules, however turning off the cache did not help. I eventually created this minimal code to reproduce the leak. With cache false this leaks, with cache true it doesn't, but when adding in dynamically created rules the cache true also leaks, even after calling clear-session-cache!

(ns mem-leak
  (:require [clara.rules :refer [mk-session defquery]]))
(defquery get-status [:?status] [?result <- :status [{status :status}] (= status ?status)])
(defquery get-all-status [] [?result <- :status])
(doseq [i (range 10000)]
    (mk-session 'mem-leak
                :cache false)) 
@k13gomez
Copy link
Contributor

@zan-xhipe if you have cache set to false then the rules will be recompiled every time, compiling rules is a CPU and memory intensive process, so every time you run this piece of code the clojure compiler is evaling the rules provided. The caching strategy used by clara currently is also very simple, it simply holds an atom with a map of productions to session, I highly recommend wrapping your own caching strategy in front of this if you want to have better control over it. The root of your problem in particular may be that your service creates rules dynamically so the productions are different every time you call mk-session, so having your own caching strategy in front of it to determine if you can re-use the session may be your only solution.

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

2 participants