【唐诗】《登幽州臺歌》 陳子昂：前不見古人，後不見來者。念天地之悠悠，獨愴然而涕下。

永夜

没有不值得去解决的问题，也没有不值得去学习的技术！

阿里云 ECS 系统盘占用超过 80%：清理 PHP、Nginx、Redis 升级残留后从 81% 降至 42%

【图 1：阿里云 ECS 系统盘使用率超过 80% 的告警邮件】

作者：

永夜

在

Post Views: 0

最近阿里云 ECS 开始持续发送系统盘使用率告警。

这台服务器的系统盘只有 20GB。此前升级 PHP、Nginx、Redis，以及处理 WordPress 历史文章时，为了测试、验证和方便回滚，服务器上陆续留下了一些源码目录、构建目录、升级备份和历史处理数据。

单独看每一项似乎都不算特别夸张，但长期累积下来，最终还是把系统盘使用率推到了 80% 以上。

由于系统盘超过告警阈值后，大约每隔一小时就会再次收到一次通知，因此今天优先处理这个问题。

整个过程中没有直接进行大范围删除，而是先确认真正占用系统盘的目录，再确认 PHP、Nginx、Redis 当前实际运行路径，之后逐项删除已经失去作用的升级残留。

最终，系统盘使用率从最初的 81% 降到了 42%，同时确认 Nginx、PHP-FPM 和 Redis 均保持正常运行。

收到系统盘使用率告警

阿里云监控邮件显示，ECS 的 /dev/vda1 已经触发“系统磁盘使用率过高”告警。

邮件中的告警条件为连续满足 5 次、平均值达到或超过 80%，当时监控显示的当前值约为 80.35%。

【图 1：阿里云 ECS 系统盘使用率超过 80% 的告警邮件】
【图 1：阿里云 ECS 系统盘使用率超过 80% 的告警邮件】

登录服务器后首先确认系统盘：

Bash
df -hT /

结果如下：

Plaintext
文件系统       类型  容量  已用  可用 已用% 挂载点
/dev/vda1      ext4   20G   15G  3.7G   81% /

系统盘总容量只有 20GB，已经使用约 15GB，可用空间只剩下 3.7GB。

【图 2：清理前系统盘使用率达到 81%】
【图 2：清理前系统盘使用率达到 81%】

同时检查 inode：

Bash
df -ih /

inode 使用率只有约 13%，因此这次并不是大量小文件导致 inode 紧张，而是单纯的磁盘容量占用问题。

定位主要占用目录

继续查看系统盘一级目录：

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

其中比较明显的是：

Plaintext
2.3G    /var
4.8G    /root
5.7G    /usr
15G     /

随后进一步查看 /root：

Bash
du -x -h --max-depth=1 /root 2>/dev/null | sort -h

很快就发现了一批非常熟悉的目录：

Plaintext
46M     /root/redis-8.10.0-core-stage
224M    /root/php85-configure-preflight-20260804
226M    /root/php85-configure-preflight-system-iconv-20260804
304M    /root/tools
333M    /root/redis-cutover-backup-20260805-193515
334M    /root/redis-upgrade-backup-20260805-185250
554M    /root/redis-8.10.0
1.8G    /root/nginx-build-1.30.4-openssl-3.5.7
4.8G    /root

这些基本都是此前升级 PHP 8.5、Nginx 1.30.4、OpenSSL 3.5.7 和 Redis 8.10.0 时留下的测试、构建和回滚文件。

【图 3：/root 中大量 PHP、Nginx、Redis 升级遗留目录】
【图 3：/root 中大量 PHP、Nginx、Redis 升级遗留目录】

此外，/usr/local 中还存在一个旧 PHP 完整目录：

Plaintext
483M    /usr/local/php-8.1.19-before-php85-20260804-182956

从名字就可以看出，这是升级 PHP 8.5 之前保存的 PHP 8.1.19 旧版本。

不过，名字带有 backup、before 或版本号，并不意味着一定可以直接删除。

在真正清理之前，还是先确认了当前生产环境实际使用的版本。

先确认 PHP、Nginx 和 Redis 当前运行版本

PHP：

Bash
/usr/local/php/bin/php -v
readlink -f /proc/$(pgrep -o php-fpm)/exe

结果确认当前已经运行：

Plaintext
PHP 8.5.9
/usr/local/php/sbin/php-fpm

Nginx：

Bash
/usr/local/nginx/sbin/nginx -V 2>&1
readlink -f /proc/$(pgrep -o nginx)/exe

当前版本为：

Plaintext
nginx/1.30.4
OpenSSL 3.5.7
/usr/local/nginx/sbin/nginx

Redis：

Bash
/usr/local/redis/bin/redis-server --version
readlink -f /proc/$(pgrep -o redis-server)/exe

当前运行：

Plaintext
Redis server v=8.10.0
/usr/local/redis/bin/redis-server

也就是说，真正的生产运行文件都已经位于：

Plaintext
/usr/local/php
/usr/local/nginx
/usr/local/redis

而 /root 下那些构建目录、源码目录和升级备份已经不参与当前运行。

这之后才开始正式清理。

意外发现 PHP-FPM 日志已经达到 824MB

检查系统盘上的超大文件时，又发现了一个额外问题：

Plaintext
2147483648  /swapfile
863869254   /usr/local/php/var/log/php-fpm.log

/swapfile 是 2GB 的 Swap 文件，属于正常系统配置，没有必要为了释放空间而删除。

真正异常的是：

Plaintext
/usr/local/php/var/log/php-fpm.log

这个 PHP-FPM 日志已经达到 824MB。

继续查看最近 100 行：

Bash
tail -n 100 /usr/local/php/var/log/php-fpm.log

可以看到日志几乎一直在重复：

Plaintext
PHP Deprecated: Method SplObjectStorage::attach() is deprecated since 8.5
PHP Deprecated: Method SplObjectStorage::contains() is deprecated since 8.5

来源是 WordPress 的 Organize Series 插件。

【图 4：PHP-FPM 日志达到 824MB，并不断出现 PHP 8.5 Deprecated 信息】
【图 4：PHP-FPM 日志达到 824MB，并不断出现 PHP 8.5 Deprecated 信息】

这个 PHP 8.5 兼容性问题此前已经反馈给插件官方，后续版本会进行修复，因此这数百 MB 的重复日志没有继续保留的必要。

不过 PHP-FPM 当前仍然打开着日志文件，因此没有直接使用 rm 删除，而是清空文件内容：

Bash
truncate -s 0 /usr/local/php/var/log/php-fpm.log

执行后：

Bash
df -hT /

系统盘立即从：

Plaintext
81%

降到了：

Plaintext
77%

仅这一项就释放了大约 800MB。

删除 Nginx 升级构建目录

首先处理最大的升级残留：

Plaintext
/root/nginx-build-1.30.4-openssl-3.5.7

这个目录约有 1.8GB。

当前 Nginx 已确认运行的是 /usr/local/nginx/sbin/nginx，因此这个目录已经只是当时编译 Nginx 1.30.4 和 OpenSSL 3.5.7 的工作区。

删除：

Bash
rm -rf -- /root/nginx-build-1.30.4-openssl-3.5.7

之后系统盘使用率从 77% 直接降到了 67%。

另外还有一个约 5.9MB 的 Nginx 升级备份目录：

Plaintext
/root/nginx-upgrade-backup-20260805-172623

由于当前 Nginx 已经稳定运行，也一并清理。

删除 Redis 8.10.0 升级残留

Redis 升级留下的文件也不少。

首先是源码和编译目录：

Plaintext
554M    /root/redis-8.10.0

删除：

Bash
rm -rf -- /root/redis-8.10.0

随后继续处理两个升级回滚目录：

Plaintext
334M    /root/redis-upgrade-backup-20260805-185250
333M    /root/redis-cutover-backup-20260805-193515

分别删除：

Bash
rm -rf -- /root/redis-upgrade-backup-20260805-185250
Bash
rm -rf -- /root/redis-cutover-backup-20260805-193515

以及升级过程中留下的临时 staging 目录：

Plaintext
46M    /root/redis-8.10.0-core-stage

删除：

Bash
rm -rf -- /root/redis-8.10.0-core-stage

处理完这一批后，系统盘已经下降到了约 60%。

删除 PHP 8.5 升级遗留文件

PHP 8.5 升级也留下了两个 configure preflight 工作目录：

Plaintext
224M    /root/php85-configure-preflight-20260804
226M    /root/php85-configure-preflight-system-iconv-20260804

这两个目录只是升级前进行 configure 验证时使用的临时工作区，因此分别删除：

Bash
rm -rf -- /root/php85-configure-preflight-20260804
Bash
rm -rf -- /root/php85-configure-preflight-system-iconv-20260804

随后再处理：

Plaintext
/usr/local/php-8.1.19-before-php85-20260804-182956

这个约 483MB 的目录是升级 PHP 8.5 前保存下来的 PHP 8.1.19 完整版本。

当前 PHP 8.5.9 已经稳定运行在：

Plaintext
/usr/local/php

因此继续删除：

Bash
rm -rf -- /usr/local/php-8.1.19-before-php85-20260804-182956

处理完成后，系统盘已经降低到 55%。

清理两个旧 OneinStack 归档

重新查看 /root 后，还剩下两个比较大的压缩包：

Plaintext
432M    /root/oneinstack-backup-20260804-155349.tar.gz
390M    /root/oneinstack-full.tar.gz

第一个是 2026 年 8 月 4 日 PHP 8.5 升级前后留下的 OneinStack 备份。

当前 /root/oneinstack 仍然存在，PHP 8.5 也已经完成升级，因此这个临时回滚包已经没有继续保留的必要：

Bash
rm -f -- /root/oneinstack-backup-20260804-155349.tar.gz

另一个 oneinstack-full.tar.gz 是 2023 年留下来的旧归档。

删除之前先查看内容：

Bash
tar -tzf /root/oneinstack-full.tar.gz | head -50

里面主要是：

Plaintext
oneinstack/
oneinstack/install.sh
oneinstack/src/php-8.1.19.tar.gz
oneinstack/src/nginx-1.24.0.tar.gz
oneinstack/src/redis-7.0.11.tar.gz
oneinstack/src/openssl-1.1.1t.tar.gz
...

本质上是一整套 2023 年时期的旧 OneinStack 源码和安装包归档。

服务器当前仍然保留着现在实际使用的 /root/oneinstack，因此这个旧归档也已经没有实际用途：

Bash
rm -f -- /root/oneinstack-full.tar.gz

系统盘继续下降到了 51%。

systemd journal 又占用了约 2GB

原本以为这次清理已经差不多结束，但重新查看 /var/log：

Bash
du -ahx /var/log 2>/dev/null | sort -h | tail -30

发现：

Plaintext
2.0G    /var/log
2.0G    /var/log/journal

也就是说，整个 /var/log 的主要占用几乎都来自 systemd journal。

这类文件不适合直接手工 rm，因此使用 journalctl 自带的清理机制：

Bash
journalctl --vacuum-size=500M

执行后系统返回：

Plaintext
Vacuuming done, freed 1.4G of archived journals

随后检查：

Bash
journalctl --disk-usage

结果为：

Plaintext
Archived and active journals take up 488.0M in the file system.
【图 5：清理 systemd journal 后释放 1.4GB，剩余约 488MB】
【图 5：清理 systemd journal 后释放 1.4GB，剩余约 488MB】

这一步又释放了 1.4GB。

系统盘使用率从 51% 直接降到了：

Plaintext
43%

原本也考虑过进一步给 journald 增加固定的磁盘容量限制，不过现在系统盘空间已经非常充裕，继续修改长期系统配置反而有些节外生枝，因此暂时没有做额外调整。

删除已经完成使命的历史文章处理目录

清理接近尾声时，又重新检查了 /root：

Plaintext
304M    /root/tools
304M    /root/tools/wordpress-ai-excerpt-backfill
304M    /root/tools/wordpress-ai-excerpt-backfill/data
304M    /root/tools/wordpress-ai-excerpt-backfill/data/raw

这里的 wordpress-ai-excerpt-backfill 是此前处理 WordPress 历史文章时上传到服务器上的运行副本。

真正的 Git 仓库保存在本地电脑上，需要修改代码时也是在本地完成后，再通过 SSH 上传至服务器执行。

而目前历史文章处理阶段已经结束。

以后如果增加新的语言，例如日语，也不准备继续沿用这一套历史迁移流程，因为这个项目本身承载了太多过去的兼容和历史遗留逻辑。

删除之前再次确认：

Bash
pgrep -af 'wordpress-ai-excerpt-backfill|history-migration'

没有相关进程。

同时检查 cron 和 systemd，也没有任何地方引用：

Plaintext
/root/tools/wordpress-ai-excerpt-backfill

因此直接删除整个服务器运行副本：

Bash
rm -rf -- /root/tools/wordpress-ai-excerpt-backfill

完成后系统盘进一步下降到了：

Plaintext
42%

最终验证生产服务

删除了这么多升级备份和历史工作目录后，最后还是需要确认生产服务没有受到影响。

首先检查 Nginx：

Bash
service nginx status

结果：

Plaintext
Active: active (running)

并且 master process 仍然使用：

Plaintext
/usr/local/nginx/sbin/nginx

PHP-FPM：

Bash
pgrep -af php-fpm | head

可以正常看到：

Plaintext
php-fpm: master process (/usr/local/php/etc/php-fpm.conf)
php-fpm: pool www
...

Redis：

Bash
/usr/local/redis/bin/redis-cli ping

返回：

Plaintext
PONG

最终再次查看系统盘：

Bash
df -hT /

结果：

Plaintext
文件系统       类型  容量  已用  可用 已用% 挂载点
/dev/vda1      ext4   20G  7.7G   11G   42% /
【图 6：最终系统盘降至 42%，Nginx、PHP-FPM 和 Redis 均正常】
【图 6：最终系统盘降至 42%，Nginx、PHP-FPM 和 Redis 均正常】

从 81% 降到 42%

这次清理开始时：

Plaintext
/dev/vda1
总容量：20G
已用：15G
可用：3.7G
使用率：81%

完成后：

Plaintext
/dev/vda1
总容量：20G
已用：7.7G
可用：11G
使用率：42%

整体释放了大约 7GB 的系统盘空间。

这次占用并不是由某一个文件单独造成，而是几个因素长期累积的结果：

  • Nginx + OpenSSL 升级留下约 1.8GB 的构建工作区；
  • Redis 升级留下源码、staging 和多个回滚备份；
  • PHP 8.5 升级留下 preflight 工作目录和完整 PHP 8.1.19 旧版本；
  • PHP-FPM 因 PHP 8.5 Deprecated 信息累计出 824MB 日志；
  • systemd journal 长期积累到约 2GB；
  • 历史 OneinStack 归档继续占用数百 MB；
  • 已结束的 WordPress 历史文章处理目录仍然保留在服务器上。

这些内容大多不是“垃圾文件”，而是在当时升级、调试和回滚阶段都有明确用途。

真正的问题在于：阶段完成后，没有及时把已经失去作用的临时资源收掉。

总结

这次处理最大的体会仍然是，生产服务器清理磁盘时，最好不要看到大文件就直接删除。

尤其像 PHP、Nginx、Redis 这种基础服务，升级期间留下的源码目录和备份文件，在当时都承担着回滚作用。

比较稳妥的顺序还是：

先确认磁盘到底被什么占用；

再确认当前生产服务实际使用的版本和路径；

确认旧目录不再参与运行；

逐项删除，并持续观察磁盘变化；

最后重新验证所有核心服务。

经过这一轮清理，系统盘从 81% 降到了 42%，每小时反复出现的系统盘使用率告警也失去了触发条件。

而且相比单纯“清掉几个大文件”，这一次还顺带把 PHP-FPM 异常日志、历史 journal、升级回滚目录和已经结束使命的服务器工作目录全部梳理了一遍。

对于一台已经运行多年的生产服务器来说，这种阶段性的收尾清理，可能比继续寻找更多零碎文件更有价值。

Linux 服务器运维、部署与线上故障排查

如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。

适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查

服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持

如需咨询，请联系我，并注明：Linux 运维咨询。

联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章