1. 从“磁盘已满”警报到问题定位一次典型的运维响应早上刚到工位还没来得及泡杯茶监控平台的告警邮件就弹了出来“服务器/根分区使用率超过95%”。点开一看是一台运行着银河麒麟高级服务器操作系统V10的生产环境主机。这种告警在运维工作中再常见不过但处理起来却丝毫不能马虎。磁盘空间爆满轻则导致应用日志无法写入服务异常重则可能引发系统崩溃数据丢失。对于银河麒麟这类常用于关键业务领域的国产操作系统其稳定性和数据完整性要求更高排查必须快速、准确、彻底。很多新手面对“磁盘已满”的第一反应是直接去找最大的文件删掉这往往治标不治本甚至可能误删关键数据。一个系统化的排查思路不仅能解决眼前的问题更能帮助我们理解系统的存储消耗模式预防未来再次发生。今天我就结合这次真实的排查经历梳理出一套在银河麒麟高级服务器操作系统同样适用于CentOS、统信UOS等主流Linux发行版上通用的磁盘空间满排查思路。这套方法从宏观到微观从表象到根因力求让你在遇到类似问题时能胸有成竹手到病除。2. 初步诊断确认问题范围与常用命令解读当告警响起我们首先需要登录服务器确认问题的真实性和范围。不要完全依赖监控数据亲自验证是第一步。2.1 使用df命令确认整体磁盘使用情况df(disk free) 命令是查看文件系统磁盘空间使用情况的首选工具。它的输出直观地显示了每个挂载点的总容量、已用空间、可用空间和使用百分比。df -h执行上述命令-h参数代表“人类可读”会自动将字节转换为 G、M 等单位。输出可能类似这样文件系统 容量 已用 可用 已用% 挂载点 devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 1.1M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/vda1 100G 95G 0G 100% / /dev/vdb1 500G 123G 377G 25% /data关键解读/dev/vda1这是我们的系统盘挂载在根目录/。容量100G已用95G可用空间为0使用率100%。这证实了告警问题就出在这里。/dev/vdb1这是一块数据盘挂载在/data空间充足。这提示我们问题很可能集中在系统本身或运行业务产生的临时文件、日志上而非用户数据。tmpfs系列这是内存文件系统空间来自内存与磁盘无关通常无需关注。注意df命令显示的是文件系统层面的信息。有时你会发现df -h显示已用100%但用dudisk usage命令去统计/目录下所有文件的大小总和却远小于磁盘容量。这种“空间幽灵”现象通常是由于文件被删除后其占用的空间并未被释放例如被某个仍在运行的进程持有或者磁盘存在大量的“孤儿”数据块。我们会在后续章节深入探讨。2.2 使用du命令定位大目录确认了问题分区后下一步是找出哪个些目录占用了大量空间。du(disk usage) 命令用于估算文件和目录的磁盘使用量。一个非常高效的命令组合是cd / # 切换到根目录因为问题在根分区 du -h --max-depth1 | sort -rh | head -20命令拆解与原理du -h --max-depth1以人类可读格式(-h)统计当前目录/下一级子目录和文件的磁盘使用量(--max-depth1)。如果不加--max-depth它会递归统计所有子目录在根目录执行会非常慢且输出冗长。sort -rh对du的输出进行排序。-r表示反向排序从大到小-h表示按人类可读的数值如 10G, 100M排序而不是按字符串那样会导致 10G 排在 9G 前面因为 ‘1’ ‘9’。head -20只显示排序后前20行结果。执行后你可能会看到类似这样的输出85G /var 6.5G /usr 2.1G /home 1.3G /opt ...很明显/var目录是“罪魁祸首”占用了85G空间。我们的排查范围一下子从整个根分区缩小到了/var目录。3. 深度探查针对可疑目录的逐层剖析找到了“嫌疑”最大的目录如/var我们需要像侦探一样一层层深入找到最终占用空间的具体文件或原因。3.1 逐级深入定位具体目录继续使用du命令但这次我们进入/var目录并查看其下一级目录的大小。cd /var du -h --max-depth1 | sort -rh | head -10输出可能显示70G /var/log 10G /var/lib 3.2G /var/cache ...问题进一步聚焦到/var/log日志目录。这是磁盘空间问题的“高发区”。3.2 分析/var/log日志文件的常见陷阱进入/var/log同样使用du命令。这里需要特别注意一些特殊的日志文件或目录系统日志/var/log/messages,/var/log/syslog,/var/log/kern.log等。应用日志如/var/log/nginx/,/var/log/mysql/,/var/log/redis/等。审计日志/var/log/audit/audit.log如果启用了审计服务这个文件可能增长极快。journal 日志这是 systemd 的日志系统。虽然日志文件本身在/run/log/journal/内存中但如果配置了持久化存储其归档文件会存放在/var/log/journal/下也可能占用大量空间。一个快速查看大日志文件的命令是ls -lhS /var/log/ | head -10 # -S 按文件大小排序-h 人类可读-l 长格式显示或者直接查找超过一定大小的文件find /var/log -type f -size 100M -exec ls -lh {} \;实操心得在银河麒麟系统中除了通用服务还需关注其特有的组件日志。例如与安全相关的模块、国产中间件或适配服务的日志它们可能存放在非标准路径。我曾遇到过一个案例某个国产数据库的调试日志默认全开且未配置轮转短短一周就写满了200G的日志分区。3.3 处理已删除但未释放的文件lsof有时du统计的大小远小于df显示的已用空间。这通常是因为有文件被删除rm但打开该文件的进程仍在运行导致磁盘空间并未真正释放给系统。使用lsof(list open files) 命令可以查看这类文件lsof | grep deleted这条命令会列出所有已被删除但还被进程占用的文件。输出会显示进程PID、命令和文件描述符。解决方法是找到对应的进程并安全地重启它例如重启相关的Web服务、数据库服务这样内核才会释放这些空间。重要提示对于生产环境的核心服务如数据库盲目重启可能导致服务中断。务必在业务低峰期或已有高可用方案的情况下与业务方充分沟通后操作。也可以尝试通过向进程发送信号如 HUP让其重新打开日志文件但这取决于应用本身是否支持。4. 专项排查系统与应用的存储消耗点除了通用的日志目录银河麒麟高级服务器操作系统还有一些特定的位置和场景需要重点关注。4.1 软件包缓存/var/cache目录/var/cache目录存放着应用程序的缓存数据。对于使用yum银河麒麟V10通常使用dnf或yum或apt某些版本或衍生版的包管理器来说下载的软件包.rpm或.deb文件会缓存于此。du -sh /var/cache/yum # 或 /var/cache/dnf, /var/cache/apt如果这个目录很大可以安全地清理前提是你确认近期不需要降级或重新安装这些软件包yum clean all # 对于 yum/dnf # 或 apt-get clean # 对于 apt4.2 容器与虚拟化环境Docker Kubernetes如果服务器上运行了 Docker 或 Kubernetes它们将是磁盘空间的“吞噬巨兽”。Docker检查 Docker 的存储目录默认是/var/lib/docker特别是其中的overlay2存储驱动目录和containers。docker system df -v # 查看Docker磁盘使用详情可以清理无用的镜像、容器、卷和构建缓存docker system prune -a --volumes警告-a会删除所有未被容器使用的镜像--volumes会删除未被使用的卷执行前请务必确认Kubernetes在 K8s 节点上除了 Docker/Containerd 的空间还需要关注 Kubelet 管理的 Pod 日志和容器镜像。日志通常在/var/log/pods/和/var/log/containers/。镜像和容器层数据则在容器运行时对应的目录。4.3 银河麒麟特有组件与配置根据提供的热词银河麒麟系统有一些特有的配置点可能影响磁盘TPCM模块如果部署了可信计算相关模块其日志或数据存储位置需要查阅相关文档。授权与激活/etc/kylin-activation/等目录存放授权文件通常很小但需确认。国产软件适配如安装的 WPS、搜狗输入法、EasyConnect 等其用户数据或缓存可能位于~/.config/或~/.cache/下的特定目录。虽然单用户不大但用户数多时也需考虑。系统更新残留系统升级如 V10 升 V11后旧版本的内核、软件包可能残留。使用dnf或yum命令可以清理package-cleanup --oldkernels --count1 # 仅保留最新一个内核 dnf autoremove # 移除不再需要的依赖包5. 高级工具与根因分析技巧当常规方法无法定位时或者需要更直观地分析时可以借助一些高级工具。5.1 使用ncdu进行交互式分析ncdu(NCurses Disk Usage) 是一个基于终端的交互式磁盘使用分析器。它比du更直观可以像文件管理器一样浏览目录并快速查看各目录占比。# 首先需要安装银河麒麟通常可以通过yum/dnf安装 yum install ncdu -y # 然后扫描目录 ncdu /进入界面后使用方向键导航按d键删除文件谨慎它能非常高效地帮你定位到最深层的那个大文件。5.2 分析文件系统 inode 耗尽问题磁盘空间满有两种情况块(block)耗尽和inode 耗尽。df命令默认查看块使用情况。inode存储文件的元信息权限、所有者、时间戳等。如果一个分区存在海量小文件例如邮件服务器、缓存服务器即使总数据量不大也可能耗尽 inode导致无法创建新文件。使用df -i命令查看 inode 使用情况df -ih如果IUse%列达到或接近 100%说明是 inode 耗尽。此时需要寻找哪个目录下的小文件最多。可以使用以下命令# 查找文件数最多的目录前20名 find / -xdev -type f | awk -F/ {print $NF} | sort | uniq -c | sort -rn | head -20 # 或者更精确地统计每个一级目录下的文件数量 for i in /*; do echo -n $i: ; find $i -type f 2/dev/null | wc -l; done | sort -k2 -rn | head -205.3 处理“空间差”问题du与df不一致的深度解析这是排查中的一个经典难题。du -sh /统计的是/下所有文件大小的总和而df -h /显示的是文件系统块的使用情况。两者不一致的常见原因有已删除但未释放的文件如前所述用lsof | grep deleted处理。文件系统预留空间Ext4/XFS 等文件系统默认会为 root 用户保留约 5% 的空间使用tune2fs -l /dev/vda1 | grep ‘Reserved block count’查看。这部分空间df会算作已用但du不会统计。在数据盘上可以通过tune2fs -m 1 /dev/vdb1将预留比例调整为 1%。文件系统内部开销如 journal日志、inode tables 等元数据占用的空间。稀疏文件 (Sparse File)或文件空洞某些数据库文件或虚拟磁盘文件可能是稀疏文件它们逻辑上看很大但实际占用的物理块不多。du报告的是实际分配的块ls -l显示的是逻辑大小而df反映物理块使用。du --apparent-size可以查看逻辑大小。容器 overlayfs 存储驱动的影响Docker 的 overlay2 驱动会存在“写时复制”带来的空间放大效应docker system df是更准确的查看方式。6. 清理策略、预防措施与自动化找到问题并清理后更重要的是建立预防机制避免问题复发。6.1 安全清理操作指南清理不是简单的rm -rf必须遵循安全原则备份优先删除任何不确定的文件前先将其移动到临时目录如/tmp/to_delete观察一段时间确认无影响后再删除。日志轮转 (Log Rotation)这是治本之策。配置logrotate服务对应用日志进行自动轮转、压缩和删除。银河麒麟系统自带了logrotate配置文件在/etc/logrotate.conf和/etc/logrotate.d/目录下。你需要为你业务的关键应用如 Nginx, MySQL添加或修改配置。# 示例/etc/logrotate.d/myapp /var/log/myapp/*.log { daily # 每天轮转 rotate 30 # 保留30份旧日志 compress # 压缩旧日志 delaycompress # 延迟一天压缩 missingok # 日志不存在时不报错 notifempty # 空日志不轮转 create 644 root root # 创建新日志文件的权限 postrotate /bin/kill -HUP cat /var/run/myapp.pid 2/dev/null 2/dev/null || true # 通知应用重载日志 endscript }使用truncate命令清空大日志文件对于正在被进程写入的日志文件直接删除 (rm) 可能导致进程报错。更安全的方法是清空其内容 /var/log/huge.log # 或 truncate -s 0 /var/log/huge.log这会将文件大小截断为0但文件描述符依然被进程持有可以继续写入。6.2 配置监控与告警不能总等问题发生了才处理。应该配置监控系统如 Zabbix, Prometheus Grafana对磁盘使用率进行持续监控。监控项不仅监控/根分区还要监控/home,/var,/data等重要挂载点。告警阈值建议设置两级告警。例如使用率超过80%触发警告Warning提醒管理员关注超过90%触发严重Critical告警需要立即处理。预测性监控可以监控磁盘空间每日增长量预测其将在多少天后写满实现更早的预警。6.3 自动化清理脚本示例对于某些已知的、可定期清理的临时目录或缓存可以编写脚本并加入crontab实现自动化。#!/bin/bash # cleanup_script.sh # 1. 清理YUM/DNF缓存 /usr/bin/yum clean all /dev/null 21 # 2. 清理超过30天的临时文件 find /tmp -type f -mtime 30 -delete 2/dev/null find /var/tmp -type f -mtime 30 -delete 2/dev/null # 3. 清理Docker无用资源谨慎需根据环境评估 # /usr/bin/docker system prune -f --filter until168h /dev/null 21 # 4. 清理特定应用日志在logrotate之外补充 # find /var/log/myapp -name *.log.* -mtime 7 -delete # 5. 发送清理报告可选 echo Disk cleanup completed on $(hostname) at $(date) /var/log/disk_cleanup.log然后通过crontab -e添加定时任务例如每周日凌晨3点执行0 3 * * 0 /root/scripts/cleanup_script.sh磁盘空间管理是系统运维的基本功也是一个需要持续观察和优化的过程。通过这次从告警到根因排查的全过程我们不仅解决了眼前的问题更建立了一套可重复使用的方法论。记住面对“磁盘已满”保持冷静按照“确认范围 (df) - 定位大目录 (du) - 深入分析 (日志、缓存、特定目录) - 解决未释放文件 (lsof) - 实施安全清理 - 建立预防机制”的流程绝大多数问题都能迎刃而解。在银河麒麟这样的生产环境中养成定期巡检磁盘空间和日志轮转配置的习惯能让你的系统运行得更加稳健。
1. 从“磁盘已满”警报到问题定位一次典型的运维响应早上刚到工位还没来得及泡杯茶监控平台的告警邮件就弹了出来“服务器/根分区使用率超过95%”。点开一看是一台运行着银河麒麟高级服务器操作系统V10的生产环境主机。这种告警在运维工作中再常见不过但处理起来却丝毫不能马虎。磁盘空间爆满轻则导致应用日志无法写入服务异常重则可能引发系统崩溃数据丢失。对于银河麒麟这类常用于关键业务领域的国产操作系统其稳定性和数据完整性要求更高排查必须快速、准确、彻底。很多新手面对“磁盘已满”的第一反应是直接去找最大的文件删掉这往往治标不治本甚至可能误删关键数据。一个系统化的排查思路不仅能解决眼前的问题更能帮助我们理解系统的存储消耗模式预防未来再次发生。今天我就结合这次真实的排查经历梳理出一套在银河麒麟高级服务器操作系统同样适用于CentOS、统信UOS等主流Linux发行版上通用的磁盘空间满排查思路。这套方法从宏观到微观从表象到根因力求让你在遇到类似问题时能胸有成竹手到病除。2. 初步诊断确认问题范围与常用命令解读当告警响起我们首先需要登录服务器确认问题的真实性和范围。不要完全依赖监控数据亲自验证是第一步。2.1 使用df命令确认整体磁盘使用情况df(disk free) 命令是查看文件系统磁盘空间使用情况的首选工具。它的输出直观地显示了每个挂载点的总容量、已用空间、可用空间和使用百分比。df -h执行上述命令-h参数代表“人类可读”会自动将字节转换为 G、M 等单位。输出可能类似这样文件系统 容量 已用 可用 已用% 挂载点 devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 1.1M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/vda1 100G 95G 0G 100% / /dev/vdb1 500G 123G 377G 25% /data关键解读/dev/vda1这是我们的系统盘挂载在根目录/。容量100G已用95G可用空间为0使用率100%。这证实了告警问题就出在这里。/dev/vdb1这是一块数据盘挂载在/data空间充足。这提示我们问题很可能集中在系统本身或运行业务产生的临时文件、日志上而非用户数据。tmpfs系列这是内存文件系统空间来自内存与磁盘无关通常无需关注。注意df命令显示的是文件系统层面的信息。有时你会发现df -h显示已用100%但用dudisk usage命令去统计/目录下所有文件的大小总和却远小于磁盘容量。这种“空间幽灵”现象通常是由于文件被删除后其占用的空间并未被释放例如被某个仍在运行的进程持有或者磁盘存在大量的“孤儿”数据块。我们会在后续章节深入探讨。2.2 使用du命令定位大目录确认了问题分区后下一步是找出哪个些目录占用了大量空间。du(disk usage) 命令用于估算文件和目录的磁盘使用量。一个非常高效的命令组合是cd / # 切换到根目录因为问题在根分区 du -h --max-depth1 | sort -rh | head -20命令拆解与原理du -h --max-depth1以人类可读格式(-h)统计当前目录/下一级子目录和文件的磁盘使用量(--max-depth1)。如果不加--max-depth它会递归统计所有子目录在根目录执行会非常慢且输出冗长。sort -rh对du的输出进行排序。-r表示反向排序从大到小-h表示按人类可读的数值如 10G, 100M排序而不是按字符串那样会导致 10G 排在 9G 前面因为 ‘1’ ‘9’。head -20只显示排序后前20行结果。执行后你可能会看到类似这样的输出85G /var 6.5G /usr 2.1G /home 1.3G /opt ...很明显/var目录是“罪魁祸首”占用了85G空间。我们的排查范围一下子从整个根分区缩小到了/var目录。3. 深度探查针对可疑目录的逐层剖析找到了“嫌疑”最大的目录如/var我们需要像侦探一样一层层深入找到最终占用空间的具体文件或原因。3.1 逐级深入定位具体目录继续使用du命令但这次我们进入/var目录并查看其下一级目录的大小。cd /var du -h --max-depth1 | sort -rh | head -10输出可能显示70G /var/log 10G /var/lib 3.2G /var/cache ...问题进一步聚焦到/var/log日志目录。这是磁盘空间问题的“高发区”。3.2 分析/var/log日志文件的常见陷阱进入/var/log同样使用du命令。这里需要特别注意一些特殊的日志文件或目录系统日志/var/log/messages,/var/log/syslog,/var/log/kern.log等。应用日志如/var/log/nginx/,/var/log/mysql/,/var/log/redis/等。审计日志/var/log/audit/audit.log如果启用了审计服务这个文件可能增长极快。journal 日志这是 systemd 的日志系统。虽然日志文件本身在/run/log/journal/内存中但如果配置了持久化存储其归档文件会存放在/var/log/journal/下也可能占用大量空间。一个快速查看大日志文件的命令是ls -lhS /var/log/ | head -10 # -S 按文件大小排序-h 人类可读-l 长格式显示或者直接查找超过一定大小的文件find /var/log -type f -size 100M -exec ls -lh {} \;实操心得在银河麒麟系统中除了通用服务还需关注其特有的组件日志。例如与安全相关的模块、国产中间件或适配服务的日志它们可能存放在非标准路径。我曾遇到过一个案例某个国产数据库的调试日志默认全开且未配置轮转短短一周就写满了200G的日志分区。3.3 处理已删除但未释放的文件lsof有时du统计的大小远小于df显示的已用空间。这通常是因为有文件被删除rm但打开该文件的进程仍在运行导致磁盘空间并未真正释放给系统。使用lsof(list open files) 命令可以查看这类文件lsof | grep deleted这条命令会列出所有已被删除但还被进程占用的文件。输出会显示进程PID、命令和文件描述符。解决方法是找到对应的进程并安全地重启它例如重启相关的Web服务、数据库服务这样内核才会释放这些空间。重要提示对于生产环境的核心服务如数据库盲目重启可能导致服务中断。务必在业务低峰期或已有高可用方案的情况下与业务方充分沟通后操作。也可以尝试通过向进程发送信号如 HUP让其重新打开日志文件但这取决于应用本身是否支持。4. 专项排查系统与应用的存储消耗点除了通用的日志目录银河麒麟高级服务器操作系统还有一些特定的位置和场景需要重点关注。4.1 软件包缓存/var/cache目录/var/cache目录存放着应用程序的缓存数据。对于使用yum银河麒麟V10通常使用dnf或yum或apt某些版本或衍生版的包管理器来说下载的软件包.rpm或.deb文件会缓存于此。du -sh /var/cache/yum # 或 /var/cache/dnf, /var/cache/apt如果这个目录很大可以安全地清理前提是你确认近期不需要降级或重新安装这些软件包yum clean all # 对于 yum/dnf # 或 apt-get clean # 对于 apt4.2 容器与虚拟化环境Docker Kubernetes如果服务器上运行了 Docker 或 Kubernetes它们将是磁盘空间的“吞噬巨兽”。Docker检查 Docker 的存储目录默认是/var/lib/docker特别是其中的overlay2存储驱动目录和containers。docker system df -v # 查看Docker磁盘使用详情可以清理无用的镜像、容器、卷和构建缓存docker system prune -a --volumes警告-a会删除所有未被容器使用的镜像--volumes会删除未被使用的卷执行前请务必确认Kubernetes在 K8s 节点上除了 Docker/Containerd 的空间还需要关注 Kubelet 管理的 Pod 日志和容器镜像。日志通常在/var/log/pods/和/var/log/containers/。镜像和容器层数据则在容器运行时对应的目录。4.3 银河麒麟特有组件与配置根据提供的热词银河麒麟系统有一些特有的配置点可能影响磁盘TPCM模块如果部署了可信计算相关模块其日志或数据存储位置需要查阅相关文档。授权与激活/etc/kylin-activation/等目录存放授权文件通常很小但需确认。国产软件适配如安装的 WPS、搜狗输入法、EasyConnect 等其用户数据或缓存可能位于~/.config/或~/.cache/下的特定目录。虽然单用户不大但用户数多时也需考虑。系统更新残留系统升级如 V10 升 V11后旧版本的内核、软件包可能残留。使用dnf或yum命令可以清理package-cleanup --oldkernels --count1 # 仅保留最新一个内核 dnf autoremove # 移除不再需要的依赖包5. 高级工具与根因分析技巧当常规方法无法定位时或者需要更直观地分析时可以借助一些高级工具。5.1 使用ncdu进行交互式分析ncdu(NCurses Disk Usage) 是一个基于终端的交互式磁盘使用分析器。它比du更直观可以像文件管理器一样浏览目录并快速查看各目录占比。# 首先需要安装银河麒麟通常可以通过yum/dnf安装 yum install ncdu -y # 然后扫描目录 ncdu /进入界面后使用方向键导航按d键删除文件谨慎它能非常高效地帮你定位到最深层的那个大文件。5.2 分析文件系统 inode 耗尽问题磁盘空间满有两种情况块(block)耗尽和inode 耗尽。df命令默认查看块使用情况。inode存储文件的元信息权限、所有者、时间戳等。如果一个分区存在海量小文件例如邮件服务器、缓存服务器即使总数据量不大也可能耗尽 inode导致无法创建新文件。使用df -i命令查看 inode 使用情况df -ih如果IUse%列达到或接近 100%说明是 inode 耗尽。此时需要寻找哪个目录下的小文件最多。可以使用以下命令# 查找文件数最多的目录前20名 find / -xdev -type f | awk -F/ {print $NF} | sort | uniq -c | sort -rn | head -20 # 或者更精确地统计每个一级目录下的文件数量 for i in /*; do echo -n $i: ; find $i -type f 2/dev/null | wc -l; done | sort -k2 -rn | head -205.3 处理“空间差”问题du与df不一致的深度解析这是排查中的一个经典难题。du -sh /统计的是/下所有文件大小的总和而df -h /显示的是文件系统块的使用情况。两者不一致的常见原因有已删除但未释放的文件如前所述用lsof | grep deleted处理。文件系统预留空间Ext4/XFS 等文件系统默认会为 root 用户保留约 5% 的空间使用tune2fs -l /dev/vda1 | grep ‘Reserved block count’查看。这部分空间df会算作已用但du不会统计。在数据盘上可以通过tune2fs -m 1 /dev/vdb1将预留比例调整为 1%。文件系统内部开销如 journal日志、inode tables 等元数据占用的空间。稀疏文件 (Sparse File)或文件空洞某些数据库文件或虚拟磁盘文件可能是稀疏文件它们逻辑上看很大但实际占用的物理块不多。du报告的是实际分配的块ls -l显示的是逻辑大小而df反映物理块使用。du --apparent-size可以查看逻辑大小。容器 overlayfs 存储驱动的影响Docker 的 overlay2 驱动会存在“写时复制”带来的空间放大效应docker system df是更准确的查看方式。6. 清理策略、预防措施与自动化找到问题并清理后更重要的是建立预防机制避免问题复发。6.1 安全清理操作指南清理不是简单的rm -rf必须遵循安全原则备份优先删除任何不确定的文件前先将其移动到临时目录如/tmp/to_delete观察一段时间确认无影响后再删除。日志轮转 (Log Rotation)这是治本之策。配置logrotate服务对应用日志进行自动轮转、压缩和删除。银河麒麟系统自带了logrotate配置文件在/etc/logrotate.conf和/etc/logrotate.d/目录下。你需要为你业务的关键应用如 Nginx, MySQL添加或修改配置。# 示例/etc/logrotate.d/myapp /var/log/myapp/*.log { daily # 每天轮转 rotate 30 # 保留30份旧日志 compress # 压缩旧日志 delaycompress # 延迟一天压缩 missingok # 日志不存在时不报错 notifempty # 空日志不轮转 create 644 root root # 创建新日志文件的权限 postrotate /bin/kill -HUP cat /var/run/myapp.pid 2/dev/null 2/dev/null || true # 通知应用重载日志 endscript }使用truncate命令清空大日志文件对于正在被进程写入的日志文件直接删除 (rm) 可能导致进程报错。更安全的方法是清空其内容 /var/log/huge.log # 或 truncate -s 0 /var/log/huge.log这会将文件大小截断为0但文件描述符依然被进程持有可以继续写入。6.2 配置监控与告警不能总等问题发生了才处理。应该配置监控系统如 Zabbix, Prometheus Grafana对磁盘使用率进行持续监控。监控项不仅监控/根分区还要监控/home,/var,/data等重要挂载点。告警阈值建议设置两级告警。例如使用率超过80%触发警告Warning提醒管理员关注超过90%触发严重Critical告警需要立即处理。预测性监控可以监控磁盘空间每日增长量预测其将在多少天后写满实现更早的预警。6.3 自动化清理脚本示例对于某些已知的、可定期清理的临时目录或缓存可以编写脚本并加入crontab实现自动化。#!/bin/bash # cleanup_script.sh # 1. 清理YUM/DNF缓存 /usr/bin/yum clean all /dev/null 21 # 2. 清理超过30天的临时文件 find /tmp -type f -mtime 30 -delete 2/dev/null find /var/tmp -type f -mtime 30 -delete 2/dev/null # 3. 清理Docker无用资源谨慎需根据环境评估 # /usr/bin/docker system prune -f --filter until168h /dev/null 21 # 4. 清理特定应用日志在logrotate之外补充 # find /var/log/myapp -name *.log.* -mtime 7 -delete # 5. 发送清理报告可选 echo Disk cleanup completed on $(hostname) at $(date) /var/log/disk_cleanup.log然后通过crontab -e添加定时任务例如每周日凌晨3点执行0 3 * * 0 /root/scripts/cleanup_script.sh磁盘空间管理是系统运维的基本功也是一个需要持续观察和优化的过程。通过这次从告警到根因排查的全过程我们不仅解决了眼前的问题更建立了一套可重复使用的方法论。记住面对“磁盘已满”保持冷静按照“确认范围 (df) - 定位大目录 (du) - 深入分析 (日志、缓存、特定目录) - 解决未释放文件 (lsof) - 实施安全清理 - 建立预防机制”的流程绝大多数问题都能迎刃而解。在银河麒麟这样的生产环境中养成定期巡检磁盘空间和日志轮转配置的习惯能让你的系统运行得更加稳健。
