lsp-mode内存占用问题

yyjjl · 2021 年8 月 28 日 06:03

似乎有人找到了 lsp-mode 的一个 memory leak 问题的原因： response-handlers 一直没有清理

github.com/emacs-lsp/lsp-mode

Memory leak in lsp-client response-handlers

opened 03:32PM - 26 Aug 21 UTC

closed 11:14AM - 04 Sep 21 UTC

blahgeek

bug performance core

## Thank you for the bug report - [X] I am using the latest version of `lsp-m…ode` related packages. - [X] I checked [FAQ](https://emacs-lsp.github.io/lsp-mode/page/faq/) and [Troubleshooting](https://emacs-lsp.github.io/lsp-mode/page/troubleshooting/) sections - [x] You may also try reproduce the issue using clean environment using the following command ```bash emacs -q -l lsp-start-plain.el ``` where `lsp-start-plain.el` can be downloaded [here](https://github.com/emacs-lsp/lsp-mode/blob/master/scripts/lsp-start-plain.el). ## Bug description ### The problem This "memory leak" issue has been brought up several times in various places: - https://github.com/emacs-lsp/lsp-mode/issues/772 - https://github.com/emacs-lsp/lsp-mode/issues/2944 - https://www.reddit.com/r/emacs/comments/olqeok/high_memory_usage_caused_by_lsp_completions/ I have the exact same issue: if I use lsp-mode for some long time (e.g. one day), emacs can use a lot of memory (>1GB). This can be confirmed in `memory-report` ("Overall Object Memory Usage"), or system monitoring tools like `top`. The most annoying part about the memory leak is not about memory usage itself (I have a 32GB RAM laptop and I can spare 1GB or 2), but it will greatly affect the GC pause time (`gabarge-collect` can easily take >1 second)), which affects the overall responsiveness (which, I suspect, is the root cause of many complains about "lsp-mode is slow but I cannot reproduce with lsp-start-plain"). Also, I don't use `gcmh-mode` ### Possible cause I think I may have identified the cause of this memory leak issue: it's in the `response-handlers` of `lsp-client`. Over time, lots of response handlers are left here forever, even if they should be timed-out. Response handlers are closures, each closure need to reference all the lexical-local variables when it's created, so it takes a lot of memory. (I identified this by adding some logging during GC in the `alloc.c` source code. `memory-report` was not able to identify this in "Largest Variables" *(Update: this is fixed in emacs master https://github.com/emacs-mirror/emacs/commit/d8d5dc45656233fdccc3709093a16e2562cd4a40)*.) To confirm this, I added the following code to clear response handlers that is already timed-out. I now have been using lsp-mode as before for several days and I don't see memory increase anymore (and I can see the "Deleting handlers in lsp-client" message frequently). ```elisp (defun my/lsp-client-clear-leak-handlers (lsp-client) "Clear leaking handlers in LSP-CLIENT." (let ((response-handlers (lsp--client-response-handlers lsp-client)) to-delete-keys) (maphash (lambda (key value) (when (> (time-convert (time-since (nth 3 value)) 'integer) (* 2 lsp-response-timeout)) (push key to-delete-keys))) response-handlers) (when to-delete-keys (message "Deleting %d handlers in %s lsp-client..." (length to-delete-keys) (lsp--client-server-id lsp-client)) (mapc (lambda (k) (remhash k response-handlers)) to-delete-keys)))) (defun my/lsp-clear-leak () "Clear all leaks" (maphash (lambda (_ client) (my/lsp-client-clear-leak-handlers client)) lsp-clients)) (setq my/lsp-clear-leak-timer (run-with-timer 5 5 #'my/lsp-clear-leak)) ``` ### Proposed actions I'm not familiar with the code, but maybe we should not rely on callers to cancel the request? Perhaps, we can always remove the response handler once the timeout is reached. ## Steps to reproduce I didn't try to reproduce this with `lsp-start-plain.el` because it requires long time of regular usage. But I think I have already identified the issue. ## Expected behavior No memory leak. ## Which Language Server did you use? clangd, pyls ## OS Linux ## Error callstack _No response_ ## Anything else? _No response_