Google Cloud VPS 突发 CPU 100%？教你一步步排查幕后黑手

下午原本摸鱼摸得正开心，突然手机震动，告警提示服务器 CPU 负载触顶了。连上后台一看，好家伙，CPU 100% 已经持续好几分钟，SSH 连上去都快卡出火星子了。遇到这种情况千万别慌，重启虽然能一时解决问题，但如果不找到根因，过一会它可能还会卷土重来。

今天就跟大家聊聊，当你的 VPS（特别是 Google Cloud 这种大厂的“鸡”）突然 CPU 爆表时，该怎么一步步揪出幕后黑手。

第一步：稳住心态，看负载平均值

Linux top 或 htop 命令查看系统负载均值界面截图

先别急着杀进程。登录系统后，首先输入 top 或者 htop 看一下整体局势。注意观察 Load Average（负载均值），如果这个数字远超你的 CPU 核心数，说明系统压力确实很大。

在这次的排查中，我发现虽然 CPU 总占用率是 100%，但并不是某个用户态进程在疯狂计算，反而是系统态占用了不少资源。这是一个很重要的线索，意味着可能不是你自己的业务代码跑飞了，而是底层的驱动、网络或者是某个内核任务在搞鬼。

第二步：揪出“吃资源”的进程

在 top 界面中，按 P 键可以按 CPU 使用率排序。通常我们会看到几个嫌疑人：

1. 挖矿程序：如果你服务器密码太弱或者 SSH 端口暴露在外，被植入挖矿木马是最常见的 CPU 飙升原因。这类进程通常伪装成很普通的系统名称，比如 kdevtmpfsi、kinsing 等，而且往往很难直接杀死，因为它写了自启动脚本。
2. 数据库死锁：如果你的跑着 MySQL 或 MariaDB，突然出现慢查询或者死锁，会把 CPU 吃光。这时候排查数据库慢日志是关键。
3. 失控的脚本：比如写了一个无限循环的 Shell 脚本，或者 PHP-FPM 的 worker 子进程卡死了。

第三步：查看系统日志与硬件中断

如果像我这回一样，CPU 占用高但看不出明显的恶意进程，那就得往深了挖。Google Cloud 的实例有时候会出现一些网络层面的抖动。

• 使用 dmesg | grep -i error 查看内核日志，看是否有硬件报错或者文件系统报错。
• 检查 sar 历史记录，看 CPU 飙升的时间点是否有网络流量激增。

在 Google Cloud Console 中停止并重启实例

这次的问题最后定位到一个异常的网络守护进程，在某些特定网络包触发下进入了死循环。Google Cloud 的 VPS 网络栈有时候比较敏感，尤其是如果你开了复杂的防火墙规则或者进行大量的包转发操作时。

常见解决方案汇总

根据经验，我总结了几种应对 CPU 100% 的急救包：

1. 如果是挖矿病毒：

   • 断网（封安全组端口）。
   • kill 掉进程，并清理 crontab、/etc/systemd/system/ 下的自启动项。
   • 修改 SSH 密码和端口，甚至直接重装系统最彻底。

2. 如果是 Google Cloud 特有玄学：

   • 有时候仅仅是宿主机的问题。尝试在控制台Stop 再 Start 实例（注意是 Stop，不是 Reset），这会强制迁移实例到另一个物理节点，大概率就能解决底层硬件导致的 CPU 抽风。
   • 检查是否是“Always Free”套餐的机子撞到了资源限制。虽然文档说限制的是 CPU Credits，但在极端情况下性能确实会大打折扣。

3. 如果是业务软件问题：

   • 配置 monit 或 supervisor 来监控进程，一旦 CPU 超过阈值就自动重启服务。
   • 对于 Web 服务，限制单个进程的 CPU 使用上限。

写在最后

VPS 突然卡顿是运维路上的常客，Google Cloud 虽然稳定，但也难免偶尔抽风。遇到问题别光靠重启，养成看日志、查进程的习惯，不仅能解决当下的故障，还能顺便学习不少 Linux 底层知识。

如果你的 GCP 也经常无故高负载，不妨检查一下是不是该给实例做个迁移了！