在Linux服务器中 项目一启动 VS Code 就断开一次从 Windows 虚拟内存到 Linux Swap 的排查实践文章目录在Linux服务器中 项目一启动 VS Code 就断开一次从 Windows 虚拟内存到 Linux Swap 的排查实践1. 问题背景项目一启动VS Code 就断开2. Linux Swap和 Windows 虚拟内存有什么关系3. 在 Ubuntu 中创建并启用 Swap4. 配置 Swap 后重新启动项目5. Swap 的使用边界和注意事项6. 常用命令与总结在服务器上部署项目时我遇到过一个看起来很像网络问题、实际却和内存有关的故障VS Code Remote SSH 平时连接正常但只要启动项目远程连接很快就会断开严重时连 SSH 都暂时无法正常连接。后来排查发现真正的问题不是 VS Code也不是 SSH而是服务器物理内存过小。项目启动阶段的瞬时内存占用把服务器推到了严重的内存压力状态。解决这个问题时我想到 Windows 在内存压力较大时会借助磁盘上的分页文件Pagefile参与内存管理于是进一步查找 Linux 是否也有类似机制最终使用Swap缓解了服务器的内存压力并让项目正常启动。**说明**本文主要记录一次真实的排查和解决过程。文中的内存大小与命令输出示例仅用于说明实际配置应以自己的服务器环境为准。1. 问题背景项目一启动VS Code 就断开当时我使用VS Code Remote SSH直接连接一台 Ubuntu 服务器进行项目部署。平时连接服务器、编辑代码、上传文件都没有什么问题但只要启动项目VS Code 的远程连接很快就会断开。有时重新连接也会失败SSH 长时间没有响应服务器看起来就像直接“卡死”了一样。一开始我首先怀疑的是网络、SSH 或 VS Code Remote 本身的问题。但反复测试之后发现了一个很明显的规律不启动项目时服务器可以正常连接一旦启动项目服务器很快就会失去响应。于是排查方向开始从“连接问题”转向“服务器资源问题”。可以先使用下面的命令查看服务器内存情况free-h也可以通过top或者htop观察各个进程的实时资源占用。检查后发现这台服务器本身的物理内存比较小而项目在启动阶段又会瞬间占用较多内存最终导致可用内存快速耗尽。整个过程大致可以理解为服务器物理内存较小 ↓ 启动项目 ↓ 内存占用快速上升 ↓ 可用内存不足 ↓ 系统进入严重内存压力 ↓ 项目、VS Code Server 等进程受到影响 ↓ 远程连接中断这里需要注意服务器表现得像“宕机”并不一定代表 Linux 系统本身真的崩溃了。当物理内存严重不足时Linux 可能进入很高的内存压力系统响应会明显变慢如果可用内存进一步耗尽还可能触发OOMOut Of Memory机制由内核终止部分进程来释放内存。而 VS Code Remote SSH 连接远程服务器后服务器端还会运行对应的VS Code Server进程。项目启动后如果进一步抢占内存VS Code Server、SSH 服务或项目自身都可能受到影响因此从客户端看起来就像“VS Code 一启动项目就掉线”。也就是说当时看到的“项目一启动VS Code 就断开。”只是表面现象。真正的问题是服务器物理内存不足无法稳定承受项目启动阶段的内存需求。确认问题和内存有关之后我想到 Windows 在内存压力较大时可以借助磁盘上的分页文件参与内存管理于是开始查找 Linux 中是否存在类似机制也由此接触到了 Linux 的Swap。2. Linux Swap和 Windows 虚拟内存有什么关系在 Windows 中虚拟内存是一套完整的内存管理机制而磁盘上的Pagefile分页文件是其中的一部分。当系统出现内存压力时Windows 可以借助分页文件把部分不需要继续常驻物理内存的数据写入磁盘。Linux 中同样存在利用磁盘缓解内存压力的机制这就是Swap交换空间。简单来说Swap 是 Linux 内存管理体系中的交换空间可以在物理内存紧张时把部分内存页换出到磁盘从而释放 RAM。可以简单理解为物理内存 RAM ↓ 内存开始紧张 ↓ 部分暂时不活跃的内存页 ↓ Swap ↓ 释放一部分物理内存Windows 和 Linux 在具体实现上并不完全相同但从使用者角度来看可以这样建立一个直观联系Windows Linux 物理内存压力增大 物理内存压力增大 ↓ ↓ Pagefile Swap 分页文件 Swap File / Partition ↓ ↓ 借助磁盘空间缓解内存压力这也是我当时为什么会从 Windows 的“虚拟内存”联想到 Linux。不过需要特别注意Swap 并不等于真正增加了物理内存。假设服务器本身有2 GB RAM又创建了4 GB Swap并不能简单理解成2 GB RAM 4 GB Swap 6 GB RAM因为 RAM 和 Swap 使用的硬件并不相同。RAM 是真正的物理内存而 Swap 通常位于 SSD 或 HDD 上读写速度明显低于内存。因此更准确的理解是RAM 速度快 主要承担程序运行时的内存需求 ↓ 内存紧张时 Swap 速度较慢 用于缓解物理内存压力Swap 更像是物理内存不足时的一层缓冲而不是物理内存的替代品。Linux 中常见的 Swap 主要有两种形式Swap 分区在磁盘上划出一个专门的分区作为交换空间。Swap 文件直接在现有文件系统中创建一个文件作为交换空间。对于已经运行中的 Ubuntu 服务器来说重新调整磁盘分区通常比较麻烦因此使用Swap File会更加方便。它不需要重新划分磁盘分区同时创建、调整和删除也比较简单。这次服务器内存不足的问题我采用的也是Swap File的方式。3. 在 Ubuntu 中创建并启用 Swap在配置之前先查看当前服务器的内存和 Swap 状态free-h如果系统没有配置 Swap可能会看到类似total used free shared buff/cache available Mem: 1.9Gi 1.5Gi 120Mi 20Mi 300Mi 180Mi Swap: 0B 0B 0B也可以执行swapon--show如果没有任何输出通常说明当前没有正在使用的 Swap。这里采用Swap File的方式。例如创建一个 4 GB 的交换文件sudofallocate-l4G /swapfile**注意**这里的 4 GB 只是示例。Swap 大小应结合物理内存、磁盘空间以及实际负载决定并不是所有服务器都应该配置 4 GB。创建完成后可以检查文件ls-lh/swapfile此时/swapfile还只是一个普通文件需要先限制它的访问权限sudochmod600/swapfile设置为600后只有 root 用户可以读写该文件。Swap 中可能包含从内存换出的数据因此不应该允许普通用户随意读取。接着把这个文件初始化为 Swapsudomkswap/swapfile正常情况下会出现类似输出Setting up swapspace version 1, size 4 GiB然后启用它sudoswapon/swapfile再次执行swapon--show可以看到类似NAME TYPE SIZE USED PRIO /swapfile file 4G 0B -2再查看内存free-h此时 Swap 一栏就会从原来的Swap: 0B变成类似Swap: 4.0Gi如果当前文件系统或环境不适合直接使用fallocate创建 Swap 文件也可以使用ddsudoddif/dev/zeroof/swapfilebs1Mcount4096statusprogress后续仍然执行sudochmod600/swapfilesudomkswap/swapfilesudoswapon/swapfile为了让 Swap 在服务器重启后仍然自动启用还需要写入/etc/fstab。可以编辑sudonano/etc/fstab在文件末尾加入/swapfile none swap sw 0 0保存后系统启动时就会根据/etc/fstab自动启用这个 Swap 文件。整个配置过程可以概括为创建 Swap 文件 ↓ 修改文件权限 ↓ 初始化 Swap ↓ 启用 Swap ↓ 写入 /etc/fstab常用命令汇总如下sudofallocate-l4G /swapfilesudochmod600/swapfilesudomkswap/swapfilesudoswapon/swapfile配置完成后可以通过下面两个命令确认 Swap 是否正常启用free-hswapon--show4. 配置 Swap 后重新启动项目Swap 配置完成后我重新通过 VS Code Remote SSH 连接服务器并再次启动之前那个一运行就会导致连接中断的项目。这一次最直观的变化是项目启动后VS Code Remote 没有再立刻断开服务器也没有再次出现明显失去响应的情况。为了观察项目启动过程中的内存变化可以在另一个终端中执行watch-n1free-h这样可以每隔 1 秒刷新一次内存和 Swap 的使用情况。也可以使用top或者htop查看各个进程的资源占用。如果系统开始使用 Swap可以在free -h中看到 Swap 的used不再是 0例如total used free Mem: 1.9Gi 1.7Gi ... Swap: 4.0Gi 300Mi 3.7Gi这里的数值仅用于演示实际情况以服务器输出为准。可以把配置前后的现象简单对比一下配置 Swap 前 启动项目 ↓ 物理内存快速耗尽 ↓ 系统进入严重内存压力 ↓ 服务器响应异常 ↓ VS Code Remote 断开配置 Swap 后 启动项目 ↓ 物理内存开始紧张 ↓ 系统可以使用部分 Swap ↓ 缓解 RAM 压力 ↓ 服务器保持基本响应 ↓ 项目正常启动如果想进一步确认系统之前是否发生过 OOM还可以查看内核日志sudodmesg-T|grep-i-Eout of memory|oom|killed process或者sudojournalctl-k|grep-i-Eout of memory|oom|killed process如果系统之前确实因为内存不足触发过 OOM可能会看到类似Out of memory Killed process ...的日志信息。如果服务器已经重启过也可以根据实际日志保留情况进一步查看上一轮启动的内核日志例如sudojournalctl-k-b-1需要注意没有查到 OOM 日志并不能百分之百证明之前没有发生过内存问题因为日志是否还存在取决于系统日志配置、是否重启以及问题发生的时间。这次实际问题的排查过程可以归纳为VS Code Remote 频繁断开 ↓ 发现问题只在项目启动时出现 ↓ 检查服务器资源 ↓ 定位到物理内存不足 ↓ 配置 Swap ↓ 重新启动项目 ↓ 项目正常运行表面上看最开始只是“VS Code 一启动项目就掉线”但真正的问题其实是服务器的内存配置无法稳定支撑项目启动阶段的资源需求。5. Swap 的使用边界和注意事项虽然 Swap 能缓解物理内存不足的问题但它不能真正代替 RAM。原因很简单RAM 速度快适合程序频繁读写 Swap 位于磁盘速度明显更慢因此Swap 更适合用于项目启动、构建或部署时出现的瞬时内存峰值小内存服务器偶发的内存不足降低瞬时内存耗尽后触发 OOM、导致进程被终止的风险。如果服务器长期处于下面这种状态RAM 长时间接近占满 Swap 持续大量使用通常说明服务器本身的内存配置已经不足。这时继续增加 Swap只能缓解问题不能真正解决性能瓶颈。另外Swap 也不是越大越好。创建很大的 Swap 文件会占用磁盘空间而当系统频繁在 RAM 和 Swap 之间换入、换出内存页时磁盘 I/O 会增加程序响应速度也可能明显下降。可以简单理解为物理内存长期不足 ↓ 频繁换出到 Swap ↓ 又频繁从 Swap 换回 ↓ 磁盘 I/O 增加 ↓ 整体性能下降如果只是偶尔在项目启动、构建或部署时出现内存峰值Swap 往往是一个比较实用的补充方案。但如果服务器长期依赖 Swap就更应该考虑升级服务器物理内存优化程序的内存占用减少不必要的后台服务限制容器或进程的资源使用调整程序启动方式避免多个高内存任务同时运行。我这次遇到的情况属于项目启动阶段出现明显的瞬时内存压力因此配置 Swap 后服务器能够顺利撑过这段高内存占用阶段项目也可以正常启动。6. 常用命令与总结最后整理一下这次排查和配置过程中比较常用的命令。查看当前内存使用情况free-h查看当前启用的 Swapswapon--show实时观察内存变化watch-n1free-h查看进程资源占用top或者htop临时关闭全部 Swapsudoswapoff-a重新启用指定 Swap 文件sudoswapon/swapfile查看是否出现过 OOM 相关日志sudodmesg-T|grep-i-Eout of memory|oom|killed process这次问题一开始表现得很像 VS Code Remote SSH 或网络连接异常启动项目 ↓ VS Code Remote 断开 ↓ 服务器无法正常响应但真正排查下来根本原因其实是服务器物理内存不足。而我的解决思路来源于一个很简单的知识迁移Windows 的分页文件 ↓ 想到 Linux 是否也有类似机制 ↓ 查到 Swap ↓ 创建 Swap File ↓ 重新启动项目 ↓ 项目正常运行这次经历让我比较深刻的一点是遇到问题时故障表现出来的位置不一定就是真正的问题所在。VS Code Remote 断开只是最终表现继续往服务器资源层面排查才找到了真正的原因。另外Swap 也不是物理内存的替代品。它更适合作为内存不足时的一层缓冲尤其适用于小内存服务器在部署、构建或启动项目时出现短时间内存峰值的场景。如果服务器长期大量使用 Swap还是应该优先考虑增加物理内存或者进一步优化程序本身的资源占用。VS Code Remote 断开 ↓ 排查服务器资源 ↓ 发现物理内存不足 ↓ 联想到 Windows 分页文件 ↓ 使用 Linux Swap ↓ 项目正常启动