前言
创立此博客之初，我遇到了一个非常苦恼的问题，那就是云服务器时不时的就会宕机。
笔者使用的是阿里云的二核轻量应用服务器，搭载 ubuntu24.04 系统。
虽然性能确实捉襟见肘，但作为只运行使用了lnmp框架的系统环境，要说性能瓶颈未免有些牵强。
为安全和方便考虑，我使用 vscode 的 ssh 插件密钥连接服务器作为开发工具。埋下伏笔
具体表现
CPU 占用率居高不下，在阿里云端发送重启指令后等待时间异常，系统盘io超载，ssh、vnc、ping 等通信握手超时。
显然，有进程占用了大量资源导致阻塞，并且疯狂的读写把盘炸了。
事已至此，先装个 atop 看看日志吧，我是这么想的。
初现端倪
经过漫长的等待重启后，火速安装 atop 并运行。可正当我准备查看日志时，服务器又又宕机了。
我想到，每次宕机我都在远程作业，显然vscode嫌疑非常大，难道是是 vscode 同步了一些插件到服务端导致的？
进入查看 vscode 插件管理，果不其然有两个不相干的插件———— github 与 github-copilot 。
卸载掉这俩插件后，短时间内确实没宕机了，我自以为解决了故障，于是atop的日志也没看。好孩子千万别学我
但是没过多久，服务器又宕机了。
故障原因
难道我错怪 vscode 了？总之，先重启吧。（漫长的等待过后）
这次我学乖了，不使用 vscode 找故障原因（毕竟 vscode 本身可能就是故障原因）
使用 vnc 进入后台，ps aux 查看进程，发现 vscode 进程确有异常。
于是再次作死打开 vscode ，查看进程————异常多的 vscode 进程占用了巨量资源！
我突然想到之前使用 vscode 时，同时进行两个连接时服务器宕机了，查看atop日志时进入的是系统根目录，也宕机了。
好似文件夹数量越多越容易宕机，那么答案呼之欲出了。
在互联网上查找资料后，果不其然是因为 vscode 默认会对工作区的所有文件建立索引，因此工作区文件一多就宕机了。
解决办法也很简单，将 vscode 设置中的 search:Follow Symlinks 取消勾选即可。
大功告成！完美解决此次故障，皆大欢喜。除了atop，日志我还是没看
总结
故障原因：vscode 会对工作区的文件建立索引，即使这是一个远程工作区。
解决办法：在设置中将远程连接的 search:Follow Symlinks 的值置于 false 即可解决。
后记
大概一周后又出现了此问题，且vscode刚连接就直接卡死，说明这次问题出在初始化上了。
ssh登录后删掉 .vscode-server 目录，以便在下次连接的时候创建一个纯净的vscode-server环境。
解决方法是打开 vscode 的 remote-ssh 插件设置，将下列键值对改为如图所示。
连接，登录，all done！