Azure ML Studio Compute VM频繁卡顿需重启，寻求故障排查建议

核心原因分析 #

1. 磁盘IO瓶颈：共享驱动器（code/Users/）多用户IO竞争、/tmp临时分区空间不足或频繁读写，加上大量未追踪大文件持续占用磁盘资源，导致系统IO负载过高，拖慢所有操作。
2. 文件系统扫描过载：GitHub仓库深目录+GB级未追踪文件，VS Code后台自动扫描Git状态、文件索引，Git进程持续占用CPU和IO，运行时间越长资源消耗累积越严重，最终引发卡顿。
3. 内存/缓存耗尽：Jupyter Notebook运行中内存泄漏或缓存累积，结合大文件占用内存，系统被迫启用交换分区（swap），导致操作延迟飙升，甚至出现进程假死（单元格显示运行但无实际进程）。
4. 临时磁盘误用：曾因向/tmp写入大文件触发磁盘满错误，说明临时分区空间规划不合理，或应用未利用VM本地SSD临时磁盘（Standard_D16s_v3自带本地SSD，IO性能远高于系统HDD）。

分步排查与优化方向 #

一、磁盘资源深度诊断 #

• 实时监控磁盘IO负载：执行iostat -x 1，重点关注各挂载点的%util指标（持续超过80%即为IO瓶颈），区分系统盘、共享盘、临时磁盘的负载差异。
• 全面检查磁盘空间：用df -h查看所有分区可用空间，重点确认/tmp、共享驱动器（code/Users/对应挂载点）的剩余空间；用du -sh /tmp/*定位大文件并定时清理。
• 评估Git仓库负载：执行du -sh .git/查看Git仓库大小，用git clean -n预览未追踪文件列表，统计GB级文件的数量与位置，判断其对后台扫描的影响。

二、资源占用优化 #

• 监控后台进程：用htop持续观察，重点排查code-server（浏览器版VS Code）、git相关进程是否持续高CPU/内存占用，定位资源消耗大户。
• 调整VS Code设置：
  • 禁用自动Git状态扫描：在设置中搜索git.autorefresh并关闭，避免后台频繁扫描仓库文件。
  • 排除大文件目录：在files.exclude中添加未追踪大文件的路径（如**/large_temp_files/**），减少文件索引开销。
• 清理未追踪文件：用git clean -f（操作前务必备份重要文件）删除无用的未追踪大文件，或把大文件移至Git仓库外的存储目录，彻底规避扫描负载。

三、Jupyter Notebook专项修复 #

• 检查内核状态：执行jupyter kernelspec list确认内核路径，查看~/.local/share/jupyter/runtime/下的内核日志，排查内存泄漏、进程崩溃记录。
• 监控内核资源：启动Notebook时添加参数jupyter notebook --ResourceUseDisplay.track_cpu_percent=True，实时查看内核CPU/内存占用，及时关闭闲置的Notebook标签。
• 精简扩展：禁用非核心Notebook扩展（如不必要的可视化、格式化工具），测试性能是否改善。

四、共享存储与VM配置验证 #

• 确认共享存储层级：Azure ML共享存储若为标准HDD，IOPS和吞吐量有限，多用户并发读写会严重拖慢系统，可联系管理员评估升级为Premium SSD的可行性。
• 利用本地临时磁盘：Standard_D16s_v3的本地SSD临时磁盘通常挂载在/mnt或/var/lib/waagent，将临时文件、中间数据写入该分区，替代/tmp或系统盘，提升IO性能。
• 对比SSH连接性能：尝试通过SSH直接连接VM操作，对比浏览器版VS Code的性能差异，排除浏览器端网络延迟或渲染开销的影响。

内容的提问来源于stack exchange，提问作者wordsforthewise