一、磁盘空间不足的常见表现
当服务器磁盘空间不足时，系统通常会表现出以下几种症状：
- 应用程序日志报错，例如"No space left on device"
- 数据库服务突然崩溃，特别是MySQL这类需要临时空间的系统
- 系统命令执行失败，甚至简单的
ls都可能无法执行 - 新文件无法创建，已有文件无法修改
最近我就遇到一个典型案例：某电商平台的订单服务突然宕机，排查发现是日志文件把/var分区撑爆了。下面这个命令可以快速查看磁盘使用情况（Linux环境示例）：
# 查看各分区使用情况（人类可读格式）
df -h
# 输出示例：
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 50G 48G 2.0G 96% /
tmpfs 3.9G 0 3.9G 0% /dev/shm
注释：使用率超过90%就需要警惕，特别是/var、/等关键分区。
二、应急处理三板斧
2.1 快速释放空间
最直接的解决方法是找到并删除大文件。推荐组合命令：
# 查找当前目录下大于100MB的文件（Linux）
find . -type f -size +100M -exec ls -lh {} \; | sort -k5 -rh
# 查找最近3天修改过的日志文件
find /var/log -name "*.log" -mtime -3 -size +10M
注释：-size参数可调整（+50M、+1G等），-mtime表示修改时间。
2.2 日志文件处理
日志是常见的"磁盘杀手"，正确的处理方式应该是：
# 清空日志文件而不删除（保持文件描述符）
echo "" > /var/log/messages
# 使用logrotate进行日志轮转（需要提前配置）
logrotate -f /etc/logrotate.d/nginx
2.3 临时空间扩展
如果无法立即删除文件，可以创建临时挂载点：
# 使用内存作为临时存储（tmpfs）
mkdir /emergency_storage
mount -t tmpfs -o size=2G tmpfs /emergency_storage
警告：tmpfs数据会在重启后消失，仅作应急使用。
三、进阶处理方案
3.1 LVM空间调整
对于使用LVM的情况（Linux环境）：
# 查看VG剩余空间
vgs
# 扩展LV（假设有剩余PE）
lvextend -L +5G /dev/mapper/vg-root
resize2fs /dev/mapper/vg-root
注意：这需要预先配置LVM，且VG中有剩余空间。
3.2 Docker磁盘清理
容器环境常有存储泄漏问题：
# 清理已停止的容器及其存储
docker system prune -a
# 查看docker磁盘使用详情
docker system df
3.3 数据库应急处理
以MySQL为例的紧急措施：
-- 清理二进制日志（需确保已备份）
PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00';
-- 临时收缩InnoDB表空间
SET GLOBAL innodb_fast_shutdown = 0;
ALTER TABLE large_table ENGINE=InnoDB;
四、预防性措施
4.1 监控体系建设
推荐使用Prometheus+Alertmanager配置类似告警规则：
# prometheus告警规则示例
- alert: DiskSpaceCritical
expr: 100 - (node_filesystem_avail_bytes{mountpoint="/"} * 100 / node_filesystem_size_bytes{mountpoint="/"}) > 90
for: 5m
labels:
severity: critical
4.2 自动化清理脚本
定时任务的Shell脚本示例：
#!/bin/bash
# 自动清理30天前的日志
LOG_DIR="/var/log/app"
MAX_USAGE=90
current_usage=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ $current_usage -ge $MAX_USAGE ]; then
find $LOG_DIR -type f -name "*.log*" -mtime +30 -delete
fi
4.3 存储架构优化
建议采用的分区方案：
/ 20G （系统）
/var 50G （日志）
/home 剩余空间
/data 单独磁盘（业务数据）
五、技术方案对比
| 方法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 直接删除文件 | 立即见效 | 可能误删重要数据 | 紧急情况 |
| 日志轮转 | 可持续预防 | 需要预先配置 | 所有生产环境 |
| LVM扩展 | 不中断服务 | 需要未分配空间 | 虚拟化环境 |
| 临时挂载 | 快速缓解 | 数据易丢失 | 极端紧急情况 |
六、血的教训
去年我们有个MongoDB集群宕机，就是因为没人注意到数据目录所在分区的inode用尽（虽然磁盘空间还有剩余）。现在我们的监控系统会同时检查：
# 检查inode使用情况
df -i
# 查找大量小文件的目录
find /data -type d | while read dir; do echo "$(find $dir -type f | wc -l) $dir"; done | sort -n
七、终极解决方案
对于关键业务系统，建议：
- 使用独立存储设备（如SAN/NAS）
- 实施分层存储策略（热/冷数据分离）
- 部署Ceph等分布式存储系统
- 每周进行存储容量规划会议
评论