lsp has gotten very memory hungry lately. Does anyone have any tricks to keep this down?
wow that's quite some memory use. ironically clj-kondo just had some changes where frees all memory after running. Perhaps you can bisect this by using older clojure-lsp commits? running a JVM version also gives you the benefit of doing a heap dump which may reveal something. this is my dev script for running clojure-lsp locally:
#!/usr/bin/env bash
clj -Sdeps '{:aliases
{:lsp
{:replace-paths []
:replace-deps
{org.clojure/clojure {:mvn/version "1.11.1"}
clj-kondo/clj-kondo {:local/root "/Users/borkdude/dev/clj-kondo"}
clojure-lsp/clojure-lsp {:local/root "/Users/borkdude/dev/clojure-lsp/cli"}
cider/cider-nrepl {:mvn/version "0.28.6"}}}}}' \
-M:lsp -m clojure-lsp.main "$@"I see you're already using Yourkit which may help finding the culprit
i restarted the lsp server with m-x lsp-restart-workspace but something must have happened because now i have the dreaded “LSP Sending to process failed with the following error: Process clojure-lsp not running: killed: 9”. And this is an unrecoverable, omnipresent error that never goes away.
emacs uptime: 20 days, 18 hours, 8 minutes, 56 seconds
must be killed because lsp won’t stop logging
locally I'm on commit d679c4d2d8d41b76a3296d89f2e5f66f9f5b84a9 of clojure-lsp (25th of July) and I haven't seen this error. I'm also on the latest clj-kondo (master) locally.
just grabbed fresh and i’ll restart
and?
back down to reasonable numbers. I’ve also not been switching branches as much which is a hypothesis of mine
another data point, also on Metabase like Dan: 10G resident right now. I haven't had to kill it in a while. I have switched branches, but only between a handful of small PRs and the same master commit, so there's little to recompile.
i’ll keep an eye on it and if i see high resource usage i’ll throw yourkit at it
I just synced the latest master and watched clojure-lsp in top.
the pattern is a sawtooth of memory use from a low end about 9500MB to a high end about 17G, using 1 core. then it uses 6 cores and swiftly falls to 9500 again, and repeats until the reprocessing is done (about 1 minute).
after that was done, it stabilized at 9449MB and 0.0% CPU. so it doesn't seem leaky, but the post-GC floor is rather high.
would be nice to check if we can repro that with clj-kondo only, but we will need to pass the same args clojure-lsp pass which affects that (asking for more analysis)
Idea: a comment block that generates the clj-kondo command from clojure-lsp call :)
I often (once every few days) find clojure-lsp taking 100%-900% CPU (and high memory), which continues until I kill/restart VS-Code. E.g. the one running now: ~/.vscode/extensions/betterthantomorrow.calva-2.0.524/clojure-lsp taking RAM: 12g res, 32g virt. Any pointers on debugging this? (Ubuntu 24.04, AMD 3700X, 64GB)
I ran that clojure-lsp --version and found this:
clojure-lsp 2025.08.25-14.21.46
clj-kondo 2025.07.28I haven't seen any excess memory use in a while, but if I do a trivial rebase or switch branches then clojure-lsp will eat all my cpu for 5+ minutes. At the same time there's like a million new lines per second in the clojure-lsp log as it seems to reanalyze and report every single namespace very verbosely. Afterwards it calms down and everything works again, but often it feels faster to just close the workspace and start again. lsp-workspace-restart etc don't work, as the LSP server is too busy to respond. But this has been happening for a month at least so it's not due to the latest changes and optimization in clj-kondo
the latest changes in clj-kondo should help memory problems, not contribute to them :)
@lasse.olavi.maatta I have a similar issue that happens when rebasing or changing branch (since around may/june I think ?). I think it's an :internal/notify-references loop. Right now I've disabled it on my project with {:notify-references-on-file-change false} until I find the root cause. I setup clojure-lsp to debug it this week but haven't found the cause yet.
I suspect the changes of may 16th are somewhat making this issue apparent, I used to have outdated analysis when changing branches and now it's always correct but the analysis takes way too long