Linux服务器磁盘空间清理与瘦身：服务器磁盘又爆了？教你彻底瘦身

做外贸独立站或者搞批量内容站的朋友，十有八九都吃过这种暗亏：正跑着投放或者外链爬虫呢，前台突然502报错，数据库无缘无故崩掉，连SSH敲个补全都提示只读。登上去敲个 df -h 一看，好家伙，根目录使用率100%。日常做好 Linux服务器磁盘空间清理与瘦身，真的不是什么高大上的玄学，而是每一个站长保命的必修课。这六年我接手过几十个濒临瘫痪的客户机器，大部分人以为是网站访问量太大撑爆的，其实扒开底下一看，全是各种垃圾日志、无用的缓存和死掉的临时文件。

今天不扯虚的理论，直接把我在生产环境常用的排查与清理路线贴出来，建议收藏备用。

第一步：别瞎删，先揪出到底是哪个目录在作怪

很多人磁盘一满，上来就是一通盲目的 rm -rf，运气好删了点无关痛痒的，运气差直接把环境依赖或者正在跑的数据库表给干碎了。

第一步永远是精准定位。

进入终端，先看整体挂载情况：

df -h

如果看到挂载在 /（根目录）的使用率到了 90% 以上，那就进入根目录，一步步往下揪大文件：

cd /
du -sh * | sort -rh | head -n 10

这条命令会把当前目录下体积最大的前10个文件夹排出来。通常来说，罪魁祸首一般集中在 /var、/tmp、/usr 或者你的建站目录（比如 /www 或 /home）。哪个大就 cd 进哪个目录，重复执行上面这条命令，最多三层就能抓到现行。

第二步：四大“吃盘狂魔”清理实操

根据我的运维经验，80% 的服务器空间不足，都是下面这几个东西在搞鬼。

1. Nginx / Apache 访问日志（尤其警惕垃圾爬虫）

外贸站天天被各种扫描器和流氓爬虫轮番轰炸，如果你的 Web 服务器开了详细的 access log 且没做轮转，一个月堆出几十个G非常正常。

避坑重点： 很多人习惯直接 rm access.log，千万别这么干！如果 Nginx 进程还在占用这个文件，你就算把文件从文件树里删了，磁盘空间也不会释放，反而会变成幽灵文件。

正确清空日志的做法是使用重定向截断：

# 找到日志文件后，直接用空内容覆盖
> /var/log/nginx/access.log
> /var/log/nginx/error.log

如果你用的是宝塔面板或者 LNMP 一键包，去对应的日志目录下找 .log 结尾的大文件，照着清空就行。

2. Systemd 系统的 journal 日志

现在的 CentOS 7+、Ubuntu、Debian 都是用 systemd 管理系统，它默认的 systemd-journald 经常会默默吃掉好几个G的磁盘空间。

输入这条命令看看它吃了多少：

journalctl --disk-usage

如果显示占了几个G，直接下狠手限制，保留最近3天或者只留500M：

# 只保留最近3天的系统日志
journalctl --vacuum-time=3d

# 或者直接限制最大体积为 500M
journalctl --vacuum-size=500M

3. 包管理器缓存与旧内核（特别是 Ubuntu/Debian）

做独立站少不了装各种依赖、升级系统，系统包管理器下载的缓存包如果不清，常年累月能攒下好几个G。

Ubuntu / Debian 系：

apt-get clean           # 清理所有已下载的软件包缓存
apt-get autoremove --purge # 清理没用的孤立依赖和老旧内核

提示：老内核文件通常堆在 /boot 分区，很多小 VPS 的 /boot 分区只有可怜的几百兆，内核更新两次就报警，autoremove 必须跑一下。

CentOS 系：

yum clean all
# 或者清理没有用的旧核心包
package-cleanup --oldkernels --count=1

4. MySQL 的 binlog（二进制日志）

这个是巨多外贸老站长容易忽视的暗雷。很多一键包或默认配置开着二进制日志用来做主从复制，结果单机跑了几年，mysql-bin.00000X 堆了一百多个，每个好几百兆。

去你的 MySQL 目录下（比如 /var/lib/mysql 或 /www/server/data）看看有没有一堆这种文件。

清理方式：别在 Linux 终端直接 rm！容易导致数据库启动报错。 登录 MySQL 控制台执行：

-- 清理某天以前的 binlog
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

如果你只是个单机运行的小站，根本不做读写分离主从同步，直接去 my.cnf 里把 log-bin 这一行注释掉，重启 MySQL，一劳永逸。

第三步：为什么删了文件，磁盘空间还是没变？

这绝对是新手最懵逼的瞬间：“我明明用 rm 删了一个20G的备份压缩包，为什么 df -h 显示还是 100%？”

原因我前面提过：有进程依然在打开并读取这个文件。 Linux 的机制是，只要还有进程拽着这个文件的句柄，它在物理磁盘上占用的块就不会被释放，哪怕它从目录树里消失了。

排查起来非常简单，输入：

lsof | grep deleted

你会看到一串列表，后面全标着 (deleted)。找到对应的进程名（比如 nginx、php-fpm 或者某个 python 脚本），看看它的 PID。

直接重启该服务，或者直接 kill 掉那个进程，被扣押的磁盘空间瞬间就吐出来了：

# 比如是某个僵死的脚本占着
kill -9 <PID>

第四步：给外贸站长的几个长效防爆建议

救火一次很累，天天救火就是架构设计有问题了。想让机器安安稳稳跑，建议做这几件事：

1. 配置 logrotate（日志轮转）：保证不管是 Nginx 还是网站程序的日志，超过 100M 或者每天都自动压缩归档，并且只保留最近7天，过期的自动删。
2. 网站定时备份一定要同步到第三方对象存储：很多人图省事，在服务器本地跑 cron 做全量站点和数据库备份。你本地留一份、两份还行，留上五天，再大的硬盘也得瘫痪。老老实实买个便宜的 S3、Backblaze B2 或者腾讯云 COS，把打包脚本直接打到远程，本地只留当天最新的，备份完立即删除本地包。
3. 设置磁盘使用告警：别等挂了才去查。写个简单的 Shell 脚本，每天定时检查 df -h，当根分区使用率超过 80% 时，给你的 Telegram 机器人或者企业微信发个提醒，花十分钟配置，能免去你大半夜爬起来重启机器的痛苦。

做站就是这样，代码写得再漂亮，底层机器配置一塌糊涂，遇到大促流量一冲照样翻车。先把上面的命令照着跑一遍，看看你的机器到底能榨出多少可用空间来。