Linux虚拟机CPU占用率飙高、系统卡顿甚至假死，核心排查思路就三步：先看宿主机资源是否被抢占，再看虚拟机内部是哪个进程在消耗CPU，最后定位是业务问题还是系统层面的异常。从我的实际经验看，多数情况下问题出在应用层，但也不能忽视虚拟化层带来的干扰。
排查Linux虚拟机CPU占用率高怎么下手
虚拟机卡住的时候,SSH还能连上吗？这是第一个要判断的问题，如果连不上，需要去宿主机上通过virsh或云控制台强制重启，如果能连上，别急着重启，先收集现场数据，否则重启后就什么都看不到了。
先分清楚是整机慢还是单进程卡
很多人遇到卡顿就习惯性敲reboot,这其实是最差的选择，我用过的最有效的流程是这样的：
- 先执行uptime,看系统负载，如果load average数值是CPU核数的好几倍，说明确实有进程在疯狂消耗资源。
- 再执行free -h，排除内存不足导致频繁swap的可能性，这一点容易被忽略，因为swap频繁时系统也会显得非常卡。
- 最后用top命令按CPU使用率排序,看是单个进程接近100%还是多个进程合计吞掉了所有核心。
关键判断规则：如果单进程CPU占用率接近100%但整体负载不高，一般是应用代码里出现了死循环，如果是多个进程合计吃满所有核，且load很高，可能是fork炸弹或者定时任务重叠爆发。
虚拟化层带来的隐性问题
虚拟机的CPU调度和物理机最大的区别在于,你看到的CPU占用率未必是真实的消耗，云平台上的虚拟机用的是vCPU，如果宿主机本身资源超卖严重，你的虚拟机分配到了vCPU时间片，但实际运行效率打折，就会出现一种奇怪的现象虚拟机内top看着CPU占用率只有30%，但业务就是响应缓慢。
行业共识认为,超卖比例超过1:5时，虚拟机的CPU性能会明显衰减，遇到这种情况，直接在虚拟机内做优化是徒劳的，需要联系宿主机管理员检查是否为同一物理机上的其他虚拟机在争抢资源。
定位CPU高占用的具体进程和线程
进到虚拟机里,用top命令按大写P键对CPU使用率排序，如果进程名能直接看出是java、php-fpm还是mysqld，那么范围就缩小了很多，但有时候进程名是python或nginx-worker这种通用名，还需要进一步确认具体是哪个业务模块出了问题。
用pidstat追踪线程级别
top只能看到进程级别,如果Java应用内部开了几十个线程，你看到的pid对应的其实是整个JVM进程，此时再用pidstat -t -p 进程号，就能看到具体是哪个线程在消耗CPU，对于Java应用，拿到线程号后转成十六进制，再通过jstack导出线程快照，在快照里搜索这个十六进制线程号，就能直接定位到具体是哪个业务代码段在执行。
系统调用级别的诊断
如果是内核线程或者内核态CPU占用率高,perf是最好的工具，执行perf top就能实时看到内核函数层面哪个调用链在消耗CPU，我遇到过一次比较典型的案例：一台跑着Nginx的虚拟机CPU占用率到了80%，但访问量并没有增长，用perf一看，排在前面的是native_write_msr_safe，这是因为CPU频率调节驱动与虚拟化环境不兼容，疯狂触发MSR写入，解决办法是把CPU调频模式改成performance，问题立刻解决。
如果perf显示的是一些文件系统相关的函数,比如ext4或xfs相关的调用，那要留意是不是磁盘I/O出现了问题，这时候执行iostat -x 1，如果util已经接近100%，说明进程其实是在等待I/O而非真正在计算，这类情况用top看CPU占用率反而是虚高的，因为进程处于不可中断睡眠状态的时间没有被正确统计。
用strace揪出异常行为
有些恶意程序或挖矿木马会伪装成正常进程名,比如把进程改名为kworker或者sshd，这些程序专门跑在后台，利用CPU挖矿，一旦被发现就会自毁，这种情况下top显示的CPU占用率往往只是接近100%，但不会一直稳定在某个数值，而是忽高忽低地跳动。
用strace -p 进程号去跟踪系统调用，如果看到大量的connect或sendto调用，基本可以断定是在对外发起网络请求，结合ss -tnp看看这个进程建立了哪些对外连接，就能定位到它是否在向矿池发送数据，这件事我干过不止一次，群晖NAS上中了挖矿病毒，CPU占用率持续100%，找到的隐蔽进程伪装成[kworker]，但在/proc目录下对应的pid文件可以找到异常。
虚拟机卡顿原因及解决方法有哪些
找到病根之后,区分场景来看解决方法。
应用代码问题导致的死循环
这种情况在Java或Node.js应用中比较多见，短期的临时手段是kill掉问题进程，恢复业务为先，长期手段是检查代码中是否有未加超时时间的循环调用，特别是while(true)这种结构，以及Redis或数据库连接池的重试机制是否配置了合理的退避策略。
定时任务和日志轰炸
业务高峰期定时任务全部堆叠在一起执行,或者应用疯狂写日志导致磁盘I/O过载，这两个也是虚拟机上常见的CPU占用率飙升原因，定时任务要看vixie-cron的日志，确认是否存在同一时刻多个任务并行执行，日志轰炸则要检查logrotate配置，以及应用日志中是否存在异常报错被重复写入的情况，我处理过一次因为某个客户端的恶意重试导致网关日志在10分钟内写满了磁盘，随之而来的是整台虚拟机服务不可用。
清理僵尸进程和回收内存
排查过程中如果发现大量僵尸进程,说明父进程没有正确回收子进程退出状态，这类进程虽然不消耗CPU，但会占据进程表项，积累多了系统会变得异常，执行ps -ef | grep defunct统计一下数量，如果超过几十个，需要修复父进程的wait处理逻辑。
解决方案可以按优先级这样排：
- 先kill掉占用率最高的异常进程,观察系统负载是否回落
- 如果是业务进程本身,重启对应的应用服务
- 确认是代码问题后,在代码中增加熔断和限流机制
- 必要时刻可以临时扩容虚拟机CPU核数,但这不是长久之计
预防Linux服务器CPU跑满的日常手段
等着出了问题再去排查,始终是被动状态，日常运维时会提前做几件事，把风险消灭在萌芽期。
配置监控和告警阈值
在虚拟机内部部署一个简单的监控脚本,每30秒采集一次CPU占用率，当连续5次超过90%就触发告警，用crontab配合shell脚本就能实现，不需要引入额外的监控软件，如果想省事点，可以直接用sysstat包中的sar来定时采集数据，核心诉求是：在CPU占用率刚上来时就能感知到，而不是等业务方反馈说服务不可用了才知道。
限制单进程资源消耗
通过systemd的CPUQuota配置,可以把某个服务的CPU使用率限制在200%以内（即最多两个核），这样即使某个业务进程确实失控了，它最多也只能占用两个核，不会把整台虚拟机拖垮，业内专家指出，这种做法牺牲了一点性能上限，但换来了整体稳定性的兜底，在混合部署多个业务的虚拟机上尤其适用。
还有一种比较通用的做法是安装cpulimit工具,针对某些不方便改代码的遗留应用，直接限制其CPU占用率上限。
合理配置虚拟机vCPU和内存
创建虚拟机的时候不要贪多,如果业务本身只需要两个核，但你给分配了八个核，反而会出现CPU steal时间偏长的情况，因为宿主机需要均衡调度，资源竞争更激烈，从主流云厂商披露的普遍经验来看，单台虚拟机的vCPU数量最好不要超过宿主物理机逻辑核心数的四分之一，这样可以有效降低争抢概率，至于具体选什么规格，结合业务实际需求来确定，而不是越大越好。
常见问题速查
虚拟机里top显示的CPU占用率和云控制台监控数据对不上
这个是正常的,top展示的是虚拟机内部视角的CPU占用率，而云监控展示的是宿主机视角的vCPU使用量，当发生CPU steal时，虚拟机内核认为自己在等待物理CPU调度，这部分时间不会计入top的user或sys，但宿主机认为分配给该虚拟机的资源已经用足了，如果差距比较大，大概率是宿主机超卖导致的。
怎么判断是宿主机层面出问题了还是虚拟机内部应用的问题
在虚拟机内部执行top,观察st字段，也就是steal时间的占比，如果这行数据高于10%，说明宿主机资源分配吃紧，虚拟机在排队等待物理CPU时间片，这时候不管你怎么优化虚拟机内部都没用，直接找宿主机管理员处理，或者迁移到负载低的物理机上，如果st基本为0，那问题就在虚拟机内部，按前述排查方法进行即可。
一台Linux服务器重启命令怎么操作
首先明确一点,重启是最后一个选择，建议优先通过systemctl restart对应服务来解决，如果确实需要重启系统，用reboot命令或者shutdown -r now都可以，重启前务必执行sync把缓存刷入磁盘，避免文件系统元数据不一致的风险，如果SSH已经卡死无法操作，可以去云控制台执行强制重启操作，但需要重视这是有极小概率造成数据丢失风险的，不过相比业务长时间中断，这是可接受的取舍。
虚拟机出现CPU高占用并不可怕,只要按步骤去定位，大部分问题都能在几分钟内找到线索，真正需要警惕的是那些隐藏在正常进程名下的异常行为，以及虚拟化层带来的虚假性能瓶颈，掌握好这些排查手段，碰到CPU飙高时才不会手忙脚乱。