服务器一进去发现磁盘已经用了130G，别慌，先执行df -h确认哪个分区满了，再用du -sh 从根目录往下排查，通常日志文件、系统缓存、旧内核和Docker镜像就是占用大户。
快速定位130G空间被谁吃了
很多运维新手一看到磁盘占用高就慌了，其实只要按顺序执行几个命令,就能把元凶揪出来。
用df -h看整体分区情况
登录服务器后第一件事，敲df -h，重点关注根分区、/var、/home等挂载点的使用率，如果某个分区已经用了130G而总容量只有200G，那确实危险，如果总容量1T，用了130G其实是正常范围，但你既然问了“怎么办”,说明剩余空间告急或者异常增长。
用du逐层定位大目录
从根目录开始，du -sh / 会列出每个一级目录的大小，注意，/proc、/sys这些虚拟文件系统可以忽略，然后针对大的目录继续深入，比如du -sh /var/，层层递进，推荐用du -sh /var/log /var/lib /tmp /home /root /opt这些常见目录快速判断。
实战技巧：du -sh /var/log/ 如果显示几十G，那日志就是问题所在，如果/var/lib/docker特别大,说明容器镜像和卷占了空间。
直接找超过1G的大文件
find / -type f -size +1G -exec ls -lh {} ; 这条命令能列出所有大于1G的文件，帮你一眼看到底是什么在吃空间，注意，执行时间可能较长,建议在业务低峰期运行。
清理日志文件，释放几十G空间
日志文件是服务器空间爆满的头号元凶，尤其是web服务器、数据库和系统日志,默认保留策略往往不合理。
系统日志集中清理
/var/log 目录下的 messages、secure、cron、maillog 等文件，如果运行多年且没有轮转，轻松就能堆到几十G，行业共识认为，超过70%的服务器磁盘报警都与日志未配置轮转有关
。
操作步骤：
- 先查看日志大小：
ls -lh /var/log/messages - 确认应用正常后，清空或压缩：
> /var/log/messages直接清空，或者用gzip归档旧的日志文件。 - 立即开启日志轮转：
logrotate -f /etc/logrotate.conf强制轮转一次，然后检查/etc/logrotate.d/下的配置，确保weekly或daily，并设置rotate 4（保留4份）等合理参数。
注意：/var/log下的journal目录如果是systemd-journald生成的，大小可能也很惊人，用journalctl --disk-usage查看，然后设置SystemMaxUse=500M限制其最大占用。
Web和应用日志清理
Nginx、Apache、Tomcat、Java应用等日志如果不做切割，一天就能产出几个G，建议用logrotate统一管理，或者写脚本按天自动归档，对于已经堆积的日志，直接删除超过30天的老文件：find /var/log/nginx -name ".log" -mtime +30 -delete。
数据库日志清理
MySQL的binlog是常见空间杀手，在MySQL命令行执行SHOW BINARY LOGS;查看有哪些binlog，确认已备份后清理：PURGE BINARY LOGS BEFORE '2026-01-01 00:00:00';，同时检查slow_query_log和general_log是否开启，没必要的就关掉，PostgreSQL的WAL日志如果归档不及时也会膨胀，建议设置wal_keep_segments为合理值。
清理系统缓存和旧内核
包管理器缓存和旧内核是另一个容易被忽视的空间占用点。
清除包管理器缓存
- CentOS/RHEL：
yum clean all清理缓存，yum remove --oldkernels删除旧内核（只保留最近两个）。 - Ubuntu/Debian：
apt-get clean和apt-get autoremove,后者会删除不再需要的依赖包和旧内核。 - 检查/boot分区：如果
/boot单独分区，旧内核文件很容易占满它。
rpm -qa kernel | grep -v $(uname -r) | xargs yum remove -y
清理临时文件
/tmp 目录通常挂载在内存或独立分区，但有些系统会把/tmp指向硬盘。/var/tmp 也是持久化临时目录。find /tmp -type f -atime +7 -delete 删除7天未访问的文件。/home下用户目录的.cache、.local/share/Trash 等垃圾文件也可以手动清理。
Docker容器与镜像空间清理
如果你用Docker，镜像、容器、卷和构建缓存占用的空间往往比想象中大得多，据统计，使用Docker的服务器中，较大比例的空间问题都来自悬空镜像和未清理的构建缓存。
一键清理：docker system prune -a
这个命令会删除所有停止的容器、未使用的网络、悬空镜像，以及构建缓存，加上-a会删除所有未被使用的镜像（包括没有标签的）,执行前确认没有需要保留的停止容器。
手动检查大镜像和卷
docker images 列出所有镜像，按SIZE排序。docker volume ls 查看卷，如果容器已删除而卷还在，这些卷会占用空间。docker volume prune 清理无用卷。
限制日志文件大小
Docker容器默认会无限保留stdout日志，这些日志存在/var/lib/docker/containers/<id>/下，每个容器可能轻松达到几个G，在docker run时加参数--log-opt max-size=10m --log-opt max-file=3，或者全局修改/etc/docker/daemon.json：{"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}},然后重启Docker。
预防130G再次出现
清理完空间只是第一步，如果不建立长效机制,用不了多久又会爆满。
配置日志轮转并监控
/etc/logrotate.conf 和/etc/logrotate.d/ 下的配置要针对所有关键日志设置，建议每日轮转，保留7-14天，同时用cron或systemd timer定期执行
du检查，配合df报警脚本。
使用磁盘空间监控工具
ncdu 是一个命令行下的磁盘分析工具，交互式界面，可以快速找到大目录。du命令结合sort也能排序，更高级的可以用inotify监控特定目录的文件变化。
规划合理的分区大小
在服务器初始化时，就根据业务规划好分区：/var独立分区并给大空间，/home如果不需要可以划小，/tmp可以挂载为tmpfs限制大小，这样即使某个分区满了,也不会影响根分区。
总结一下：服务器一进去就是130G，核心思路就是先定位，再清理，最后建立长效机制，日志、缓存、旧内核、Docker镜像这四个方向占住了绝大多数场景,按顺序排查就能快速解决问题。
服务器磁盘空间清理常见问题解答
服务器一进去就是130g，但用du找不到大文件，为什么？
可能是被已删除但仍在被进程占用的文件“吃”掉的，用lsof | grep deleted 查看，确认后重启对应进程或kill -HUP释放文件句柄,这种情况在日志文件被误删除但进程未重启时尤其常见。
清理服务器日志会影响正常业务吗？
仅清理已归档的日志或轮转过的日志不会影响业务，直接清空正在写入的日志文件（如> /var/log/messages）不会导致服务中断，但最好先停止服务或使用kill -USR1让进程重新打开日志文件，对于数据库日志,清理binlog前务必确认已备份且不再需要。
如何在不停机的情况下清理130G的Docker空间？
使用docker system prune时加上--force不会停止运行中的容器，但会删除停止的容器和悬空镜像，如果担心影响，可以先用docker system df查看空间详情，再逐步清理：docker image prune清理悬空镜像，docker volume prune清理无用卷,这些操作对运行中的容器无影响。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e4%b8%ba%e4%bb%80%e4%b9%88%e6%9c%8d%e5%8a%a1%e5%99%a8%e4%b8%80%e8%bf%9b%e5%8e%bb%e5%b0%b1%e6%98%af130g%ef%bc%8c%e6%80%8e%e4%b9%88%e8%a7%a3%e5%86%b3%ef%bc%9f/
