磁盘空间满不是服务挂死的直接原因，而是让服务在关键写操作时失败，从而表现成“异常挂死”。排查需先执行df -h和df -ih确认空间及inode是否耗尽，再用du -sh /* | sort -rh | head -10逐层定位大目录，重点检查/var/log、/var/lib/docker等路径，并通过find和lsof揪出大文件或已删除但被进程占用的文件，最后交叉验证系统日志与服务写操作是否失败。
磁盘空间满不是服务挂死的直接原因，而是让服务在关键写操作时失败，从而表现成“异常挂死”。比如 MySQL 写 binlog 失败、Nginx 写 access.log 失败、Java 应用写堆 dump 失败，都会触发进程退出或卡住。排查要从“系统是否真没空间”开始，而不是一上来就查服务日志。
先确认是不是磁盘空间或 inode 耗尽
执行两条命令，缺一不可：
- df -h：看各挂载点 Use% 是否达到 100%，尤其关注服务实际运行的分区（如 /、/var、/data）
-
df -ih：看对应分区的 IUse% 是否也接近或等于 100%。inode 耗尽时，
No space left on device会照常报出，但df -h显示还有大量空间
常见陷阱：只查 /，却忽略 /var/log 或 /var/lib/docker 是独立挂载点；或者看到 /dev/shm 占用高，误以为是磁盘问题（它其实是内存文件系统）。
定位占用空间的“真凶目录”
对已确认满的挂载点，逐层缩小范围：
- 查一级目录：
du -sh /* 2>/dev/null | sort -rh | head -10 - 若
/var异常大，再查：du -sh /var/* 2>/dev/null | sort -rh | head -10 - 重点盯这些路径：
/var/log（应用/系统日志）、/var/lib/docker（容器镜像+日志）、/var/lib/mysql（binlog、临时表）、/tmp和/var/tmp（临时文件）
不要跳过 2>/dev/null，权限错误会淹没有效结果。
揪出具体的大文件或异常进程
找到可疑目录后，进一步锁定文件级元凶：
- 找大于 500MB 的文件：
find /var/log -type f -size +500M 2>/dev/null -exec ls -lh {} \; - 查 Docker 容器日志（常被忽略）：
find /var/lib/docker/containers -name "*.log" -size +100M 2>/dev/null - 检查已删除但仍在被进程占用的文件：
lsof +L1或lsof | grep deleted。这类文件不显示在目录中，但空间未释放，重启对应进程即可回收
例如 Nginx worker 进程长期持有被轮转走的 access.log.1，就会持续占着空间。
验证服务异常是否与空间相关
别只信服务自己的日志，要交叉验证：
- 查看系统日志中是否有写入失败记录：
journalctl -n 50 --since "1 hour ago" | grep -i "no space\|write\|failed" - 手动模拟服务关键写操作：比如用
echo "test" > /var/log/test.log测试目标目录是否可写 - 检查服务启动时的完整输出：
systemctl status nginx看最近一次 failed 原因，或journalctl -u nginx -n 30查失败上下文
很多服务在初始化阶段就因无法创建 socket 文件、pid 文件或临时目录而静默失败，状态显示为 inactive (dead)，但日志里只有模糊的 “Operation not permitted”。
