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

Server constantly eats 30% of cpu core #42

Open
p-pavel opened this issue Mar 30, 2021 · 10 comments
Open

Server constantly eats 30% of cpu core #42

p-pavel opened this issue Mar 30, 2021 · 10 comments

Comments

@p-pavel
Copy link

p-pavel commented Mar 30, 2021

macOS/MMA 12.2/12.3pre, VSCode. 'development' branch.

This behaviour persist even when VSCode is not visible and nothing happens.

Any hints on how to diagnose this further are welcome.

@kenkangxgwe
Copy link
Owner

VSCode is not visible and nothing happens

Could you explain why is VSCode not visible? Did you install the vscode extension?

@p-pavel
Copy link
Author

p-pavel commented Mar 30, 2021

VSCode is not visible and nothing happens

Could you explain why is VSCode not visible? Did you install the vscode extension?

I meant I minimised it to make sure there's no user (mine) activity so the server should probably be idle.

@kenkangxgwe
Copy link
Owner

image

I am not sure how you can monitor the sub-processes on Mac, but could you confirm that it is the wolfram kernel (highlighted in the above screenshot) that consumes 30% CPU, or the other sub-processes of VSCode?

@p-pavel
Copy link
Author

p-pavel commented Mar 30, 2021

image

@p-pavel
Copy link
Author

p-pavel commented Mar 30, 2021

This is the WolframKernel started by VSCode extension and running lsp

@kenkangxgwe
Copy link
Owner

Did you start the wolfram executable from some place liek /Applications/Mathematica.app/Contents/MacOS/wolfram? Just wonder why it is shown as WolframKernel instead, but that may not related to the issue.

Again, after a short while of high CPU usage, could you attach the wlserver.log? That will help the investigation. Thanks

@p-pavel
Copy link
Author

p-pavel commented Mar 30, 2021

Did you start the wolfram executable from some place liek /Applications/Mathematica.app/Contents/MacOS/wolfram? Just wonder why it is shown as WolframKernel instead, but that may not related to the issue.

every executable of this kind (wolfram/wolframscript) ends up running WolframKernel under macOS, they're just a thin wrappers. In this case wolfram executable was started.

Again, after a short while of high CPU usage, could you attach the wlserver.log? That will help the investigation. Thanks
Currently I have two of them after closing and reopening VSCode :)

image

Log file attached but it does not seem very informative

wlserver.log

@p-pavel
Copy link
Author

p-pavel commented Mar 30, 2021

image

I am not sure how you can monitor the sub-processes on Mac, but could you confirm that it is the wolfram kernel (highlighted in the above screenshot) that consumes 30% CPU, or the other sub-processes of VSCode?

Looking at your screenshot I suppose the problem is macOS specific (didn't have a change to check under Linux yet). So I'll probably try to investigate it more thoroughly.

@VasilySotnikov
Copy link

I think it would be useful to add here that I can confirm similar behaviour on Linux distributions Ubuntu 20.04 and openSUSE Tumbleweed.

In fact, I am using lsp-wl not with VSCode, but with vim through coc-lsp-wl interface. The process

WolframKernel -script <..>/init.wls <...>

always takes up to 30-40% of a CPU while vim is idle, and this also happens even with vim in terminal (without graphical interface). Most of the time this process even stays running when I close vim and it continues to take up similar CPU load until I kill it manually, but this is likely an unrelated problem.

@newptcai
Copy link

newptcai commented Apr 6, 2021

@VasilySotnikov Same problem here. Have to kill the server manually each time.

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

4 participants