从 94% 到 72%：一次真实的 Linux 系统"急救"全过程
封面摘要：磁盘告警、CPU 飙高、服务卡顿……面对一台十多年没清理的老机器，盲目清理往往适得其反。本文记录一次真实的 Linux 系统排查过程，帮你建立正确的"运维动刀"顺序。
一、凌晨的告警，和一台"年迈"的机器
那天晚上，一台跑了很久的 Linux Mint 主机突然变得异常卡顿。登录一看，系统负载飙到 3.0~4.6，家目录占用 94%，根分区也到了 89%。
这台机器有点特殊——它是 2012 年的小主机，十多年没清过灰，也没做过系统的"体检"。表面上看，是"垃圾文件太多"；但经验告诉我，表象之下，往往藏着真正的病灶。
二、家目录：缓存不是敌人，失控才是
先看家目录。94% 的占用率，看着吓人，但大头其实是各类缓存：
- pip 安装缓存
- 缩略图缓存
- 浏览器缓存（Firefox / Chrome）
- 虚拟机相关缓存
这些缓存有一个共同点：删了会自动重建。在确认没有正在运行的敏感任务后，我清理了这些目录：
rm -rf ~/.cache/pip ~/.cache/thumbnails ~/.cache/vmware
rm -rf ~/.cache/mozilla ~/.cache/google-chrome
这一步释放了不少空间，但我很清楚：这只是"止血"，不是"治病"。
三、硬件层面：老机器的沉默抗议
软件之外，硬件也在报警。
打开机箱，风道几乎被积灰堵死。重新清灰、重涂硅脂、检查风扇转速后，温度明显下降。对于一台服役超过十年的设备来说，散热本身就是性能的一部分——过热会触发降频，进而放大所有软件层面的卡顿。
四、真正的"元凶"：崩溃循环
继续往下挖，问题逐渐浮出水面：
- 核心转储文件多达 4,632 个，占用了 4.1GB
- journal 日志膨胀到 2.8GB
- 系统日志里，崩溃记录每 3~4 秒一条
这不是普通的资源耗尽，而是一个典型的崩溃循环：某个服务反复崩溃、系统不断生成 core dump 和日志，反过来又把磁盘和 CPU 拖垮。
最显眼的一个指标是：CPU 系统态（sy）占用高达 42%。正常情况下，这个值应该是个位数。系统态异常高，往往意味着内核在频繁处理中断、调度或错误恢复——这和崩溃日志的频率完全吻合。
五、优化效果：数据不会说谎
清理和优化完成后，各项指标的变化非常直观：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 根分区 / | 89%，可用 6.4GB | 77%，可用 13GB |
| 家目录 /home | 94%，可用 489MB | 72%，可用 2.1GB |
| 核心转储 | 4,632 个（4.1GB） | 0 |
| journal 日志 | 2.8GB | 约 200MB |
| 崩溃记录 | 每 3~4 秒一条 | 0 |
| 系统负载 | 3.0~4.6 | 约 1.2 |
| CPU 系统态占用 | 42% | 个位数 |
合计释放约 12.6GB 磁盘空间。更重要的是，系统从"濒临不可用"回到了正常水平。
六、经验总结：排查顺序比命令更重要
这次排障让我再次意识到：找到源头，比盲目清理高效得多。有几点值得记下来：
- 磁盘告警别只盯着删文件。先用
du -sh /var/lib/*这类命令搞清楚是谁在占空间，转储和日志往往会现形。 - 异常 CPU 占比是重要线索。用户态（us）高，多半是业务问题；系统态（sy）异常高，要往进程调度、日志、崩溃处理方向想。
- 崩溃循环要学会看规律。同一个地址、固定间隔的崩溃，基本是确定性的兼容问题，而不是偶发 bug。
- 老硬件跑新软件要多留个心眼。
lscpu里的指令集标志位（AVX/AVX2 等），决定了很多新编译的二进制能不能跑。 - 定期体检纳入日常。定时执行
df -h、journalctl --vacuum，把磁盘和日志控制在健康水位，避免问题累积成事故。
写在最后
很多人遇到 Linux 卡顿，第一反应是"删点东西"或者"重启试试"。但真正的运维思维是：先把统计看完，再去动刀。
这台 2012 年的老机器，最终没有被淘汰，而是继续稳定服役。也许，这就是系统优化的意义——不是一味换新，而是让每一份算力，都物尽其用。
本文基于 Linux Mint 22.3 / systemd 环境，大部分命令在 Debian/Ubuntu 系通用。清理缓存、删除日志与转储前，请先确认没有正在运行的敏感任务，并做好必要备份。结果仅适用于该设备及测试条件。