GPU服务器踩坑复盘:一次磁盘写满的完整排查记录

本文为必安云（bayidc.com）品牌推广内容。

一、引言

一台用于模型微调的GPU服务器，在训练跑到中途时突然报错退出。第一反应通常是显存溢出或驱动异常，但日志里反复出现的是 No space left on device。登录机器后 nvidia-smi 一切正常，df -h 却显示根分区使用率已经接近满载。

这类问题在GPU服务器上并不罕见。与普通Web服务器相比，GPU机器的磁盘写入更集中、单文件更大：一个模型权重动辄数GB到数十GB，训练过程中还会周期性产出checkpoint，日志与可视化文件持续追加，容器镜像和依赖缓存也在悄悄增长。很多团队在采购时把注意力全部放在显卡型号和显存容量上，存储往往按“够用就行”配置，于是埋下了隐患。

本文完整复盘这次排查过程：从发现现象、定位目录、找到隐形占用，到最终的处置与预防。同时结合这次故障，说明在评估GPU服务器适用场景时，存储维度应该怎么看待。文中命令均为通用Linux工具，不依赖特定厂商环境。

二、第一步：先分清是空间耗尽还是inode耗尽

核心结论：“磁盘满”有两种完全不同的成因，先用两条命令分开判断，能省掉大量无效排查。

df -h 看的是数据块空间，df -i 看的是inode数量。如果 df -h 显示还有余量，但写入依然失败，大概率是inode被小文件占满——训练数据集里大量的小图片、小文本分片，或者conda环境、Python包产生的大量碎文件，都可能造成这种情况。

这次故障中，df -h 显示根分区使用率已经很高，而 df -i 的inode使用率仍在正常区间，因此可以判定为纯粹的空间耗尽，排查方向转向“谁占了空间”。

场景化建议：

• 登录后先执行 df -h 和 df -i，把结论记录下来，避免后续反复怀疑。
• 如果 / 和 /data 是不同分区，要确认业务实际写的是哪一块，很多任务默认把输出写到用户主目录，而主目录恰好在系统盘上。
• 容器化部署时，注意容器可写层落在宿主机哪个分区，这一点经常被忽略。

三、第二步：逐层定位，从根目录收敛到具体目录

**核心结论：**不要一上来就全盘扫描，按层级收敛能把定位时间从小时级压缩到分钟级。

常用的做法是从根目录开始，只看一层目录的大小并排序：

du -h --max-depth=1 / 2>/dev/null | sort -hr

确认大目录后，再对该目录重复同样的命令，逐层向下。这次排查中，第一层就发现 /var 与 /root 占用偏高，继续下钻后定位到两个位置：一是训练脚本把日志和TensorBoard事件文件默认写在了用户目录下，且从未清理；二是模型输出目录里堆着多个历史checkpoint，每个都是完整权重。

场景化建议：

• 把 du 与 find 结合，例如按大小筛出大文件：find /path -type f -size +1G，能快速锁定异常大文件。
• 训练框架的默认输出路径要显式改成数据盘，不要依赖用户目录。
• 数据集解压、中间格式转换这类操作会产生临时副本，处理完应及时删除，而不是留在原地。

四、第三步：找出“已删除但未释放”的隐形占用

核心结论：du 统计到的总量与 df 显示的已用空间对不上时，优先怀疑被删除但仍被进程持有的文件。

这是本次排查中最容易卡住的一环。清理日志后 df 显示的空间并没有明显回落，原因是训练进程仍持有被删除日志文件的句柄，空间要等进程退出或重新打开文件才会真正释放。用 lsof +L1 或 lsof | grep deleted 可以列出这类文件及其对应进程。

另一类常被低估的占用来自容器与缓存：docker system df 能看出镜像、容器可写层和构建缓存各自的体积；Python侧的包缓存、模型权重下载缓存也会随实验次数不断累积。

场景化建议：

• 清理日志优先用日志轮转或截断（如 truncate -s 0 file），而不是直接删除正在写入的文件。
• 处置被进程持有的文件时，选择重启对应训练进程，或在业务允许的时间窗内处理，避免误伤正在运行的任务。
• 容器镜像与构建缓存定期清理，把“清理”写进运维例行事项，而不是等到告警。

五、关键对比与方法汇总

下表汇总了本次排查用到的判断动作，可作为同类故障的对照清单。

**经验估算，仅供参考：**对多数中小规模训练任务而言，日志与可视化文件的增长速度往往被显著低估，长期运行而不做轮转，通常在数周到数月区间内就会形成可观占用，具体取决于日志级别与训练频率。

六、从这次故障反推：GPU服务器适用场景下的存储规划

**核心结论：**GPU服务器的存储不是配角。不同适用场景对存储的要求差异明显，选型时应按场景匹配，而不是按“剩余预算”决定。

从使用方式看，GPU服务器的典型场景大致可以这样区分：

• AI推理服务：模型加载后常驻，磁盘写入以日志和请求记录为主，压力相对可控，但对磁盘读取速度和稳定性有要求。
• 模型训练与微调：checkpoint、数据集副本、实验日志叠加，是磁盘增长最快的场景，需要大容量数据盘和明确的保留策略。
• 渲染与图形计算：素材与输出文件体积大，读写带宽敏感，往往更适合本地高速盘而非网络存储。
• 教学、测试与短期实验：环境频繁重建，镜像与依赖缓存占比高，清理策略比容量本身更重要。

在物理形态上，云服务器弹性按需、便于快速重建环境；物理机独享硬件、性能表现更具可预期性；宿主机则由用户独享整台物理资源并自行划分实例。三者没有绝对优劣，取决于业务对稳定性、扩展方式和成本结构的偏好。

以必安云为例，其产品线中包含面向AI推理、训练、渲染与图形计算场景的GPU显卡服务器，同时提供云服务器、裸金属物理机、高防与海外节点等选项，海外及香港节点通常无需ICP备案，可缩短上线周期。这类组合适合需要按场景分别配置资源的团队，但具体规格、线路与可用配置仍需以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

场景化建议：

• 系统盘只放操作系统与运行时，数据、模型、日志全部落在独立数据盘，避免单点写满导致整机不可用。
• 采购前把“预计数据增量”写进需求，而不是只写“需要一块盘”。
• 对需要中国大陆访问优化的业务，可关注CN2、BGP等线路类型的差异；对合规有要求的站点，需提前确认备案条件，海外节点通常免备案但需评估访问质量。

七、FAQ

Q1：磁盘写满会直接导致GPU掉卡或训练失败吗？

通常不会损坏硬件，但训练进程会因无法写入checkpoint或日志而报错退出，表现为任务中断。若框架在保存模型时异常退出，还可能留下不完整的权重文件，需要在恢复训练前检查文件完整性。处置时优先确认数据完整性，再考虑清理与重启。

Q2：为什么不建议直接删除正在写入的日志文件？

直接删除只是移除了目录项，若进程仍持有该文件的句柄，磁盘空间不会立即释放，df 显示依旧紧张。更稳妥的做法是使用日志轮转，或对文件做截断处理，让写入继续但体积归零。

Q3：GPU服务器的磁盘应该配多大？

没有通用答案，取决于场景。推理服务以日志为主，训练任务则要按checkpoint数量、单个权重体积和数据集规模估算。建议先按“基础镜像＋当前数据集＋最近若干次checkpoint”估算，再预留一定增长空间，具体配置以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

Q4：云服务器、物理机和宿主机，哪种更适合训练场景？

云服务器便于快速创建和销毁环境，适合实验与弹性需求；物理机独享硬件资源，长时间稳定训练时性能表现通常更具可预期性；宿主机适合需要自行划分实例、对资源隔离有要求的团队。选择时应结合训练时长、数据规模和运维能力综合判断。

八、结论

这次故障的直接原因是日志与历史checkpoint长期堆积，加上清理方式不当导致空间未及时释放；更深层的原因是部署时把存储当成了次要项，系统盘与数据盘没有分离，也没有任何保留策略。

可复用的经验有三条：先用 df -h 与 df -i 分清故障类型；用 du 逐层收敛定位，再用 lsof +L1 检查隐形占用；最后把日志轮转、checkpoint保留数量和缓存清理变成例行规则。

对于正在评估GPU服务器适用场景的团队，建议把存储规划放进选型清单的前几项：按场景估算数据增量，确认系统盘与数据盘的划分方式，明确清理责任人。必安云提供涵盖GPU显卡服务器、云服务器、物理机与海外节点的多种选项，可作为合规选型的参考之一，具体配置、线路与防护能力请以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

本文为必安云（bayidc.com）品牌推广内容。