Closed D3SL closed 2 years ago
Would you like to try with the latest development version of languageserver and see if the problem still persists?
the R package or the vscode extension?
I've got it installed, it may be a bit before I know if it's working or not given there doesn't seem to be any consistent way to provoke the issue.
Actually that was faster than I thought. I don't get the constant error messages now but whatever is causing an extreme runaway spawning of processes is even worse than before, I've got something like 3 full double-screens worth of these processes and sometimes they wind up taking up almost all free resources.
Looks like it might be caused by the session pool? @randy3k @qinwf any idea why this could happen?
In case it's relevant I do often have more than one VSCode window open, often with one of them SSHed into a remote machine, and generally just close my laptop to put it to sleep rather than save and shut down everything. Are there any further logs or dumps I can provide, or any test I can run for you?
I'm having the same problem, both in Windows and when using SSH to access a Linux server.
@D3SL @arnoudplantinga
Could you share the answers to the following questions?
R_LANGSVR_POOL_SIZE=0
in your ~/.Renviron
so that the session pools are disabled?R For Windows front-end
processes and 7 R For Windows terminal front-end
the instant I create an R terminalVery late update but this appears to still be thing. I opened VSCode momentarily just to try this and instantly had 4 "R for Windows Front-end" processes and 8 "R for Windows Terminal Front-End" processes just from having a single R script open and R session created.
It's unfortunate because unlike the slower object or plot rendering and windows bracketed paste issue this is an actual showstopper, it eventually winds up eating all available ram and then I'm forced to kill the language server's processes.
@D3SL Is it still eating all the memory if you put R_LANGSVR_POOL_SIZE=0
in your ~/.Renviron
so that the session pools are disabled?
@randy3k I think we need to minimize the session pool if the machine does not meet a certain condition, e.g. at least 8 CPUs and 32GB RAM?
Assuming it's using the .Renviron in Documents, which path.expand('~')
says is my home folder, yes I put that in when you first suggested it last year. On the upside, it seems like those processes are actually cleaned up on closing VSCode now so I don't wind up with 200 of them like before. EDIT: One thing that is different, opening a single file can sometimes open just VSCode without all of the "console window host" and R for Windows/Windows Terminal front-end processes.
I'm not sure if they'll still grow out of control over time, I can go back to VSC instead of RStudio for a few dev sessions and see if it just stays parked at about this level of memory usage.
~/.Renviron
in Windows should mean C:\\Users\\user\\Documents\\.Renviron
. You could try file.edit("~/.Renviron")
in R.
If R_LANGSVR_POOL_SIZE=0
is properly specified, then a vscode instance with a R workspace folder open will only spawn two R processes that are constantly running in background, one for languageserver, and the other for R help server. The languageserver will spawn at most two more child processes as you open or change a document but will terminate once the task is done.
Yep, that's it alright. It's definitely the language server, disabling that gets rid of all the extra processes and halves memory usage. With only a single folder and ~20 line script open VSC sits at under 500mb total with the language server disabled, about 50mb specifically noted for "R for Windows terminal front-end". Enabling the language server and reloading the window results in memory usage ballooning to a whopping 1.3 gigabytes with many extra processes of each kind.
Disabling all of my other extensions doesn't make a difference.
Language server disabled, or enabled but before opening any R scripts:
Language server enabled and a single script open:
And in case it helps I turned on diagnostics for the language server, did the same thing, and here's the output with anything private removed:
@D3SL In your languageserver log, I don't find R_LANGSVR_POOL_SIZE=0
in the env. Looks like it does not take effect?
It's definitely there, I even used file.edit("~/.Renviron")
to doublecheck I had the right file in the right place. Could this be a leftover from a very old initial setup or caused by something else somewhere else?
@randy3k I think we need to minimize the session pool if the machine does not meet a certain condition, e.g. at least 8 CPUs and 32GB RAM?
I think it is reasonable. On top of it, with the default settings, we always create 6 worker R sessions (3 for linting and 3 for parsing). Except in the initialization step, only one worker is running a task and the others are idle at most of the time,. I wonder if we could close some sessions after the initialization step.
So I'm probably showing my ignorance here asking this, but why doesn't RStudio have this same level of memory usage? It does linting, code completion, and so on as well but the equivalent session to the screenshots I provided here used maybe 600mb as opposed to 1.3-1.5gb.
Likewise, I have posted this in https://github.com/REditorSupport/vscode-R/issues/735, which is similar to this thread, but I don't know whether the both are the same. It seems my problem is more likely to be related to this thread. vscode-r
never terminate the R front-end
, so when we restart vscode multiple times, the R for Windows front-end
accumulates gradually.
My running environment:
Windows 10 20H2-19042.1415
Version: 1.63.2 (user setup)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:40:02.816Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.190420.5.13
4.1.1
0.3.12
No
No
false
- in VSCode settings"never"
- in VSCode settingswhen I seted R_LANGSVR_POOL_SIZE = 0
in my ~/.Renviron
and opened a vscode instance (never opened any files), then quit vscode, these process remained runing:
when I seted R_LANGSVR_POOL_SIZE = 1
in my ~/.Renviron
and opened a vscode instance (never opened any files), then quit vscode, these process remained runing:
when I reopen vscode several times, the process R for Windows front-end
in vscode
will accumulate:
This shouldn't be caused by radian
, I have run radian
alone with R
in windows cmd.exe
, which didn't present above results.
This may not be the problem of language server
, I think it's the responsibility of vscode-r
extension, which created this sub-process, to kill this process when exit?
Let me see if I can reproduce it in a Windows environment first.
Thanks for your reply @renkun-ken. Are there any procedures or tests I can help?
I’m not familiar with the vscode extension but just can write some r code.
Resolved with https://github.com/REditorSupport/vscode-R/pull/941
After giving this a bit of use it looks like this is resolved for me too. A reasonable number of processes are spawned up front and they actually close on their own now. Being able to use VSCode instead of RStudio is a big quality of life improvement, to say nothing of the competition to the RStudio monopoly being vital for the R ecosystem's health.
Unfortunately I spoke too soon, it looks like I'm either still having this issue or it's recurred. I noticed VSCode chugging today and found out ~70% of my ram was being used up by the language server processes. Unticking LSP in settings seems to fix it.
Hi, Maybe you can try to set environment variable R_LANGSVR_POOL_SIZE
in your ~/.Renviron
to limit the languageserver process, as indicated by renkun-ken.
~/.Renviron
in Windows should meanC:\\Users\\user\\Documents\\.Renviron
. You could tryfile.edit("~/.Renviron")
in R.If
R_LANGSVR_POOL_SIZE=0
is properly specified, then a vscode instance with a R workspace folder open will only spawn two R processes that are constantly running in background, one for languageserver, and the other for R help server. The languageserver will spawn at most two more child processes as you open or change a document but will terminate once the task is done.
As noted in this comment I've tried that without success unfortunately.
Hi, Maybe you can try to set environment variable
R_LANGSVR_POOL_SIZE
in your~/.Renviron
to limit the languageserver process, as indicated by renkun-ken.
~/.Renviron
in Windows should meanC:\\Users\\user\\Documents\\.Renviron
. You could tryfile.edit("~/.Renviron")
in R. IfR_LANGSVR_POOL_SIZE=0
is properly specified, then a vscode instance with a R workspace folder open will only spawn two R processes that are constantly running in background, one for languageserver, and the other for R help server. The languageserver will spawn at most two more child processes as you open or change a document but will terminate once the task is done.
Sometime in the last two weeks I started getting the error
Connection to server is erroring. Shutting down server.
in VSCode's output window with varying frequency during coding sessions. Today while during a lag spike I took a look at the task manager and saw about 20 R terminal front-end processes each taking nearly 100mb of ram. When I killed each process I got an error in VSCode like this one:I'm on Windows 10, using the latest versions of VSCode and the LSP extension, R 4.0.2, and languageserver 0.3.6