VPS炸了？内存硬盘爆满导致SSH连不上的急救指南

相信很多玩小鸡的朋友都遇到过这种情况：本来跑得好好的服务，突然网页打不开，SSH连接一直转圈最后提示Connection timed out。

这个时候你大概率会去服务商的后台控制台看一眼，结果发现CPU 100%，内存爆红，或者磁盘IO直接飙满。遇到这种情况，千万别慌，更别无脑强制重启（可能会导致数据丢失）。今天就给大家整理一套从“死机”状态救活小鸡的标准操作流程。

🔨 第一步：利用服务商控制台救援

既然SSH进不去，我们唯一的入口就是服务商提供的网页版VNC/Console控制台。

1. 尝试登录：虽然SSH不通，但控制台通常是基于底层虚拟化的，大概率还能挤进去。用户名密码照旧。
2. 还是卡死？按重启键：如果控制台键盘输入都没反应，或者进度条卡住不动，这时候只能联系后台强制Reboot。注意：如果是生产环境，且数据极其重要，优先尝试联系官方技术支持挂载ISO进行救援，而不是直接强制断电。

🩺 第二步：安全模式下的故障排查

重启之后，如果不及时处理，系统很可能再次陷入死循环。我们需要在服务还没完全把资源耗尽之前，迅速找到罪魁祸首。

使用 top 命令查看系统资源占用情况，关注进程的 CPU 和内存使用率。

1. 谁在吃内存？

登录后第一时间输入：

free -h

如果发现Swap也被用光了，那就是严重的OOM（内存溢出）。接着看是谁在吃：

ps aux --sort=-%mem | head -n 10

常见元凶：

• Java/Python应用：代码内存泄漏，或者配置的堆内存太小。
• MySQL/MariaDB：配置文件里innodb_buffer_pool_size设置过大，超过了物理内存。
• Redis：如果没有设置最大内存限制，它会一直吃到内存耗尽。

解决办法：如果是不可控的进程，直接kill -9 [PID]掉；如果是数据库等关键服务，先kill保命，然后修改配置文件调低参数再启动。

2. 谁在爆IO？

输入命令查看IO负载：

top # 按下 1 查看每个核心负载，同时关注 %wa (wait for I/O)
iotop # 如果没有安装，运行 yum install iotop 或 apt install iotop

如果%wa非常高，说明CPU在空转等待磁盘读写。这时候一定要用iotop或者dstat看是哪个进程在疯狂读写磁盘。

使用 df -h 命令检查磁盘空间，防止因磁盘写满导致系统卡死。

常见元凶：

• 日志文件无限增长：某个程序的错误日志疯狂刷屏，把磁盘写满。
• 坏道导致卡顿：云盘底层出现故障，系统反复尝试读取损坏的数据块。
• 搬家/备份：自己忘了后台在运行大文件的scp或rsync。

解决办法：如果是日志爆满，先echo "" > /path/to/log清空日志释放空间；如果是坏道，赶紧快照备份，然后找服务商换盘。

3. 磁盘空间满了也没救

别忽略了最基础的一点：

df -h

如果Use%是100%，系统连写临时文件的权限都没有，自然卡死。通常是因为 /var目录下的日志或者Docker的镜像占满了空间。

🛡️ 第三步：事前预防，胜过事后诸葛亮

既然救回来了，怎么防止下次再炸？

1. 加装监控报警：不要等挂了才发现。使用Prometheus+Grafana或者云服务商自带的监控，设置当内存超过80%或IO持续高位时，发送邮件/Telegram通知。
2. 限制关键服务资源：
   • Docker容器一定要加--memory限制。
   • Redis配置文件里务必加上maxmemory 1gb（根据你的实际情况设置）并设置淘汰策略。
   • 定时任务清理日志（如logrotate）。
3. 配置Swap：如果是突发性流量导致内存溢出，适当的Swap（比如1G-2G）能给你留出足够的重启服务的时间，虽然会增加IO延迟，但能保命。

结语

小鸡卡死并不可怕，可怕的是不知道为什么死。掌握这套“VNC登录 -> 快速定位 -> Kill保命 -> 修改配置”的连招，基本上90%的突发故障都能手到病来。如果你连VNC都进不去，或者一直重启失败，那大概率是底层硬件问题，别犹豫，直接开工单找客服赔...哦不，找客服修吧！