search

josa42 / coc-sh

SH language server extension using bash-language-server for coc.nvim.
MIT License
205 stars 4 forks source link

High CPU usage #53

Closed hejops closed 2 years ago

hejops commented 3 years ago

On one of my machines, this extension causes my CPU usage to spike to 100% or more. It works normally otherwise (with coc-diagnostic). Other extensions like coc-pyright don't produce any CPU spikes.

user    139508  0.1  0.1 642932 61208 ?        Ssl  17:31   0:01 node --no-warnings /home/user/.vim/plugged/coc.nvim/build/index.js
user    142976  0.1  0.1 642016 64084 ?        Ssl  17:40   0:01 node --no-warnings /home/user/.vim/plugged/coc.nvim/build/index.js
user    143020  0.0  0.1 586480 43876 ?        Sl   17:40   0:00 /usr/bin/node /home/user/.config/coc/extensions/node_modules/coc-diagnostic/out/server --node-ipc --clientProcessId=142976
user    148178  113 13.4 14085084 4412416 ?    Rl   17:57   0:56 node /home/user/.config/coc/extensions/node_modules/coc-sh/node_modules/bash-language-server/bin/main.js start

## versions

vim version: VIM - Vi IMproved 8.1 8012269
node version: v15.11.0
coc.nvim version: 0.0.80-98a0c6db19
coc.nvim directory: /home/user/.vim/plugged/coc.nvim
term: dumb
platform: linux

## Log of coc.nvim

2021-03-15T11:30:43.303 INFO (pid:1464362) [services] - registered service "diagnostic-languageserver"
2021-03-15T11:30:43.304 INFO (pid:1464362) [services] - diagnostic language service state change: stopped => starting
2021-03-15T11:30:43.446 INFO (pid:1464362) [language-client-index] - diagnostic-languageserver started with 1464650
2021-03-15T11:30:43.453 INFO (pid:1464362) [services] - registered service "sh"
2021-03-15T11:30:43.453 INFO (pid:1464362) [services] - bash-language-server state change: stopped => starting
2021-03-15T11:30:43.457 INFO (pid:1464362) [plugin] - coc.nvim 0.0.80-98a0c6db19 initialized with node: v15.11.0 after 241ms
2021-03-15T11:30:43.461 INFO (pid:1464362) [language-client-index] - Language server "sh" started with 1464665
2021-03-15T11:30:43.543 INFO (pid:1464362) [services] - diagnostic language service state change: starting => running
2021-03-15T11:30:43.545 INFO (pid:1464362) [services] - service diagnostic-languageserver started
2021-03-15T11:30:45.950 INFO (pid:1464362) [attach] - receive notification: highlight []
2021-03-15T11:30:53.686 INFO (pid:1464362) [attach] - receive notification: showInfo []

$ cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

$ uname -r
5.4.0-66-generic
hejops commented 3 years ago

I'm fairly certain this is due to coc-sh (disabling coc-diagnostic did not produce any improvements), and it only happens on my Ubuntu machine (it works normally on Manjaro). I updated the post to add some CocInfo logs, as well as my OS information.

As a workaround, I have the following condition in my .vimrc to disable loading the extension on my affected machine.

let g:coc_global_extensions = [ ... ]
let hostname = substitute(system('hostname'), '\n', '', '')
if hostname != "bad_machine"
    let g:coc_global_extensions += ['coc-sh']
endif
ThomasFaivre commented 3 years ago

I am encountering the same issue on my Debian 10 machine using nvim. But it's not spikes but a constant 100%-200% cpu usage.

:CocInfo

## versions

vim version: NVIM v0.5.0-dev+1166-g070e084a6
node version: v14.16.0
coc.nvim version: 0.0.80-89a2dc8fc8
coc.nvim directory: /home/faivre/configfiles/vim/bundle/coc.nvim
term: xterm-256color
platform: linux

## Log of coc.nvim

2021-04-30T17:27:23.602 INFO (pid:17654) [services] - registered service "diagnostic-languageserver"
2021-04-30T17:27:23.660 INFO (pid:17654) [coc-git] - Looking for git in: git
2021-04-30T17:27:23.675 INFO (pid:17654) [services] - registered service "highlight"
2021-04-30T17:27:23.690 INFO (pid:17654) [plugin] - coc.nvim 0.0.80-89a2dc8fc8 initialized with node: v14.16.0 after 158ms
2021-04-30T17:27:23.694 INFO (pid:17654) [language-client-index] - highlight started with 17669
2021-04-30T17:27:24.069 INFO (pid:17654) [attach] - receive notification: highlight []
2021-04-30T17:27:24.664 INFO (pid:17654) [services] - registered service "pyright"
2021-04-30T17:27:25.541 INFO (pid:17654) [attach] - receive notification: highlight []
2021-04-30T17:27:28.237 INFO (pid:17654) [services] - diagnostic language service state change: stopped => starting
2021-04-30T17:27:28.251 INFO (pid:17654) [language-client-index] - diagnostic-languageserver started with 17771
2021-04-30T17:27:28.254 INFO (pid:17654) [services] - registered service "sh"
2021-04-30T17:27:28.254 INFO (pid:17654) [services] - bash-language-server state change: stopped => starting
2021-04-30T17:27:28.258 INFO (pid:17654) [language-client-index] - Language server "sh" started with 17777
2021-04-30T17:27:28.356 INFO (pid:17654) [services] - diagnostic language service state change: starting => running
2021-04-30T17:27:28.357 INFO (pid:17654) [services] - service diagnostic-languageserver started
2021-04-30T17:27:29.217 INFO (pid:17654) [attach] - receive notification: highlight []
2021-04-30T17:27:41.851 INFO (pid:17654) [attach] - receive notification: highlight []
2021-04-30T17:27:43.907 INFO (pid:17654) [attach] - receive notification: showInfo []

Something is actively polling something. I used strace to do a quick check. I had to remove the futex syscall as it was flooding the logs:

$ strace -p 16421
[...]
futex(0x446c720, FUTEX_WAKE_PRIVATE, 1) = 1
[...]

$ strace -p 16421 -e 'trace=!futex'
[...]
read(16, "\1\0\0\0\0\0\0\0", 1024)      = 8
epoll_wait(13, [{EPOLLIN, {u32=16, u64=16}}], 1024, 0) = 1
read(16, "\1\0\0\0\0\0\0\0", 1024)      = 8
write(1, "Content-Length: 238\r\n\r\n", 23) = 23
write(1, "{\"jsonrpc\":\"2.0\",\"method\":\"windo"..., 238) = 238
epoll_wait(13, [{EPOLLIN, {u32=16, u64=16}}], 1024, 0) = 1
read(16, "\1\0\0\0\0\0\0\0", 1024)      = 8
epoll_wait(13, [{EPOLLIN, {u32=16, u64=16}}], 1024, 0) = 1
oblitum commented 3 years ago

This is probably just a side-effect of scanning your home folder? See https://github.com/josa42/coc-lua/issues/58 and resolution. Core coc.nvim recently changed behavior to fix this, so maybe it's already fixed for bash-language-server.

oblitum commented 3 years ago

As far as I can tell this is finally fixed after https://github.com/neoclide/coc.nvim/commit/39c14a3b888367dcefe9c7808b7a06ffd2452dcf, and I can finally use coc-sh over "raw bash-language-server configuration with a "ignoredRootPaths": ["~"] setting" which would avoid the issue.

ThomasFaivre commented 3 years ago

Indeed. An upgrade of coc.nvim seems to have fixed my issue.

Thanks! And sorry for the noise!