------
封面摘要：
磁盘告警、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% → 77%，可用空间从 6.4GB 涨到 13GB
• 家目录 /home：从 94% → 72%，可用空间从 489MB 涨到 2.1GB
• 核心转储：4,632 个（4.1GB）→ 0
• journal 日志：2.8GB → ~200MB
• 崩溃记录：每 3~4 秒一条 → 0
• 系统负载：3.0~4.6 → ~1.2
• CPU 系统态占用：42% → 个位数
合计释放约 12.6GB 磁盘空间。更重要的是，系统从“濒临不可用”回到了正常水平。
------
六、经验总结：排查顺序比命令更重要
这次排障让我再次意识到：找到源头，比盲目清理高效得多。有几点值得记下来：
1. 磁盘告警别只盯着删文件
先用 du -sh /var/lib/* 这类命令搞清楚是谁在占空间，转储和日志往往会现形。
2. 异常 CPU 占比是重要线索
用户态（us）高，多半是业务问题；系统态（sy）异常高，要往进程调度、日志、崩溃处理方向想。
3. 崩溃循环要学会看规律
同一个地址、固定间隔的崩溃，基本是确定性的兼容问题，而不是偶发 bug。
4. 老硬件跑新软件要多留个心眼
lscpu 里的指令集标志位（AVX/AVX2 等），决定了很多新编译的二进制能不能跑。
5. 定期体检纳入日常
定时执行 df -h、journalctl --vacuum，把磁盘和日志控制在健康水位，避免问题累积成事故。
------
写在最后
很多人遇到 Linux 卡顿，第一反应是“删点东西”或者“重启试试”。但真正的运维思维是：先把统计看完，再去动刀。
这台2012年的老机器，最终没有被淘汰，而是继续稳定服役。也许，这就是系统优化的意义——不是一味换新，而是让每一份算力，都物尽其用。
本文基于 Linux Mint 22.3 / systemd 环境，大部分命令在 Debian/Ubuntu 系通用。
------
文末互动：
你在维护老机器时遇到过哪些“离谱”的问题？欢迎在评论区聊聊你的排查经历。
