vscode remote 只要一连接服务器，服务器 CPU 负荷瞬间飙升到几乎不能运行
kisshere · 2020-09-18 08:46:01 +08:00 · 6197 次点击这是一个创建于 1525 天前的主题，其中的信息可能已经有所发展或是发生改变。
我就纳闷了一个编辑器去拖累服务器干嘛？？？！！！ vscode remote 连接服务器后，top 命令查看，一个叫“node”的进程 CPU 消耗量瞬间飙升，然后没过几分钟服务器就被这个进程拖垮了，关了 vscode，服务器负荷又正常了，这个怎么破？服务器 centos 系统，未安装 nodeJS
 |
1
wtks1 2020-09-18 08:48:36 +08:00 via Android
服务器的硬件配置太低？
|
 |
2
heyjei 2020-09-18 09:03:27 +08:00
估计是在做索引吧，你服务器上的 vscode 的目录删了让他重新初始化试试看
|
 |
3
LokiSharp 2020-09-18 09:06:06 +08:00
微软 Azure 上 VSCode Online 官方推荐配置我记得是 2C4G 朝上，这玩意就是个鸡肋
|
 |
5
Kilerd 2020-09-18 09:12:11 +08:00
你猜猜 vscode 是用什么写的？
|
 |
7
tfdetang 2020-09-18 09:33:56 +08:00  3
vscode remote 是需要在 remote 服务器装一个 vscode server 的。 你本地只是展示 UI, 剩余的 vscode 功能和代码执行都是放在 remote 的，所以你觉得为什么一个叫 node 的进程让你那么卡？
|
 |
8
rbe 2020-09-18 09:34:32 +08:00
碰到过类似的事情，用 windows 做 server(普通 window10，非 win server)，16g i7 4790，开了 remote 后 CPU 跑满，不得已关掉了。但这个不是必现的。
|
 |
9
keepeye 2020-09-18 09:35:57 +08:00
我用的 wsl remote，各种卡，插件不能正常使用，遂放弃
|
 |
10
asanelder 2020-09-18 09:54:27 +08:00
俺猜是 2G1 核，之前也是这情况
试试 4G2 核？ |
 |
11
ruanimal 2020-09-18 10:06:45 +08:00
楼主 remote 编辑的文件夹太大了吧
|
 |
12
oott123 2020-09-18 12:31:24 +08:00
那就不要用 vscode remote 啦，试试这个： https://marketplace.visualstudio.com/items?itemName=liximomo.sftp
|
 |
13
xiaotianhu 2020-09-18 13:13:04 +08:00
+1
同事用这玩意,开发机直接要凉了感觉 关了好多了. 猜测是服务端 node 在搞索引.开发机是机械盘,扛不住 |
 |
14
kokodayo 2020-09-18 13:18:27 +08:00
还有个方案：服务器上装 linux 版 vs code，然后 X11 Forwarding
|
 |
15
zhenjiangidc 2020-09-18 13:25:15 +08:00
硬盘不行？？？
|
 |
16
MengiNo 2020-09-18 14:28:16 +08:00
都叫 remote 了，不拖死服务器难道还拖死本机么 ... 为了让我那 8G 的 15 款 mbp 再发挥几年余热，前一段搞了个 2c4g 的腾讯云，vscode-remote 体验挺棒的，mbp 上只要 在 /usr/local/bin 里放一个 dockerd 的二进制文件，其他都交给服务器，连 git 甚至都可以不用装（正好 big sur 的预览版 也有 bug 装不了 xcode-select 套件），.devcontainer 文件夹 直接放在 Dropbox / Github 里真的很方便。
最好是推荐 2c4g 的机器，1c2g 倒也不是说不行，消耗较少的语言、项目还是可以跑得动的，合理控制插件即可。比如 Laravel 项目，Gitlens + PHP Intelephense + PHPUnit Test Explorer + phpfmt + DocBlocker 1c2g 还是很舒服的。其他的像 Golang 、Python 1c2g 也勉强能用。但是 一个 Typescript 的基于 Antd 的管理后台，仅开了 Gitlens + Eslint + Prettier 直接卡的起飞，必须上 2c4g 否则 yarn install 都拉不下来（毕竟 black hole ），直接 CPU 冲到 100%，服务器就假死了（等好久 zsh 进程会把 node 进程杀掉以恢复正常，但是我是实在懒得等，都是直接去腾讯云后台强制重启）。 如果没有什么特别的需求，特别是本地机器性能不错的情况下，还是 WSL2 + Docker，感觉足够了，传统一点好。vscode-remote 不但要投入服务器成本，在某些语言的项目上也只能算差强人意（要不是 remote 我是真的一点都不想用本身就是 Js 写的 vscode ）。 |
 |
17
lovecy 2020-09-18 16:14:35 +08:00
“我就纳闷了一个编辑器去拖累服务器干嘛？”，其实这个就跟你浏览器请求一个页面，结果服务器崩了一个道理。
remote 连接后，是不是开了比较大的文件夹或工作区，还有插件太多也会导致资源占用高 |
 |
18
spcharc 2020-09-19 11:09:27 +08:00
为什么都猜测是 node 搞索引？
这是微软版 linux kernel 的锅啊。 node 的服务端有个 event loop 。它和所有 event loop 一样，如果没事可做它会做个 syscall 睡一会儿，起来接着检查有没有事可做。 然而 wsl 里 linux 内核是 windows 模拟的，较新版本的 glibc （ 2.31 或以上）因为改写了 nanosleep 的逻辑，会无法正确调用这个模拟 kernel 的 syscall 。 老版本使用的是 CLOCK_MONOTONIC，新版本改用 CLOCK_REALTIME，而 WSL 从来没有支持过后者。微软当时做模拟 kernel 是针对老 glibc 。 因为大量程序都要用到 glibc，这会导致各种程序里所有要 sleep 的地方都会立刻返回，包括 node 。 https://sourceware.org/git/?p=glibc.git;a=commit;f=posix/nanosleep.c;h=3537ecb49cf7177274607004c562d6f9ecc99474 自己在测试 wsl 里测试 bash 命令： sleep 5 如果这个命令立刻返回了，而不是等五秒再返回，恭喜你中招了。 解决方案： 降级 glibc 到 2.30 或以下，或换老发行版环境，或 wsl2 走起，或加入微软 Insider 测试渠道来升级微软修复过的 kernel |
Select Language