<p>先运行df -h确认/var或/var/lib/docker挂载点Use%是否超95%，再用df -i查inode；若高占用，执行du -sh * 2>/dev/null | sort -hr | head -15定位log/cache/docker等目录；优先用logrotate轮转、truncate清空日志或lsof+kill释放deleted文件句柄；最后停非必要容器、精简Docker日志配置并迁移模型至数据盘。</p>
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你的ChatGPT服务频繁报错“no space left on device”，容器反复崩溃、日志写不进、模型加载失败，不是模型太大，而是服务器磁盘被日志、缓存、残留镜像悄悄吃空——盲目清日志或删容器ID，可能让服务彻底失联。
先确认是不是真缺空间
登录服务器，运行 df -h，重点看 【/var 或 /var/lib/docker 所在挂载点的 Use% 是否超过95%】。若显示 100% 但 df 没报错，极可能是已删除日志文件仍被进程持有句柄，在后台持续写入占位。
再跑 df -i，检查 inode 使用率。哪怕磁盘显示还有 30% 空间，【inode 耗尽也会触发 same error】，此时必须优先清理小文件而非大文件。
精准定位真实罪魁
进入高占用分区根目录（如 cd /var），执行：
du -sh * 2>/dev/null | sort -hr | head -15
这一步列出前15个最大子目录。注意：必须加 2>/dev/null，否则权限拒绝刷屏会淹没真实结果。若看到 log、cache、lib/docker 异常突出，就钻进去继续查。
例如发现 /var/log 占比畸高，进入后立即执行：du -sh */* 2>/dev/null | sort -hr | head -8，快速锁定 docker/containers 或 journal 下的膨胀日志子目录。
安全清理三板斧
方法一：用 logrotate 强制轮转（推荐）
找到对应服务配置，比如 ChatGPT WebUI 的日志通常由 nginx 或 pm2 管理，查配置路径：ls /etc/logrotate.d/ | grep -E "nginx|pm2"。确认参数无误后，直接运行：logrotate -f /etc/logrotate.d/nginx。它会按规则压缩旧日志、删除过期归档，不中断任何进程。
方法二：清空正在写入的日志文件（慎用）
若发现 /var/log/chatgpt-webui/out.log 已达 8GB 且 tail -f 显示实时滚动，绝不能 rm。用 truncate -s 0 /var/log/chatgpt-webui/out.log 或 > /var/log/chatgpt-webui/out.log。这保留文件 inode 和进程句柄，服务完全无感。
方法三：释放已删仍占空间的文件
运行 lsof +L1，找形如 node 12345 root 1w REG 8,1 1245678900 987654 /var/log/chatgpt-webui/error.log (deleted) 的条目。记下 PID（这里是 12345），执行 kill -USR1 12345（通知进程重开日志）或直接 kill -9 12345 后重启服务——【务必确认该进程非核心主服务，否则会中断API】。
扩容前必须砍掉的假需求
第一步：停掉所有非必要容器
docker ps -q | xargs docker stop → docker system prune -f --volumes。这一步清理掉已退出容器、悬空镜像、未被引用的 volume，往往能腾出 5–20GB。注意：【--volumes 参数会删除所有未被容器引用的卷，确认无重要数据再执行】。
第二步：禁用 Docker 默认日志驱动
编辑 /etc/docker/daemon.json，加入：{"log-driver": "local", "log-opts": {"max-size": "10m", "max-file": "3"}}。重启 Docker：systemctl restart docker。从此新容器日志自动轮转，单个不超过 10MB，最多存 3 份。
第三步：把模型文件移出系统盘
若模型放在 /root/models，而你有大容量数据盘（如 /data），直接 mv /root/models /data/，再用软链还原：ln -s /data/models /root/models。这比扩 C 盘快十倍，且避免后续反复踩坑。
