1. 磁盘空间不足的典型表现与诊断当系统提示No space left on device错误时意味着某个挂载点的磁盘空间已经耗尽。这个错误看似简单但背后可能隐藏着多种复杂情况。作为运维人员我们需要掌握系统的完整诊断方法。1.1 基础诊断命令解析最基础的诊断命令是df -h这个命令的输出包含几个关键字段Filesystem显示挂载的设备或分区Size分区总容量Used已使用空间Avail可用空间Use%使用百分比Mounted on挂载点一个典型的输出示例如下Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 48G 500M 99% / tmpfs 16G 0 16G 0% /dev/shm注意当Use%达到100%时系统将完全无法写入新数据某些服务可能会直接崩溃。1.2 深入分析磁盘使用情况仅知道磁盘满了还不够我们需要找出是哪些文件占用了空间。du命令是更深入的分析工具# 查看目录大小按从大到小排序 du -h --max-depth1 / | sort -h -r这个命令组合可以快速定位占用空间最大的目录。对于生产环境我建议添加--time参数查看文件的修改时间帮助判断哪些是陈旧的可以清理的数据du -h --max-depth1 --time /var | sort -h -r1.3 特殊情况的处理有时df和du的结果会出现矛盾——df显示磁盘已满但du统计的各目录总和却远小于磁盘用量。这种情况通常由以下原因导致已删除但未释放的文件被进程打开的文件即使被删除其空间也不会立即释放。使用lsof | grep deleted查找这类文件。文件系统元数据占用特别是小文件极多的场景inode可能先于磁盘空间耗尽。用df -i检查inode使用情况。XFS等文件系统的特性某些文件系统的空间统计方式可能导致差异。2. 系统级空间清理策略2.1 通用清理位置根据多年运维经验以下目录通常是清理的重点目标以CentOS/RHEL为例目录典型内容清理建议/var/log系统和服务日志使用logrotate或手动清理旧日志/var/cache应用程序缓存根据应用类型选择性清理/tmp临时文件注意有些重要进程可能使用/tmp/var/lib/dockerDocker存储特别关注overlay2目录2.2 日志文件的专业处理日志是空间消耗大户需要系统化的管理方法配置logrotate合理的logrotate配置示例/var/log/nginx/*.log { daily missingok rotate 30 compress delaycompress notifempty create 640 nginx adm sharedscripts postrotate /bin/kill -USR1 cat /run/nginx.pid 2/dev/null 2/dev/null || true endscript }使用journalctl管理systemd日志# 查看日志占用空间 journalctl --disk-usage # 清理早于3天的日志 journalctl --vacuum-time3d2.3 软件包缓存清理不同的包管理器有不同的清理方法对于yum/dnf# 清理缓存包 dnf clean packages # 清理所有缓存 dnf clean all对于aptapt-get clean apt-get autoclean3. 数据库相关空间管理3.1 PostgreSQL/OpenGauss空间问题数据库是磁盘空间的重度使用者需要特别注意事务日志堆积检查pg_wal(PostgreSQL)或pg_xlog(老版本)目录# 查看WAL日志大小 du -sh /var/lib/pgsql/12/data/pg_wal/表膨胀问题即使删除数据物理空间可能不会立即释放-- 查找膨胀严重的表 SELECT schemaname, tablename, pg_size_pretty(pg_total_relation_size(quote_ident(schemaname) || . || quote_ident(tablename))) AS total_size FROM pg_tables ORDER BY pg_total_relation_size(quote_ident(schemaname) || . || quote_ident(tablename)) DESC LIMIT 10;定期维护-- 手动执行VACUUM FULL会锁表 VACUUM FULL VERBOSE ANALYZE 表名; -- 更安全的pg_repack pg_repack -d 数据库名 -t 表名3.2 MySQL空间管理MySQL有自己特有的空间问题ibdata1文件膨胀-- 查看各表空间使用情况 SELECT table_schema, table_name, data_length/1024/1024 AS data_mb, index_length/1024/1024 AS index_mb FROM information_schema.tables ORDER BY (data_length index_length) DESC;二进制日志清理-- 设置过期时间 SET GLOBAL expire_logs_days 7; -- 手动清理 PURGE BINARY LOGS BEFORE 2023-01-01 00:00:00;4. 高级处理与预防措施4.1 LVM在线扩容实战当清理无法满足需求时扩容是最终解决方案。使用LVM可以最小化停机时间# 查看当前VG空间 vgs # 扩展物理卷假设新磁盘为/dev/sdb pvcreate /dev/sdb vgextend vg_name /dev/sdb # 扩展逻辑卷 lvextend -L 100G /dev/vg_name/lv_name # 调整文件系统ext4示例 resize2fs /dev/vg_name/lv_name4.2 自动化监控方案预防胜于治疗建议配置监控系统跟踪磁盘使用情况。一个简单的Shell监控脚本示例#!/bin/bash THRESHOLD90 CURRENT$(df / | grep / | awk { print $5 } | sed s/%//g) if [ $CURRENT -gt $THRESHOLD ]; then echo 磁盘空间不足: / 已使用 ${CURRENT}% | \ mail -s 磁盘空间警报 adminexample.com # 自动清理旧日志 find /var/log -type f -name *.log -mtime 30 -exec rm -f {} \; fi对于企业环境建议集成到Prometheus等监控系统中配置类似以下的告警规则groups: - name: disk.rules rules: - alert: DiskSpaceCritical expr: 100 - (node_filesystem_avail_bytes{mountpoint/} * 100 / node_filesystem_size_bytes{mountpoint/}) 90 for: 5m labels: severity: critical annotations: summary: 磁盘空间严重不足 (实例 {{ $labels.instance }}) description: 根分区使用率超过90%: {{ $value }}%4.3 文件系统选择建议不同的使用场景适合不同的文件系统使用场景推荐文件系统优势通用服务器XFS高性能大文件处理优秀数据库存储ext4 (带journal)数据安全性高海量小文件btrfs高效的小文件处理超大规模存储ZFS出色的扩展性和数据完整性在创建文件系统时根据用途选择合适的inode数量和大小的参数# 创建XFS文件系统指定更大的inode大小 mkfs.xfs -i size2048 /dev/sdb1 # 创建ext4文件系统预分配更多inode mkfs.ext4 -N 5000000 /dev/sdb15. 云环境特殊考量云服务器的磁盘管理有其特殊性ECS云盘扩容先在云控制台扩容云盘然后在OS内扩展分区和文件系统# AWS/Alibaba Cloud示例 growpart /dev/vda 1 resize2fs /dev/vda1对象存储挂载 对于静态文件考虑使用s3fs等工具挂载对象存储s3fs my-bucket /mnt/s3 -o passwd_file/etc/passwd-s3fs -o urlhttps://s3-endpoint容器存储管理 Docker的overlay2驱动可能导致空间泄漏定期执行docker system prune -af对于Kubernetes环境需要设置Pod的Eviction阈值apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration evictionHard: memory.available: 500Mi nodefs.available: 10% imagefs.available: 15%磁盘空间管理是系统运维的基本功但也是最容易忽视的环节。在实际工作中我建议建立定期检查制度将磁盘空间监控纳入日常巡检项目。对于关键系统最好保留20%以上的空闲空间作为缓冲避免突发写入导致系统不可用。