1. 从一次“磁盘已满”的告警说起那天下午我正在调试一个后台服务突然收到监控系统的告警邮件“服务器磁盘使用率超过95%”。登录到那台跑着CentOS 7的机器上第一反应就是执行df -h看一眼。果不其然根分区/已经飘红了。这几乎是每个运维和开发都会遇到的经典场景——磁盘空间告急。但问题来了df命令显示使用了90G可我凭经验感觉系统文件和业务日志加起来不应该有这么大。于是我又熟练地敲下du -sh /想看看具体是哪个目录在“吃”空间结果命令卡住了半天没反应。这就是CentOS 7乃至整个Linux系统磁盘空间管理的第一个“坑”df和du统计口径不同以及在大目录下du可能极其缓慢。“查看磁盘空间”这个操作远不止一个df -h那么简单。它背后涉及文件系统原理、挂载点、已删除未释放的文件、稀疏文件、以及各种“空间黑洞”。对于CentOS 7这样一个依然在生产环境中广泛使用的稳定系统掌握一套完整的磁盘空间分析与排查方法论是保障系统稳定性的基本功。本文将从一个老运维的角度不仅告诉你用什么命令更深入解释为什么会有这些现象以及当常规命令失效时你该如何像侦探一样一层层剥开迷雾找到吞噬磁盘空间的“真凶”。2. 基础命令df与du的兄弟之争几乎所有教程都会从这两个命令开始。它们是最直接的武器但理解它们的差异是避免误判的关键。2.1df文件系统层面的空间报告df命令报告的是文件系统的磁盘空间使用情况它的数据来源于文件系统的超级块。你可以把它理解为物业的“总电表”它只看整个大楼用了多少电不管每个房间具体怎么用的。最常用的命令是df -h-h参数代表“人类可读”用G、M、K来显示容量比直接看字节数友好得多。df -h输出通常如下文件系统 容量 已用 可用 已用% 挂载点 /dev/vda1 50G 45G 2.8G 95% / 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 200G 30G 161G 16% /data这里有几个关键信息/dev/vda1这是根分区所在的物理设备。45G已用仅剩2.8G使用率95%告警由此而来。/dev/vdb1这是额外挂载的数据盘空间充足。tmpfs系列这些是基于内存的临时文件系统重启后数据会消失。它们占用的是内存而非磁盘空间所以即使显示已用也不必担心磁盘被占。为什么df显示的空间使用率增长很快但好像没存那么多文件一个常见原因是文件被删除但进程仍持有打开状态。假设一个服务比如Tomcat、Nginx在持续写一个巨大的日志文件app.log。你直接用rm app.log删除了它。在文件系统层面这个文件的索引inode被标记为删除。但是如果写入这个文件的进程没有重启它仍然持有该文件的句柄操作系统会认为文件仍“存在”直到所有持有它的进程都关闭句柄。因此df看到的已用空间不会释放而du扫描目录时却找不到这个文件。此时lsof | grep deleted命令可以帮你找到这些“幽灵文件”和持有它们的进程。2.2du目录层级的空间计算du命令则是通过递归统计目录下所有文件的大小来计算的。它像是挨家挨户查电表的抄表员把每个房间的用电量加起来。常用命令是du -sh /path/to/directory-s是汇总-h是人类可读。# 查看根目录总大小 du -sh / # 查看 /var/log 目录大小 du -sh /var/log # 找出当前目录下最大的10个文件或目录 du -ah /path/to/dir | sort -rh | head -n 10du和df结果对不上的核心原因已删除但未释放的文件如上所述这是最常见原因。du找不到这些文件df却还记着它们。文件系统预留空间Ext4/XFS等文件系统默认会保留约5%的空间给root用户以防普通用户写满磁盘导致系统无法运行。这部分空间df会计入“已用”但du不会。稀疏文件有些文件如虚拟机磁盘镜像、数据库文件是稀疏文件。它们看起来很大但实际占用的物理块可能很小。du默认报告实际占用的块--apparent-size参数可以看逻辑大小而df反映的是实际占用的物理空间。例如用dd命令创建一个1G的稀疏文件dd if/dev/zero ofsparse_file bs1 count0 seek1G。ls -lh显示1Gdu -h显示可能只有几Kdf看到的空间占用也是几K。文件系统元数据df统计的空间包括了inode表、日志等元数据占用的空间而du只统计文件数据。实操心得当磁盘告警时首先对比df -h和du -sh /的结果。如果df的已用空间远大于du统计的根目录空间那么极有可能存在“已删除未释放”的大文件。此时重启相关进程如日志服务、应用服务是最快的释放空间方法。3. 进阶排查当du也束手无策时有时候du -sh /命令会运行得非常慢甚至像开头那样卡住。这通常是因为目录结构极深、文件数量极多或者有挂载了NFS等网络文件系统。这时我们需要更精准的工具和策略。3.1 使用ncdu交互式磁盘使用分析器ncdu是一个基于文本的交互式磁盘分析工具比du更直观、更快。它先扫描目录然后提供一个可以导航的界面让你快速定位大目录。# 安装 ncdu (CentOS 7 EPEL源) yum install epel-release -y yum install ncdu -y # 扫描根目录 ncdu /进入界面后你可以用方向键导航按d删除文件谨慎它能清晰展示每个子目录的空间占比效率远超du配合sort。3.2 定位最大文件的N种方法当需要快速找到“罪魁祸首”时这些命令组合是利器方法一查找大于100M的文件从根开始可能较慢find / -type f -size 100M -exec ls -lh {} \; 2/dev/null | head -202/dev/null是为了忽略权限拒绝产生的错误信息。方法二聚焦常见“肥胖”目录系统中有几个目录是空间消耗的“重灾区”应优先检查/var/log 系统及应用日志。日志轮转配置不当会导致其无限膨胀。/var/lib/docker Docker的存储目录包含镜像、容器数据。/tmp 临时文件。有些程序异常退出会留下大文件。/home 用户家目录。/opt 第三方软件安装目录。方法三使用ls按时间排序找近期的大文件# 在可疑目录下按文件大小降序排列 ls -lhS /var/log/ # 按修改时间降序排列找最近被修改的大文件 ls -lht /var/log/3.3 处理“已删除未释放”的文件这是导致空间“神秘消失”的元凶。诊断步骤如下确认问题执行df -h和du -sh /确认存在显著差异。查找被删除但仍被进程打开的文件lsof | grep deleted输出会显示进程ID(PID)、命令和文件描述符。你会看到类似这样的行java 12345 user 1w REG 8,1 1048576000 1234 /path/to/app.log (deleted)这表示PID为12345的Java进程仍然持有一个已删除的、约1GB大小的日志文件。释放空间优雅方式重启持有该文件的进程如systemctl restart application.service。强制方式如果进程不能重启可以清空该文件描述符极度危险可能导致程序异常echo /proc/12345/fd/1。更安全的方法是向进程发送信号让其重新打开日志文件如kill -USR1 12345前提是程序支持。根本解决配置应用的日志轮转如使用logrotate避免单个日志文件无限增长。4. 空间清理实战与扩容考量找到问题后清理是门技术活乱删可能直接导致系统崩溃或服务异常。4.1 安全清理指南1. 日志文件清理使用logrotate这是管理日志的首选工具。检查/etc/logrotate.conf和/etc/logrotate.d/下的配置确保日志能按时间或大小自动轮转、压缩和删除。手动清理旧日志对于非关键日志可以安全删除。# 清理7天前的日志文件 find /var/log -name *.log -mtime 7 -exec rm -f {} \; # 清空当前日志注意有些服务需要重启或发信号才能继续写入 /var/log/some_large.log2. 包管理缓存清理YUM的缓存可能占用不少空间。# 清理所有已安装软件包的缓存 yum clean all # 或者只清理过期缓存 yum clean packages3. 系统临时文件CentOS 7 引入了systemd-tmpfiles来管理临时文件但/tmp目录下仍可能有残留。# 查看 /tmp 目录大小 du -sh /tmp # 重启后/tmp目录下非系统创建的文件会被清除取决于 /etc/tmpfiles.d/ 配置4. 容器与虚拟机镜像如果是Docker环境/var/lib/docker是重点。# 查看Docker磁盘使用 docker system df # 清理无用的镜像、容器、卷和构建缓存 docker system prune -a踩坑警告绝对不要直接删除/var/lib、/usr、/bin、/sbin等系统核心目录下的未知文件。特别是/lib、/lib64里的库文件删除一个就可能让系统命令全部瘫痪。清理前务必确认文件用途。4.2 扩容最后的解决方案当清理也无法满足需求时扩容就是必选项。从热搜词“centos扩容”、“vmware ubuntu扩展磁盘空间”、“vsphere安装配置centos设置远程访问”可以看出这是虚拟化环境下的高频需求。物理机扩容相对复杂涉及硬盘插槽、RAID配置等这里不展开。虚拟机扩容以VMware/VirtualBox为例通用流程在虚拟化管理界面扩容虚拟磁盘关闭虚拟机在VMware或VirtualBox设置中将虚拟硬盘大小从例如50G增加到100G。此操作仅改变了“容器”的大小操作系统内部还感知不到。在CentOS 7内部扩展分区和文件系统对于使用LVM的情况推荐也是最常见的# 查看物理卷、卷组、逻辑卷 pvdisplay vgdisplay lvdisplay # 假设新空间在 /dev/sda 上需要先创建新分区如 /dev/sda3并类型设置为8e (Linux LVM) # 使用 fdisk 或 parted 操作此处略。 # 将新分区创建为物理卷 pvcreate /dev/sda3 # 将物理卷扩展到现有卷组假设卷组名为 centos vgextend centos /dev/sda3 # 扩展逻辑卷假设要扩展根逻辑卷 /dev/centos/root lvextend -l 100%FREE /dev/centos/root # 最后调整文件系统大小对于xfs和ext4不同 # 如果是xfs文件系统CentOS 7默认 xfs_growfs / # 如果是ext4文件系统 resize2fs /dev/centos/root对于非LVM的普通分区这非常棘手通常需要借助第三方Live CD工具如GParted来移动和调整分区风险极高强烈建议在操作前备份所有数据。热搜词中提到的“no volume groups found.”错误就是在执行vgextend时系统找不到卷组。这通常是因为磁盘扩容后新增的空间没有创建为物理卷或者虚拟机配置的磁盘控制器模式如SCSI/SATA与系统识别的不符导致磁盘设备名变化。解决方法是先用lsblk确认新增的磁盘设备名如/dev/sdb然后使用pvcreate /dev/sdb创建物理卷再将其加入卷组。5. 防患于未然监控与日常维护策略被动响应告警总是狼狈的。一个成熟的系统管理员应该建立主动的磁盘空间监控和维护体系。1. 配置监控告警使用像Zabbix、PrometheusGrafana这样的监控系统对关键分区的使用率设置告警阈值例如80%警告90%严重。这是第一时间发现问题的手段。2. 实施日志管理策略为所有自研应用配置日志轮转写入/etc/logrotate.d/。对于像Nginx、Docker这类常用服务确保其默认的logrotate配置已启用并符合预期。考虑将日志中心化收集到Elasticsearch等日志平台本地只保留短期日志。3. 定期清理任务Crontab将一些安全的清理任务写入定时任务。# 编辑root用户的crontab crontab -e # 每周日凌晨3点清理YUM缓存和临时文件 0 3 * * 0 yum clean all /dev/null 21 0 3 * * 0 find /tmp -type f -atime 7 -delete /dev/null 214. 选择合理的初始分区方案在新系统安装时对应热搜词“centos安装磁盘分区教程”就应做好规划使用LVM这是最重要的建议。LVM提供了无与伦比的灵活性后续扩容几乎零停机。分离关键目录将/home、/var、/opt甚至/var/log单独分区。这样即使日志爆满也不会影响根分区的系统运行。预留足够空间根据业务性质预估增长为根分区和关键数据分区预留充足的余量。磁盘空间管理看似是简单的命令操作实则是系统理解深度和运维经验的体现。从df和du的差异到lsof追踪幽灵文件再到LVM的动态扩容每一步都需要知其然并知其所以然。下次再遇到磁盘空间报警希望你能像侦探一样从容地拿起这些工具精准地找到问题根源而不仅仅是机械地执行删除命令。毕竟在服务器上每一点空间都关乎着业务的稳定。