1. 项目概述为什么“查看磁盘空间”是运维的必修课“磁盘又满了”——这大概是每个运维工程师或系统管理员最常听到的警报之一。在CentOS 7这类服务器操作系统中磁盘空间管理绝非简单的“看一眼”那么简单。它直接关系到应用的稳定性、服务的可用性甚至是数据的安全性。一个被占满的根分区/可能导致系统无法写入日志、用户无法登录、数据库服务崩溃进而引发线上事故。因此掌握一套系统、高效的磁盘空间查看与分析流程是每一位与Linux服务器打交道的人的必备技能。这个项目标题“CentOS 7查看磁盘空间”看似基础实则内涵丰富。它不仅仅是执行一两条命令而是一个包含初步概览、深度定位、问题分析和解决方案的完整工作流。很多新手在遇到“No space left on device”错误时只会用df -h看一眼发现根分区100%后便束手无策或者盲目删除文件可能误删关键数据。资深运维的视角则不同我们会像侦探一样从宏观到微观层层深入精准定位到是哪个目录、哪个用户、甚至哪个进程在“疯狂吞噬”磁盘并给出安全、有效的处理方案。本文将基于CentOS 7拆解这套完整的排查方法论并分享大量实战中积累的“避坑”经验。2. 核心工具链解析df、du及其背后的文件系统原理在CentOS 7中查看磁盘空间主要依赖两个核心命令df和du。理解它们的差异和工作原理是高效排查的基础。2.1 df文件系统磁盘空间使用情况统计dfdisk free命令用于报告文件系统的整体磁盘空间使用情况。它的数据来源是文件系统的超级块superblock读取速度快反映的是挂载点如//home的全局情况。最常用的命令是df -h-h参数代表“human-readable”以K、M、G为单位显示更直观。df -h输出示例Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 45G 2.9G 94% / devtmpfs 3.9G 0 3.9G 0% /dev tmpfs 3.9G 0 3.9G 0% /dev/shm tmpfs 3.9G 8.5M 3.9G 1% /run tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup /dev/vdb1 100G 30G 71G 30% /data关键列解读Filesystem: 磁盘分区或设备名如/dev/vda1。Mounted on: 该分区挂载到的目录路径即挂载点。Use%: 使用百分比这是我们需要重点关注的核心指标。通常当使用率超过80%时就需要警惕超过90%则应立即处理。注意df看到的“已用空间”包含了为root用户保留的磁盘空间默认为5%。这意味着即使df显示使用100%root用户仍可能有一定空间进行紧急操作如删除文件以释放空间。可以使用tune2fs -l /dev/vda1 | grep ‘Reserved block count’查看保留块信息。2.2 du估算文件和目录的磁盘使用空间dudisk usage命令用于估算指定文件或目录占用的磁盘空间。它通过递归统计目录下所有文件的大小来计算因此对于大目录执行可能较慢。常用命令组合du -sh /path/to/directory: 汇总-s显示指定目录的总大小并以易读格式-h输出。例如du -sh /var/log。du -h --max-depth1 /path: 显示指定目录下一级子目录的大小便于快速定位大目录。例如du -h --max-depth1 /home。2.3 df与du结果不一致的深度解析这是排查磁盘空间问题时最经典的困惑“为什么df显示磁盘快满了但用du统计根目录所有文件加起来却差很多” 这通常不是命令错误而是由以下一个或多个原因造成的已删除文件但未被释放文件被进程占用这是最常见的原因。当一个文件被进程打开时即使你使用rm命令删除它只要进程没有关闭该文件句柄磁盘空间就不会被释放。df命令基于文件系统统计会认为空间仍被占用而du命令遍历目录树找不到已删除的文件名所以不计入。排查命令lsof | grep deleted。这条命令会列出所有已被删除但仍被进程占用的文件。找到对应的进程IDPID重启该进程即可释放空间。实战心得Web服务器如Nginx、Apache的日志文件、数据库如MySQL的日志或表空间文件如果配置了日志切割但切割后没有正确通知服务重启或重新打开日志极易出现此问题。一个生产环境案例是某Java应用打印的GC日志文件被持续写入管理员rm了日志文件但未重启应用导致磁盘空间在df视角下持续减少直至告警而du却找不到“元凶”。文件系统元数据占用du统计的是文件数据块而df统计的是整个数据块的使用包括inode表、日志等元数据。对于存在海量小文件的系统例如邮件服务器、Docker容器层inode可能先于磁盘空间耗尽。此时df -i就派上用场了。排查命令df -i。查看inode使用情况。如果IUse%达到100%即使df -h显示还有空间也无法创建新文件或目录。解决方案查找并清理海量小文件目录或考虑使用存储效率更高的文件系统或归档方式。隐藏空间LVM快照、磁盘配额、稀疏文件LVM快照如果创建了LVM逻辑卷的快照快照会占用空间来保存原始数据的变更这部分空间在du中不易直接体现。磁盘配额针对用户或用户组的磁盘使用限制超出配额后即使df显示有空间也无法写入。稀疏文件像虚拟机磁盘文件如.qcow2或数据库文件它们声明的大小可能很大但实际占用的数据块可能很小。du默认显示实际占用而df在有些情况下可能受其影响。3. 系统化排查流程从报警到定位的实战指南当监控系统报警磁盘空间不足或你手动发现df -h使用率过高时应遵循一个清晰的排查路径避免盲目操作。3.1 第一步宏观概览确定问题范围首先使用df -hT-T显示文件系统类型查看所有挂载点的使用情况。这能帮你快速判断是哪个具体的分区如根分区/、数据分区/data、家目录分区/home出了问题。问题往往集中在//var/home这几个地方。3.2 第二步逐层深入定位罪魁祸首假设问题出在根分区/。接下来使用du命令像“剥洋葱”一样逐层定位大目录。一级定位du -h --max-depth1 / 2/dev/null | sort -rh | head -20这条命令组合非常强大du统计根目录下一级目录大小2/dev/null忽略权限不足产生的错误信息sort -rh按人类可读的数字逆序排序head -20显示最大的前20个结果。通常你会看到/usr/var/home名列前茅。假设/var最大。二级定位du -h --max-depth1 /var 2/dev/null | sort -rh | head -20进入/var目录继续分析。常见“大户”是/var/log日志、/var/lib应用数据如Docker、MySQL、/var/cache缓存。三级定位继续使用相同命令深入可疑目录直到定位到具体的文件或目录。例如最终可能发现是/var/lib/docker/containers/.../...-json.log某个Docker容器日志暴涨或者是/var/lib/mysql下的某个数据库文件巨大。3.3 第三步特殊场景与高级定位技巧如果通过du逐层查找仍然无法匹配df显示的巨大空间缺口就需要启用“高级侦查模式”。查找被删除但未释放的文件lsof L1 | grep -i deleted # 或者更精确地针对某个挂载点 lsof / | grep deleted找到PID和文件描述符后可以决定是重启对应服务还是通过/proc/PID/fd/FD的方式清空文件风险较高需谨慎。检查inode是否耗尽df -i如果IUse%100%需要查找inode消耗大户# 查找目录下文件数量非大小 find /path/to/search -type f | wc -l # 或者查找包含文件最多的目录 find / -xdev -type f | cut -d / -f 2 | sort | uniq -c | sort -rn | head -20使用ncdu进行交互式可视化分析 对于不习惯命令行的用户ncdu(NCurses Disk Usage) 工具是神器。它提供字符图形界面可以交互式地浏览目录、排序、删除文件。yum install -y ncdu # 安装 ncdu / # 扫描根目录使用方向键浏览按d删除选中项界面直观不易误操作。4. 常见问题场景与针对性解决方案实录根据网络热词和常见问题我整理了以下几个高频场景及其处理方案。4.1 场景一日志文件暴涨现象/var/log目录巨大特别是messagessecure 或某个特定应用日志如nginx/access.log。解决方案日志轮替Log Rotation这是治本之策。CentOS 7默认使用logrotate服务。检查/etc/logrotate.conf和/etc/logrotate.d/下的配置文件确保相关日志配置了合理的轮替策略如按日切割、保留7天、压缩旧日志。手动清理历史日志对于已经产生的巨大日志文件如果无需保留可以使用truncate或:命令安全清空而非直接rm避免影响正在写入的进程。# 清空文件内容但保留文件inode进程可继续写入 : /var/log/myservice.log # 或 truncate -s 0 /var/log/myservice.log重要警告绝对不要直接rm -f /var/log/myservice.log然后重启服务。对于正在被进程打开的文件直接删除会导致磁盘空间不被释放问题2.3所述。应先清空内容或配置好日志轮替后重启服务。4.2 场景二Docker/容器存储占用失控现象/var/lib/docker目录占用巨大。Docker的镜像、容器、卷、日志默认都存储于此。解决方案清理无用资源# 删除所有已停止的容器、未被任何容器引用的网络、构建缓存等 docker system prune -a -f # 删除所有未被使用的镜像、容器、卷、网络 docker system prune --volumes -f限制容器日志大小这是导致空间暴涨的元凶之一。在docker run时或docker-compose.yml中为容器配置日志驱动和大小限制。# docker-compose.yml 示例 services: myapp: image: myimage logging: driver: json-file options: max-size: 10m # 单个日志文件最大10MB max-file: 3 # 最多保留3个日志文件迁移Docker数据目录如果/分区空间实在紧张可以考虑将Docker的根目录迁移到大容量分区。这需要停止Docker服务移动数据并修改/etc/docker/daemon.json中的>-- 在MySQL命令行中执行 PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY); -- 清理7天前的日志 -- 或设置过期时间需MySQL 5.7或MariaDB 10.2 SET GLOBAL binlog_expire_logs_seconds 604800; -- 7天过期优化表与清理碎片对于InnoDB表可以使用OPTIMIZE TABLE table_name;来重建表并释放空间。注意此操作会锁表需在业务低峰期进行。检查通用日志/慢查询日志确认这些日志是否被意外开启且未轮替。在MySQL配置文件my.cnf中检查general_logslow_query_log的设置。4.4 场景四系统更新缓存与软件包残留现象/var/cache/yum或/var/cache/dnf目录堆积了大量下载的软件包.rpm文件。解决方案# 清理所有已安装软件包的缓存 yum clean all # 或 dnf clean all # 自动删除不需要的依赖包 yum autoremove # 或 dnf autoremove5. 进阶磁盘空间监控与自动化维护手动排查是救火自动化监控和清理才是防火。5.1 配置简单的磁盘监控脚本可以编写一个Shell脚本定期检查磁盘使用率并通过邮件或监控系统报警。#!/bin/bash THRESHOLD90 # 使用率告警阈值 CURRENT_USE$(df / | grep / | awk { print $5 } | sed s/%//g) if [ $CURRENT_USE -gt $THRESHOLD ]; then echo 警告根分区磁盘使用率已达 ${CURRENT_USE}%请及时清理 | \ mail -s 磁盘空间告警 $(hostname) adminexample.com # 也可以在此触发自动清理脚本如清理特定日志 fi将脚本加入crontab例如每10分钟检查一次*/10 * * * * /path/to/check_disk.sh5.2 使用成熟的监控系统对于企业环境更推荐使用Zabbix、PrometheusGrafana、Nagios等监控系统。它们可以图形化展示磁盘使用趋势设置多级报警阈值如80%警告90%严重并与其他系统指标关联分析。5.3 建立日志管理规范应用层所有自研应用必须支持日志轮替或写入由logrotate管理的日志文件。中间件层Nginx、Docker、MySQL等必须配置合理的日志大小和保留策略。系统层定期审查/etc/logrotate.conf配置确保覆盖所有关键日志。磁盘空间管理是一个持续的过程而非一次性任务。它要求我们不仅熟悉df和du这些基础命令更要理解Linux文件系统和存储的工作原理建立从监控、告警到分析、处理、预防的完整闭环。下次当你再看到“磁盘空间不足”的提示时希望你能像一位经验丰富的系统侦探从容不迫地拿起这套工具和方法论快速定位问题根源并实施最优雅的解决方案。记住清理空间很重要但弄明白“空间去哪儿了”以及“如何避免再次发生”更能体现出一个运维工程师的价值。