企业官网建设流程全解析

凌晨三点被告警短信吵醒，打开笔记本连上VPN，SSH 到那台 4C8G 的服务器，敲下df -h，看到/dev/vda1那一行 Use% 赫然写着 100%。这是很多运维人都有过的经历。“云服务器爆满”这种事，表面看是磁盘满了，但实际上背后可能藏着日志失控、镜像堆积、inode 耗尽、文件句柄不释放…… 各种因素交错在一起，处理不当轻则服务假死，重则数据丢失、实例无法登录。这篇内容我不打算做成教科书式的操作手册，而是从一个实际处理过多次这类故障的从业者角度，把这套东西掰开揉碎：怎么快速定位爆满的真凶、怎么在不影响业务的前提下先把磁盘空间抢回来、事后又该怎么配置才能让它不再犯。如果你也管着几台云服务器，或者正在为磁盘空间告警发愁，这篇应该能帮你省掉不少半夜起床的麻烦。

1. 问题确认与根因分析：爆的到底是什么资源

1.1 先分清磁盘满、内存满还是 inode 耗尽

很多人一看“服务器爆满”就下意识认为磁盘满了，直接开始清文件。但“爆满”这个词其实很含糊，有可能是内存被吃干净、CPU 跑满、磁盘 IO 饱和，也有可能是磁盘空间明明还剩几十 G，但 inode 用完了导致无法创建新文件。判断错误的话，处理方向就会完全跑偏。

我个人的习惯是拿到告警后先跑一组最基础的排查命令，顺序固定，基本能在一分钟内确认问题的类型：

• df -h：看文件系统容量和使用率，确认是不是空间真的满了
• df -i：看 inode 使用率，如果这里显示 100%，空间再大也白搭
• free -h：看内存，判断是不是内存耗尽导致 OOM，进而拖垮 IO
• uptime和top：看负载，排除 CPU 被打满的情况

这里有个很容易踩的坑：df -h和df -i的结果经常不一致。比如根分区显示用了 82%，还在继续写，而 inode 已经 100%，这时候创建任何文件都会报“No space left on device”。我遇到过一次很典型的场景，某跨平台系统的消息队列服务突然写不进数据，排查了一圈，最后发现是/var/spool/下面堆积了几百万个小文件，把 inode 吃光了。当时磁盘空间其实还有空闲，但系统就是像一个满了的储物柜——箱子没满，柜子格子用完了，什么都塞不进去。

1.2 高频根因盘点：日志、镜像、临时文件与数据库文件

确认了是磁盘空间爆满之后，下一步就是找“谁吃了空间”。按我这些年的经验，云服务器磁盘爆满的根因翻来覆去就那几类，而且大多有规律可循。

第一类是日志文件失控，这基本上是概率最高的一种。常见于 Java 应用、Nginx 和系统本身。Java 服务如果不配 logback 或 log4j 的 rolling 策略，一个application.log能跑到几十个 G。Nginx 的access.log在流量高点的时候，一天涨几个 G 很常见。还有一个容易被忽视的是journald，也就是 systemd 的日志。很多发行版默认SystemMaxUse没设置，journal 日志可以无限增长，我曾见过一台只跑了一个 Nginx 的 2G 内存小机器，/var/log/journal/吃掉了 8 个 G 的磁盘空间。

第二类是容器镜像和悬空数据。用 Docker 跑服务的话，/var/lib/docker下的东西膨胀速度非常惊人。新镜像拉取后旧镜像并不会自动删除，反复迭代几版之后，悬空镜像（<none>镜像）和构建缓存能堆出十几个 G。还有容器日志，默认的 json-file 驱动不对文件做任何大小限制，如果应用往 stdout 疯狂打日志，这个文件是可以无限增长的。我做运维的时候见过最夸张的一次，是一个容器打印的日志占满了整个数据盘。

第三类是系统的临时文件和程序产生的中间文件。/tmp目录、/var/tmp，还有应用自身的临时目录。比如某些数据处理任务，跑挂了之后临时文件没清理，每个任务写几个 G 的中间结果，几个任务积攒下来空间就没了。core dump文件也是这类，进程崩了之后默认会在工作目录下生成一个巨大的 core 文件，有些甚至几个 G 一个。

第四类是数据库文件，这个更隐蔽，因为很多人不会想到数据库竟然能“爆满”。MySQL 的 binlog 如果不设expire_logs_days，主从架构下 binlog 是只增不减的，从库追不上主库的时候，积压的 binlog 会持续涨。Redis 开启 AOF 持久化之后，rewrite 不及时的 aof 文件也会迅速膨胀。PostgreSQL 的 WAL 文件同理，归档失败时会无限堆积在pg_wal目录里。

第五类是备份文件。手动备份、自动备份脚本跑完之后，备份文件如果没有定期清理机制，会像滚雪球一样越积越多。我见过有人每天打一次全量数据库备份，保留策略又没配，三个月后 500G 的数据盘还剩 30G，吓一跳才来排查。

1.3 快速定位大文件的实用命令组合

确认根因不能靠猜，得靠工具去“看”。定位大文件的命令组合其实不复杂，但顺序很重要。

第一步，先用du从根目录往下扫，快速看目录层级的大小分布。比如：

du -sh /* 2>/dev/null | sort -rh | head -20

这能看到根目录下每个一级目录占了多少空间，/var、/home、/opt这些大头会立刻浮现。然后再往下一层：

du -h --max-depth=1 /var 2>/dev/null | sort -rh | head -20

这个方法虽然笨，但非常有效，能顺着目录一层层找到真正的大目录。如果扫描速度太慢，也可以用ncdu，这是交互式的磁盘分析工具，上下键浏览很方便。小内存的老机器上跑ncdu，有时候比du更高效，因为它一次性扫完读进内存再让你翻看。

第二步，用find按文件大小直接找大文件：

find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null

这个命令是跨整个文件系统找超过 500M 的文件，-xdev参数很重要，它限定只在当前文件系统内查找，避免去扫描挂载的其他盘或/proc这类虚拟目录。找到的文件列表按大小排一下，基本就能锁定目标了。

第三步，如果磁盘空间明明还有剩余但系统就是不让你写，马上查 inode：

df -i find / -xdev -type f | wc -l

df -i看 inode 使用率，find统计文件总数。如果你发现某个目录下有几十万甚至上百万个文件，那基本就是大量小文件把 inode 吃满了。这类问题处理起来有时候比单纯的大文件更麻烦，因为小文件太多，rm -rf都要跑很久。

2. 应急处理流程：用最小代价把空间抢救回来

2.1 第一原则：先保业务，再谈清理

磁盘爆满之后，系统会进入一种非常脆弱的状态。进程可能无法写日志，数据库无法写入数据，甚至 SSH 登录都可能受影响（因为登录过程也要写 wtmp、lastlog 这些文件）。如果根分区满了，系统还可能变成只读文件系统，那时候很多命令都会报错，局面更加被动。

所以应急处理的第一原则不是“马上全面清理”，而是“先保住业务可用”。具体来说有三条：

• 对于仍能正常执行命令的情况，优先清理最安全、最不会影响业务的文件。
• 宁可先清出 5% 的空间让业务恢复写入能力，再慢慢持续清理，也不要一上来就大规模rm -rf。
• 清理涉及正在使用的文件时，尽量不要直接删除，要考虑文件句柄问题。

“不要直接删除正在写的日志”是我反复跟团队强调的。Nginx、Java 应用这类进程会持有打开的文件句柄，你直接把日志文件rm了，进程并不会释放磁盘空间，因为句柄还在，文件还在被写入，只是从目录结构中消失了。这时候df -h看空间还是满的，但你又找不到对应的文件，非常诡异。正确的做法是把文件内容清空而不是删除，比如用truncate或复制空文件覆盖。

2.2 日志类文件的应急清理实测

日志导致的磁盘爆满，处理起来其实最顺手，因为换作是我，优先清理的就是日志，它丢了不影响业务本身，只是影响排查历史。

系统日志用journald时，可以用以下命令快速压缩和控制大小：

journalctl --disk-usage journalctl --vacuum-size=200M

journalctl --disk-usage会显示当前日志占用的总空间，--vacuum-size=200M会直接清理日志，直到剩余大小不超过 200M。这个命令很好用，不会索引优雅不优雅，它会自动删除最老的日志文件。改完这个之后，顺便把/etc/systemd/journald.conf里的SystemMaxUse=500M这行配置加上，重启systemd-journald服务，下次才不会又涨起来。

对于应用日志和访问日志，应急场景下用truncate清空即可：

truncate -s 0 /var/log/nginx/access.log truncate -s 0 /var/log/app/application.log

truncate -s 0把文件截断为零字节，文件本身还在，进程持有的文件句柄依然有效，后续写入会从零开始继续写。这一点比重定向到/dev/null更安全。>符号重定向是会改变文件 inode 的，虽然也可以，但在某些情况下会触发进程报错，所以我更推荐truncate。

如果日志文件特别多，想按天保留一部分，应急时也可以直接用logrotate强制转一次：

logrotate -f /etc/logrotate.conf

-f是 force 模式，强制执行一次日志轮转，不管当前是否到了轮转条件。这样会把当前日志重命名成带日期的文件，如果配置文件里写了compress，还会压缩掉。之后如果还嫌旧日志占空间，直接删掉那些转出来的旧文件即可。

2.3 容器镜像与临时文件的空间释放

如果du显示/var/lib/docker是大头，那就是容器和镜像的问题。先看现状：

docker system df

这个命令会列出镜像、容器、本地卷、构建缓存各自占用的空间。接下来按需清理：

docker container prune -f docker image prune -f docker image prune -a docker system prune

docker container prune删除所有已停止的容器，docker image prune -f只删除悬空镜像（<none>的临时镜像），image prune -a会删除所有未被容器使用的镜像——这个要谨慎，因为如果你之后想回滚版本，没有标签的旧镜像可能就找不回来了。docker system prune是一次综合清理，会同时清掉停止的容器、未使用的网络、悬空镜像和构建缓存，但它不会动正在运行的容器。

这里有两个细节值得注意。第一个是docker system prune默认带有-a的效果的时候，它会删掉所有未被使用的镜像，不只是悬空的，所以执行之前一定要把当前要保留的镜像确认好。第二个是构建缓存，尤其是用了 Dockerfile 多层构建的项目，/var/lib/docker里的缓存目录会非常大，如果你确认短期内不需要重新构建同一份镜像，清理构建缓存释放的空间通常非常可观。怎么清理缓存？docker builder prune -f或者直接docker system prune都会带上。

临时文件的清理相对简单，但也别有风险。/tmp和/var/tmp下的文件按照约定是可以清理的，但前提是确认没有进程正在使用。如果你不确定，就优先保留最近修改时间一周内的文件：

find /tmp -type f -mtime +7 -delete 2>/dev/null

-mtime +7表示修改时间超过 7 天的文件，这个命令会递归删除。同样，core dump 文件用find / -xdev -type f -name "core.*" -size +100M -delete来清。

2.4 特殊场景：inode 耗尽与数据库文件膨胀

inode 耗尽比磁盘满更难处理，因为空间没满但写不进文件，很多常规排查手段会失效。处理思路是找那些“巨多小文件”的目录，然后成批删除。常见的高危目录包括：

• /var/spool/postfix/maildrop/：用户态 cron 任务如果输出未重定向，邮件会堆积在此，一个文件一行，几百万个很常见
• /tmp：PHP 或 Java 临时会话文件，炸掉的时候数量惊人
• /usr/sbin这类正常目录一般不会出问题，重点还是看/var和/tmp

判断具体是哪个目录文件最多，可以这样：

for d in /var /tmp /home /opt; do echo "$d: $(find $d -xdev -type f 2>/dev/null | wc -l)"; done

找出那个文件数量爆炸的目录，批量清理。比如/var/spool/postfix/maildrop下面全是无用邮件缓存，直接删除即可：

rm -rf /var/spool/postfix/maildrop/*

小文件太多时，rm -rf也可能很慢，有几个办法能加速：用rsync配合空目录同步删除，或者find加-delete参数。前者在某些几百 GB 海量小文件场景下清理速度确实比rm快不少，因为它是遍历删除而不是逐个 stat。

数据库文件膨胀要分清场景。MySQL 的 binlog 如果确认不需要用于恢复或主从追平，可以手动清除到指定序号之前：

PURGE BINARY LOGS TO 'mysql-bin.000010';

或者按时间：

PURGE BINARY LOGS BEFORE NOW();

Redis 的 AOF 在应急时可以临时关掉 rewrite 或直接执行一次BGREWRITEAOF让 aof 压缩。PostgreSQL 的 WAL 堆积，可以先检查归档命令是不是挂了，修复归档之后手动执行pg_switch_wal()和清理pg_wal里已经归档的段文件。

3. 长期预防与优化方案：把问题掐死在发生之前

3.1 日志轮转配置实战：别让日志成为无限增长的黑洞

应急处理完之后，如果不做预防措施，磁盘爆满一定还会再来。日志轮转是第一道防线，也是性价比最高的防护措施。

Linux 自带的logrotate完全可以胜任，不需要额外装什么。以 Nginx 日志为例，在/etc/logrotate.d/nginx写一个配置：

/var/log/nginx/*.log { daily rotate 7 compress missingok notifempty dateext copytruncate su root root }

解释一下关键参数的含义。daily表示每天轮转一次，rotate 7保留最近 7 份转出来的旧日志，compress会压缩转后的日志，dateext让旧日志文件名带上日期，便于回溯查找。copytruncate很重要，进程还在往日志文件里写的话，这个参数会先复制一份再截断原文件，避免日志丢失，而且不需要重启服务，代价是会有一瞬间的日志拷贝开销。如果你的应用支持重开日志文件，一般用postrotate配合通知进程 reopen 更干净，比如 Nginx 的配置就是postrotate里执行nginx -s reopen。但 Java 应用很多不支持 reopen，那就老老实实用copytruncate。

对于 Docker 容器日志，更推荐直接在启动或 daemon 配置里限制：

{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "5" } }

这段配置写在/etc/docker/daemon.json里，重启 Docker 后生效。max-size=50m意味着单个日志文件超过 50MB 就轮转一次，max-file=5最多保留 5 个轮转文件。配合这个配置，每个容器日志最多占用 250MB，这比任何手动清理脚本都可靠。

Java 应用的日志滚配，以 logback 为例：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/data/logs/app-%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>7</maxHistory> </rollingPolicy> </appender>

maxHistory控制保留多少天日志，既防止磁盘爆满，又给你留出查问题的时间窗口。

3.2 监控告警与自动化巡检脚本

预防光靠“记住要清理”是不行的，得靠监控和告警。磁盘使用率低于某个阈值时不觉得，一旦过了 80%，增长速度往往超乎想象。

一个最简单的磁盘监控脚本，用df加条件判断：

#!/bin/bash THRESHOLD=80 df -h | grep '^/dev' | while read line; do mount_point=$(echo $line | awk '{print $6}') usage=$(echo $line | awk '{print $5}' | sed 's/%//') if [ "$usage" -gt "$THRESHOLD" ]; then echo "[$(date)] Warning: $mount_point usage $usage%" # 这里可以接告警渠道，比如 curl 调用你的告警系统接口 fi done df -i | grep '^/dev' | while read line; do mount_point=$(echo $line | awk '{print $6}') inode_usage=$(echo $line | awk '{print $5}' | sed 's/%//') if [ "$inode_usage" -gt "$THRESHOLD" ]; then echo "[$(date)] Warning: inode usage at $mount_point is $inode_usage%" fi done

把脚本放到/usr/local/bin/disk_check.sh，加执行权限，然后写进 crontab 每小时跑一次：

crontab -e 0 * * * * /usr/local/bin/disk_check.sh >> /var/log/disk_check.log 2>&1

这只是最朴素的玩法。实际生产中，如果你用了云监控或自建监控系统（比如 Prometheus 那套），配置一个磁盘使用率超过 85% 的告警规则是基本操作。我个人经验是设置两级：80% 告警提醒该清理了，90% 告警进入响应节奏，这个阈值因人而异，但别设成 99%，等到 99% 才告警基本已经来不及了，很多系统在 95% 以上就会出现明显的性能问题。

对于磁盘空间的历史趋势，我强烈建议留一个简单的记录脚本，每天把df结果追加到一个文件里，可以用一行 crontab 实现：

0 2 * * * echo "$(date +%F-%T) $(df -h / | tail -1)" >> /var/log/disk_history.log

这样哪怕监控系统挂了，回溯问题的时候你还有历史数据可以看，不用凭记忆猜。

3.3 架构层面优化：数据与系统分离，容量规划

当清理和轮转都做到位了，再往上走就是架构层面的优化，这一步能彻底解决“系统盘爆满”这类问题。

最核心的一条是：不要把数据放在系统盘。云服务器通常系统盘只有 40G 到 50G，装完系统、跑几个运行时，空闲空间本来就不宽裕。日志、数据库文件、容器数据目录、应用上传文件，这些都应该规划到独立的数据盘（数据盘单独挂载到/data或者/opt这类路径下）。这样哪怕数据盘真的满了，系统盘依然有空间，SSH 能连上，日志能写，各种紧急操作都能执行——关键时刻这个“能登录”和“不能登录”差别非常大。

操作上，在云厂商控制台购买一块数据盘，挂载到服务器，格式化之后在/etc/fstab里加一行开机自动挂载。常见实践是把数据盘固定在比如/data这个路径下，然后调整应用配置，把日志和数据目录指过去。路径规范一点，后面运维就少一个坑。

第二点是容器相关的目录建议迁移。Docker 默认数据目录在/var/lib/docker，如果 Docker 也装在系统盘上，镜像和容器数据同样会挤占系统盘空间。可以通过修改daemon.json里的>{ "data-root": "/data/docker" }

改完重启 Docker 服务，之后再拉取的镜像都会写到数据盘。注意，这个操作会把已有镜像和容器“留”在原目录，迁移老数据时需要把/var/lib/docker下的内容同步复制过去，或者把镜像导出重导一次，不然已有的容器可能找不到。

第三点是容量评估的底线思维。给一个服务的磁盘配额时，不要只看当前占用，要按“峰值速率 × 保留时长”来估算。比如日志每天涨 2G，你要留 7 天回溯时间，那光日志就要 14G；Docker 镜像构建周期内最多可能有三个版本并存，按最大的算。有了这个估算，你给数据盘扩容时才心里有数，不会出现“刚清理完一个月又满了”的循环。

4. 常见问题与排查技巧实录

4.1 高频坑位：文件句柄、只读文件系统与误删

处理磁盘爆满这些年，我踩过不少坑，也见过不少同行在这个问题上翻车。最经典的一个坑就是文章前面提到的“删了日志但空间没释放”——删的是目录项，进程还攥着文件描述符。排查办法是lsof | grep deleted：

lsof +L1

这个命令会列出所有“已删除但仍被占用”的文件。看到这样的结果，确认是哪个进程占用的，按 PID 找到对应服务，要么重启进程让它释放句柄，要么用truncate清空而不是删除。此时如果磁盘满了，建议用kill <PID>触发进程重启，多数服务重启起来就能把空间释放掉，不过要不要重启还是得看你服务的容错能力。

第二个坑是磁盘满之后根文件系统变成只读。df -h显示满了，执行mkdir、touch都报“Read-only file system”错误，SSH 能连上但什么都干不了。最稳妥的做法是重启进入单用户模式或救援模式，清理空间后恢复。如果不想重启，可以尝试：

mount -o remount,rw /

这条命令把根分区重新挂载为可读写。虽然有些情况下能救命，但如果文件系统已经因为断电或其他原因需要 fsck，强行 remount 可能加重损坏，所以要自己权衡。

第三个坑是手滑删错了东西。清理的时候看到/data/logs很大，一冲动把整个目录删了，结果发现里面既有日志又有正在用的临时数据。这个我没法提供“后悔药”，但可以分享一个流程：删除之前先看清楚目录里是什么，用du、ls确认，不要只看目录名就下手。重要数据目录如果要清理，先做一次快照再操作。云服务商的控制台基本都支持磁盘快照功能，做一次快照成本很低，但关键时刻是真正的保命手段。

4.2 排查速查表：症状、判断与处理对照

把这么多年的排查经验浓缩成一张速查表，方便你在故障现场快速对照：

这张表是我平时处理问题时的思路总结，可以说，只要你冷静下来照着这个顺序排查，磁盘爆满这件事其实不难解决。

4.3 一个真实场景的完整复盘

去年处理过一个比较有代表性的故障，发生在某公司内部的一个模拟项目 X 服务器上。这台机器配置不高，跑了 Nginx、一个 Java 后端和一个 MySQL 实例，系统盘只有 50G。某天上午告警消息弹出来，一看磁盘使用率已经到了 98%。

我先执行了df -h确认是根分区满了，然后du -sh /*扫描，发现/var占了 30 多 G，/home占了 8 个 G。进入/var往下定位，/var/log/journal占了 12G，/var/log/nginx占了 8G，/var/lib/docker占了 10G。继续看 docker 里的情况，是旧镜像和构建缓存堆积。

整个应急过程按顺序执行：

journalctl --vacuum-size=300M truncate -s 0 /var/log/nginx/access.log docker image prune -a -f docker builder prune -f

这几步清掉了大约 20G 的空间，使用率降到 60% 出头。过程大概持续了 15 分钟，服务没有中断过，业务影响控制在“日志暂时无法查询”这个范围内。处理完之后，我顺手把 journald 的SystemMaxUse配上了，Docker 的log-opts限容也加了，Java 应用日志加上了maxHistory，然后给这台机器的数据盘划出一个/data/logs目录，把日志输出路径指过去。从那之后这台机器再没有因为空间问题告警过。

这个案例的特点是：不是“某个单一原因爆满”，而是日志、镜像、构建缓存三个因素叠加导致。这也是为什么我前面反复强调，不要只盯着一个可能原因，要用du一层层把整个目录树过一遍，把所有大块头都找出来再动手。

4.4 运维习惯与工具储备

处理这类问题的速度和平时积累的习惯直接相关。以前我处理一次磁盘爆满可能要折腾半小时以上，后来养成了几个好习惯，效率提升非常明显。

第一个习惯是常备一套“应急命令包”。把定位大文件、清 journal、看 docker 空间、查 deleted 文件这些命令整理成一个 markdown 文件存到本地，或者抄在一张便签纸上，关键时刻不打字直接复制粘贴。别小看这一步，服务器都进不去了还现场搜命令，那感觉太难受了。

第二个习惯是定期巡检。每周看一次磁盘使用率的增量，比如每周一记录df -h结果，对比上周变化，就能大概算出“按这个增长速度，磁盘还有多久会满”。有了这个预估，就不会被动等着告警响，而是提前规划清理或扩容。有段时间我管理的机器数量多，就用脚本把这些服务器的磁盘信息集中输出到一个表格里，巡检效率高很多。

第三个习惯是给每台服务器打标签写备注。比如哪台是数据库专用机、哪台是测试环境、哪台是线上应用，空间告警优先级完全不同。测试环境磁盘满了我可以慢慢处理，线上机器空间满了可能就要立刻响应。有这个底，遇到问题时心里不慌，知道哪些先做哪些后做。

第四个习惯是别把所有鸡蛋放在一个篮子里。重要数据一定要有多级保障：磁盘快照、异地备份、至少最近一份有效的备份文件。很多时候磁盘爆满本身不可怕，可怕的是爆满之后你为了清理空间误删了唯一一份数据备份，那才叫追悔莫及。

最后再分享一点个人的经验

云服务器磁盘爆满的问题，我在实际处理中最大的体会是：九成以上的爆满并不是“突然发生”的，而是积累了很久没人管，只是恰好在你值班的凌晨爆发了。日志增长、镜像堆积、备份膨胀，这些都是有节奏、有速率、可预测的事情。真正专业的运维工作，不是等它爆了再去救火，而是在它还没到 80% 的时候就已经把方案做好了：日志限容配好、监控告警加好、数据目录规划好、定期巡检养成习惯。这套东西看起来不起眼，但能让你少熬很多夜，少背很多锅。如果读完这篇内容，你能至少动手把其中一件事做了——比如给日志加上轮转，或者写个磁盘告警脚本——那这篇文章的价值就达到了。