磁盘空间缓慢增长：谁在写文件

多数时候，悄悄吃掉磁盘的就是两类东西：日志和临时文件。增长的规律也能先给个粗判：速度稳定、位置固定，多半是日志和 binlog 这类可预测的写入；速度忽快忽慢，才需要抓现行。但要定罪，还是得按流程把写入者找出来。 第一步：找到是哪个分区、哪个目录 df -h 看哪个分区增长最快，然后顺着往下挖： du -xh --max-depth=1 / | sort -rh | head -20 -x 参数只统计同一个文件系统，避免跨分区误判；-h 让单位自动换成 G 和 M，读起来直观。一层层往最大的目录钻，通常两三层就能锁定目标。/var/log 和 /tmp 是两大高发区，数据库服务器的 binlog 目录也要重点看。另外注意 df 和 du 可能对不上：du 数的是文件大小，df 看的是分区占用，两者差距大，多半是有文件被删了但句柄还被进程握着，那是另一类问题。 第二步：确认是谁在写 锁到可疑文件后，看哪个进程握着它： lsof /var/log/app.log lsof +D /var/log/ | awk '{print $1, $2}' | sort -u lsof 会列出打开这个文件的进程名和 PID。如果是日志文件，多半是应用没配轮转，只增不减。要抓现行，可以用 inotifywait（需安装 inotify-tools 包）： inotifywait -m -e modify /tmp 哪个进程频繁触发 modify 事件，写盘的就是它。写入不落在固定文件时还有一手：翻可疑进程的 /proc/进程PID/io，write_bytes 字段直接暴露写入大户。 第三步：处理和预防 日志类问题配好 logrotate，按天切割并保留固定份数，配置片段供参考： /var/log/app.log { daily rotate 7 compress missingok } 切割之后记得让应用重新打开日志文件，nginx 用 nginx -s reopen，支持 USR1 信号的服务用 kill -USR1 进程号，否则新日志仍写进旧文件。MySQL 的 binlog 设置 expire_logs_days 或 binlog_expire_logs_seconds 自动清理；systemd 的 journal 也可能占好几个 G，journalctl --disk-usage 查占用，journalctl --vacuum-size=200M 收缩。/tmp 里的临时文件加一条定时清理： find /tmp -type f -mtime +7 -delete 磁盘增长是慢性病，等 df 报警时往往已经影响写入。如果最后发现写入者是应用自己在落临时数据，先看程序有没有控制这份数据生命周期的开关，治本永远在应用侧。上线新服务前先把日志轮转配好，比事后追凶省事得多。