解决云服务器打开 VS Code Server 后失去响应的问题

我在一台阿里云轻量云服务器上部署了 VS Code Server，用于远程开发。这台服务器配置为 2 核 CPU + 2GB 内存，我额外添加了 8GB 的 swap，希望应对 VS Code Server 启动后的内存压力。然而，在实际使用中，每次通过 SSH 启动 VS Code Server 后不久，服务器就会失去响应，SSH 连接中断，必须强制重启机器。

起初我怀疑是内存不足或 swap 设置不当导致的系统崩溃，但深入排查之后，发现真正的问题其实来自系统对 inotify 监听器数量的限制。通过调整 fs.inotify.max_user_watches 参数，问题得以彻底解决。

下面是我的排查过程与最终的解决方案。

初步怀疑：内存不足和 swap 设置

由于 VS Code Server 启动时会拉起大量语言服务器、插件和文件监听器，在初次遇到 SSH 连接中断后，我第一时间怀疑是内存不足导致的。通过 dmesg 和 free -h 查看系统日志和内存状态，发现 VS Code Server 启动后确实存在内存紧张的情况。

我尝试通过增加 swap 空间到 8GB 来缓解压力，具体做法可以参考之前的文章Linux 下增加、删除 Swap 文件。然而，问题依旧没有解决。SSH 连接依然在 VS Code 启动后不久被挂起，系统无法及时响应新连接，甚至无法正常关机。

进一步调查：监控进程和系统调用

我观察到在 VS Code Server 启动后，node 和 tsserver 进程数量迅速上升，内存占用随之增高，同时系统 I / O 等待时间变得非常长。用 vmstat 和 ps 工具查看系统状态时，也看到了频繁的文件访问和上下文切换。

这让我开始怀疑是否是文件系统监听器数量过多导致系统资源耗尽。VS Code 和许多语言服务器会使用 inotify 机制监听文件变化，用于自动刷新和提示功能。而 Linux 对每个用户可以创建的 inotify 监听器数量是有限制的。

找到真正的问题：inotify 限制过低

通过查看 /proc/sys/fs/inotify/max_user_watches，我发现默认值仅为 8192。这对于一个包含多个项目文件夹和自动索引的开发环境来说，远远不够。

一旦监听器数量超限，VS Code Server 中的插件和语言服务器就会频繁尝试重新监听文件，占用大量资源，最终导致系统进入无法响应的状态。这也解释了为什么增加 swap 并没有改善情况：问题其实不是内存不足本身。

解决方案：提高 max_user_watches 限额

确定问题之后，我通过以下方式修改了系统配置：

首先临时调整参数：

1

sudo sysctl fs.inotify.max_user_watches=65536

然后将其写入配置文件以永久生效：

1
2

echo fs.inotify.max_user_watches=65536 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

重启服务器后再次连接 VS Code Server，问题彻底消失。无论打开多少项目或运行多少扩展，服务器都能够稳定运行，系统资源使用保持正常。

总结

云服务器内存有限时运行 VS Code Server，常见的建议是增加 swap、限制语言服务器内存或禁用部分扩展。然而，如果系统在 VS Code 启动后迅速失去响应，除了内存问题，还应特别注意 inotify 的限制。

在我遇到的案例中，虽然最初误以为是内存瓶颈，最终发现是 fs.inotify.max_user_watches 太低导致的资源耗尽。只需简单提升监听器上限，就能让 VS Code Server 在低配服务器上运行得更加稳定流畅。

如果你也在远程开发中遇到类似问题，不妨检查一下这个关键参数。