Google Cloud Platform托管WordPress下/dev/sda1体积增大原因及缩减方案

• 已删除文件被进程持续持有句柄未释放
  这是小容量系统盘占用异常的最高发原因：如果之前删除过体积较大的日志、临时文件、备份包，但对应的Web服务（Nginx/Apache/PHP-FPM）、定时备份进程没有重启，系统不会回收已删除文件对应的磁盘块，du命令扫描不到这类文件，但df统计的磁盘占用会持续包含这部分空间，单这一项就能占满数GB容量。
• WordPress生态的非核心运行文件堆积
  核心程序运行文件仅762MB的前提下，配套生成的非必要文件很容易堆出数GB占用：
  • 插件、主题升级时残留的安装压缩包，默认存在wp-content/upgrade路径下，不会自动清理
  • 备份插件默认在站点目录本地存储的全量备份文件，单份备份就能达到1-2GB，多份历史备份累计很容易突破数GB
  • 开启WordPress调试模式后生成的debug.log，遇到插件兼容错误、接口请求异常时，日志文件可以持续涨到数GB
• 系统层日志与缓存堆积
  GCP Compute Engine默认的官方系统镜像本身仅占约2GB空间，不存在系统自带大文件导致占满空间的情况，异常占用基本来自未配置自动清理的日志与缓存：
  • 操作系统默认的journal日志如果没配置轮转策略，运行数月就能攒下2-3GB的占用
  • apt包管理器下载的安装缓存，存在/var/cache/apt/archives路径下，长期不清理能占1-2GB
  • Web服务的访问日志、错误日志如果没配置自动切割，长期累积可以涨到数GB
• 路径挂载错位导致的空间统计偏差
  如果之前磁盘扩容、挂载点配置出错，原本挂在其他独立分区的大文件实际落在/dev/sda1上，但目录扫描时因为路径偏移找不到对应的文件，也会出现总占用和可见文件大小对不上的情况

• 第一步：定位被进程占用的无主已删除文件
  执行命令lsof +L1 列出所有被进程持有但已从文件系统删除的大文件，记录对应的进程PID，重启对应的服务进程即可立即回收这部分占用的磁盘空间。
• 第二步：逐层扫描目录定位实际大文件
  从根路径开始执行命令du -h --max-depth=1 / 逐层向下扫描，重点排查几个高占用路径：
  • WordPress站点目录下的wp-content/backups、wp-content/upgrade、wp-content/uploads、wp-content/debug.log
  • 系统日志路径/var/log下的单个体积超过100MB的日志文件
  • 系统缓存路径/var/cache/apt/、/var/lib/snapd/cache
• 第三步：执行针对性清理
  • 删除站点目录下存储的本地全量备份文件，将备份任务的存储路径切换到外部对象存储，不要占用系统盘空间
  • 对超过500MB的大日志文件执行清空操作，配置logrotate实现日志自动按大小切割、历史日志自动压缩
  • 执行apt clean清空apt安装包缓存，执行journalctl --vacuum-size=200M将系统日志总占用限制在200MB以内
  • 删除残留的插件、主题安装压缩包等临时文件
• 第四步：校验空间释放效果
  执行df -h /dev/sda1确认剩余空间，如果清理后空间没有达到预期，重启一次实例即可回收所有未被正常释放的磁盘块。

内容的提问来源于stack exchange，提问作者Chris