# **腾讯云CVM CPU 100%？9个排查命令快速定位问题**
本文由**腾讯云国际站『云老大-飞弟 @yunlaoda360 / YunLaoDa-腾讯云服务器服务商•撰写』**如需转载请注明！

监控告警响个不停，SSH 连上去敲个 `top` 都卡到无法刷新——当一台腾讯云 CVM 的 CPU 占用率长时间停在 100%，再淡定的运维也得深吸一口气。把问题拆开来看，往往就几个命令的距离。本文整理了九个在生产环境验证过的 **腾讯云 CVM CPU 100%排查命令**，从现象识别到定位根因，帮你把不明不白的高负载拽回正常线上。

## 一、CPU 100%现象与基本概念

CPU 占用 100% 意味着服务器所有计算核心的处理能力已被持续榨干，时间片全部分配给可运行任务，用户态进程、内核态线程或中断处理都可能成为“元凶”。表现上，轻则业务接口延迟抖动，重则 SSH 连不上、`top` 命令刷不出来。问题不是 CPU 爆了，而是需要判断是正常的业务增长，还是异常进程在背后“偷跑”。

### 1. 什么是CPU占用100%？

CPU 占用 100% 指操作系统层面 `%user`、`%sys`、`%iowait` 等指标叠加后持续满负荷。最常见的是用户态进程（如 Nginx、MySQL）消耗大量计算时间，或内核态被中断、系统调用占满。按量计费的腾讯云 CVM 若触发实例保护策略，还可能因为 CPU 超限被强制关机，对线上业务的破坏远不止卡顿这么简单。

### 2. 哪些进程会导致CPU飙高？

业务进程本身的高负载是最常见的情形——数据库的慢查询、Web 服务的 GC 停顿、爬虫任务的无序扩散。另一种需要警惕的是挖矿病毒，它常常利用系统漏洞植入并伪装成正常进程，表面上 `ps` 输出看不出异常，但 `strace` 会暴露大量向陌生 IP 发起的 `connect` 调用。此外，计划任务、systemd 守护服务可能成为恶意进程的“复活点”，杀掉主进程几秒后又会重新拉起，让 CPU 再次回到 100%。

### 3. CPU 100%的危害有哪些？

响应缓慢只是第一步。数据库连接池耗尽、API 超时、消息积压会连锁发生，用户侧直接感受到“崩了”。如果实例是突发性能型或设置了按量计费上限，长时间 100% 会触发腾讯云的自动关机策略，业务被迫中断。挖矿病毒还会消耗出网带宽，导致云监控费用异常上涨，同时在内部横向扩散，把一台服务器的问题放大为整个 VPC 的安全事件。

## 二、基础排查命令：实时监控CPU

当腾讯云CVM控制台弹出“CPU使用率100%”的告警时，运维人员的第一个动作通常是SSH登录服务器。但现实往往比理想残酷——登录过程本身就可能因为资源耗尽而超时。这种情况在2024年后愈发常见，背后推手不再是正常的业务洪峰，而是自动化扫描植入的挖矿木马。它们会刻意隐藏进程名、伪造系统文件，让常规的`ps aux`看不出破绽。因此，第一阶段的排查目标不是解决问题，而是**在混乱中建立起稳定的观察哨**。

### 1. top命令怎么看CPU占用

`top`是多数人的肌肉记忆，但默认输出很容易产生误导。直接执行`top`看到的是进程列表，而真正关键的信息在首行：`us`（用户态）、`sy`（内核态）、`wa`（I/O等待）。如果`wa`值持续高于30%，意味着磁盘I/O是瓶颈，CPU只是在等数据落盘。此时按`shift+c`可以展开进程的完整启动命令——挖矿病毒常伪装成`[kworker]`或空命令，但展开后能看到异常的外联IP和矿池地址。另一个盲区是短时进程：`top`默认3秒刷新一次，某些规避检测的挖矿程序会利用这个间隙交替休眠。命令`top -d 1`将刷新间隔缩短到1秒，虽然会增加自身开销，但在CPU已满载的机器上，这点消耗几乎可以忽略。

### 2. vmstat查看系统负载

`vmstat 1 5`输出的第一行是系统启动以来的平均值，排查时应直接看第二行开始的实时数据。关注`r`列（运行队列长度）和`wa`列。如果`r`值持续大于CPU核心数，说明有大量进程在排队等待调度，这是CPU成为瓶颈的直接信号。而当`wa`列数值异常时，问题多半出在存储层——可能是数据库慢查询引发的全表扫描，频繁触发磁盘寻道。另一个容易被忽视的列是`si`和`so`（内存换入换出），如果这两个值不为零，说明物理内存已耗尽，系统被迫使用Swap分区，这会间接导致CPU在处理内存页面交换时飙高。这种情况下的正确做法不是杀掉占用CPU最高的进程，而是先执行`free -h`确认内存水位，避免被表象误导。

## 三、进程级定位：找出高CPU进程

当你通过 `top` 确认 CPU 确实被打满后，第一件事不是急着敲 `kill`，而是搞清楚到底哪个进程在消耗资源。很多运维老手都经历过这样的尴尬：重启服务器后问题暂时消失，两小时后告警又响了——因为你根本没找到根因。

真正有效的排查，是从进程级开始的逐层下钻。这里介绍三个在不同场景下最实用的命令组合。

### 1. ps命令筛选高CPU进程

`top` 是交互式的，信息刷新有延迟，而且进程列表会跳动。当你需要一份静态的“犯罪现场快照”时，`ps` 更可靠。

执行 `ps -eo pid,ppid,%cpu,%mem,cmd --sort=-%cpu | head -15`，这条命令会按 CPU 占用率从高到低排列进程，同时显示父进程 ID（PPID）和完整命令行。PPID 这个字段在后续排查中很关键——如果你发现一个高 CPU 进程的父进程是 `[kthreadd]` 或 `1` 号进程，说明它可能是内核线程或被 init 收养的孤儿进程，处理方式完全不同。

另一个常见坑：进程列表看起来都正常，但 CPU 就是 100%。这时候留意 `cmd` 列是否有方括号包裹的进程名，比如 `[kworker/0:1]`，这种内核工作队列的高占用往往指向磁盘 I/O 或网络中断问题，而不是某个具体的应用程序。

### 2. pidstat跟踪进程CPU

`ps` 给出的是瞬时快照，但你需要的往往是“过去 5 分钟到底发生了什么”。`pidstat` 能填补这个空白，它属于 sysstat 工具包，默认在腾讯云 CVM 的 CentOS 或 Ubuntu 镜像里都预装了。

执行 `pidstat -u 2 5`，每隔 2 秒采样一次，共采 5 次，输出会显示每个进程在这段时间内的平均 CPU 利用率。重点看 `%usr`（用户态）和 `%system`（内核态）两列的比值。如果 `%system` 显著偏高，比如一个 Java 进程用户态只占 10%，内核态却占了 40%，这通常意味着程序在频繁进行系统调用，可能是网络 I/O 密集或线程竞争严重，升级 CPU 核数也不一定能解决。

对于挖矿病毒这类恶意程序，`pidstat` 的持续采样还有一个实用价值：它们往往在服务器空闲时段才开始大量占用 CPU，白天业务高峰时反而伪装得很正常。通过设置 cron 定时采集 `pidstat` 日志，比手动蹲守有效得多。

## 四、深度分析：strace与perf实战

top、ps 只能告诉你“谁在吃 CPU”，却讲不清它在“吃什么”。当业务进程 cpu 占用持续 100% 但日志不报错、代码看不出死循环时，就必须下钻到系统调用和函数热点——strace 看外部行为，perf 看内部开销，两条线交叉验证才能收敛根因。

### 1. strace 追踪系统调用

strace 的典型用法不是直接 attach 生产进程，而是 `strace -p [PID] -c -S time` 做 10-15 秒的统计。2026 年泽御云公开的一起挖矿处置中，运维人员发现一个名为 `sshd` 的进程 CPU 拉满，但 top 看不像真实 sshd；用 `strace -e trace=network -p [PID]` 抓到该进程高频向外站矿池 IP 发 TCP connect，立刻判定是伪装 webshell 植入的挖矿木马。统计模式下，若 `% time` 集中在 `futex`、`nanosleep` 且长期不返回，说明流程可能空转；大量 `connect`、`sendto` 则是外联行为，常见于病毒或配置错误的后台任务。

### 2. perf top 分析热点函数

如果是正常业务把 CPU 跑满，瓶颈通常在代码逻辑或框架设计。`perf top -p [PID]` 能实时展示函数级别的 CPU 采样，排序靠前的热点函数就是优化切入点。实践中，一个 PHP 站点 CPU 100%，perf top 显示 `zend_hash_find` 和 `memcpy` 占比超 40%，最终定位到全局数组未索引，每次请求做 O(n) 遍历；另一个 MySQL 实例慢查询日志正常，但 perf 热点停留在 `buf_calc_page_crc32`——那是 InnoDB 校验和计算，根因是临时表全部落在磁盘，改为 tmpdir 上 tmpfs 后 CPU 直接降了 30%。perf 也能揭穿“代码没问题”的错觉：一次 Node.js 服务 perf 报告里 `v8::internal::Runtime_KeyedLoadIC_Miss` 占比奇高，原因是 JSON 字段反复解析，改存 Buffer 后完成一次优化。

### 3. 如何解读 strace 输出

刚接触 strace 的人容易盯着单条记录的返回时间，其实更该看系统调用的聚集模式。用 `-c` 汇总后，`% time` 最高的调用未必是调用次数最多的。如果 `read` 耗时排第一但次数很少，往往是单次 I/O 阻塞，这时要查文件系统或存储端延迟；如果 `futex` 排第一且次数极多，大概率是短时间大量线程争抢锁，需要回看应用层的并发控制。另外，`strace -f -e trace=process` 可观察 `clone`、`execve` 系列调用，用于排查某些异常进程被杀后“瞬间复活”——背后一定有守护脚本或 systemd timer 在重新拉起，不斩断这个链条，CPU 100% 会反复出现。

## 五、常见原因及解决方案

CPU 打到 100% 并不等于“该升级配置了”。在腾讯云工单系统里，相当比例的性能故障最终定位是应用层异常，而非资源不足。真正值得立刻上手的，是按进程类型拆解——Web 服务、数据库、可疑的后台任务——并分别用一套固定流程快速收敛。

### 1. Web 服务负载过高怎么办

Web 进程突然吃满 CPU，常见诱因是短时间涌入的异常流量或代码死循环。先用 `top -c` 盯住进程，再对 PID 执行 `strace -p [PID] -c -S time`，能快速看出时间耗在 read/write 还是 epoll_wait 上。曾有一个外贸客户的 Nginx worker 持续 100%，strace 显示 90% 时间消耗在向一个失效上游发送请求，问题不在 CVM，而在后端超时设置空缺。所以别急着扩容——多数情况下调权重、加缓存或限流，比买更高规格实例见效更快。

### 2. 数据库查询慢导致 CPU 高

数据库引起的 CPU 飙高，几乎都能追溯到几条“重量级”SQL。在 MySQL 里直接跑 `SHOW FULL PROCESSLIST`，通常就能看到某个 `Sending data` 状态的查询已经运行了上百秒，往往是全表扫描或索引失效。再结合 `slow_query_log` 把执行时间超过 1 秒的语句抓出来，用 `EXPLAIN` 检查 type 列是否为 ALL。我们观察到，中小企业开发环境里，超过 70% 的慢查询是因为遗忘了添加复合索引，或者在生产库上直接跑了未优化的报表统计 SQL。处理这类问题，加一个索引比加 CPU 核心更直接有效。

### 3. 挖矿病毒排查与清除

最让运维头疼的是 top 里看不到高占用进程，但云监控的 CPU 曲线一直钉在 100%。这通常是挖矿病毒在伪装——进程名被替换成 `[kworker]` 之类，或者通过加载内核模块隐藏。排查时，不要只信 top，尝试 `ps -eo pid,%cpu,cmd --sort=-%cpu | head -10` 结合 `cat /proc/[PID]/exe` 看真实路径。泽御云 2026 年的一起案例中，攻击者通过 Redis 未授权访问植入挖矿程序，并在 `/etc/cron.d/` 下注册了每 10 分钟执行的复活脚本。清除时，必须同步清理 crontab 和 systemd 服务，同时用 `ss -ntp` 检查外联到矿池 IP 的连接。发现异常后只杀进程不删持久化机制，等于白干。

## 六、长期优化与预防措施

挖矿病毒伪装成普通进程、慢查询拖垮数据库、定时任务悄悄复活——这些场景反复证明，一次性的应急 kill 进程解决不了根本问题。长期来看，需要把“事后扑火”转化为系统性的预防动作，而不是等到用户投诉再冲进去翻命令行。

### 1. 设置 CPU 使用率告警

在腾讯云云监控里把“CPU 使用率 ≥80% 持续 5 分钟”作为一个基础告警规则，是性价比最高的第一道防线。不止是监控 CVM，还要把托管在云上的 MySQL、Redis 等服务的 CPU 指标一并放入告警池。配合自动化脚本（例如通过告警触发自定义消息队列，再由 CVM 上的 agent 执行 `top -bn1 | head` 快照保存上下文），能比“收到告警再登录机器”缩短至少 3–5 分钟的定位窗口。如果业务有明显的波峰波谷，建议再加一条“CPU 使用率环比突增 50%”的条件，能更早暴露异常进程。

### 2. 定期巡检关键进程

很多被植入的挖矿程序，并不是一直占满 CPU，而会在深夜或某几个小时内启动，避免白天被运维注意到。所以单纯看实时 CPU 很难抓住。需要有一套定时巡检逻辑：每天在 `/etc/cron.d/`、`/var/spool/cron/` 中扫描新增的 crontab 条目，检查有无 `/tmp`、`/dev/shm` 下启动的异常二进制文件，并通过 `ps -eo ppid,pid,cmd --sort=-%cpu | head -20` 汇总过去 24 小时内的高 CPU 进程快照。泽御云在 2026 年披露的挖矿案例中，病毒就是通过伪装成 `[kworker]` 的内核线程骗过了第一眼排查，最后靠对比进程的可执行文件 MD5 找到线索——这就是巡检要覆盖的深度。

### 3. 优化代码与配置推荐

控制 CPU 的长期成本，最终还是要从应用层下刀。对 Web 服务，`perf top` 可以清楚显示哪些函数在吃 CPU 周期：一次常见的 PHP 框架请求里，如果 `preg_match` 占据 30% 以上耗时，就需要回溯调用链做正则预编译或缓存。数据库场景中，慢查询是“慢性毒药”，一个缺少索引的全表扫描 SQL 在并发上来后可以把 16 核 CPU 打到 100%。建议开启 MySQL 慢查询日志，并设置 `long_query_time=0.5` 秒，每周导出分析。此外，CVM 本身也不是服务开得越多越好，关闭无用的 `cron`、`atd`、`bluetooth` 等服务，能挤出 2–5% 的系统 CPU 开销，对轻量规格（如 2C4G）的实例来说并非可以忽略不计。

本文由腾讯云国际站『云老大-飞弟 @yunlaoda360 / YunLaoDa-腾讯云服务器服务商•撰写』如需转载请注明！

腾讯云国际站：CVM CPU 100%？9个排查命令快速定位问题

监控告警响个不停，SSH 连上去敲个 top 都卡到无法刷新——当一台腾讯云 CVM 的 CPU 占用率长时间停在 100%，再淡定的运维也得深吸一口气。把问题拆开来看，往往就几个命令的距离。本文整理了九个在生产环境验证过的 腾讯云 CVM CPU 100%排查命令，从现象识别到定位根因，帮你把不明不白的高负载拽回正常线上。

人工智能

腾讯云CVM服务器CPU100%问题排查指南，提供9个实用命令快速定位高负载原因。从top、vmstat基础监控到ps、pidstat进程分析，再到strace、perf深度追踪系统调用和函数热点，帮助运维人员快速识别业务进程、挖矿病毒等异常情况。针对Web服务、数据库慢查询等常见场景给出解决方案，并建议设置告警、定期巡检等长期优化措施，有效降低服务器CPU负载。

4核4G3M云服务器 新用户低至38元/年！

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

腾讯云CVM服务器CPU100%问题排查指南，提供9个实用命令快速定位高负载原因。从top、vmstat基础监控到ps、pidstat进程分析，再到strace、perf深度追踪系统调用和函数热点，帮助运维人员快速识别业务进程、挖矿病毒等异常情况。针对Web服务、数据库慢查询等常见场景给出解决方案，并建议设置告警、定期...

腾讯云国际站：CVM CPU 100%？9个排查命令快速定位问题-腾讯云开发者社区-腾讯云

腾讯云国际站：CVM CPU 100%？9个排查命令快速定位问题

腾讯云国际站：CVM CPU 100%？9个排查命令快速定位问题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐