物理机CPU占用100%时，你的第一反应应该是打开终端自查，同时准备联系服务商，因为CPU 100%可能源于你的应用错误，也可能是硬件故障或配置问题，服务商负责硬件和底层环境，但操作系统及应用层需要你自行排查。参考2
物理机CPU占用100%怎么解决：责任归属与实操步骤
物理机租用CPU飙高找谁：服务商与用户分工
在物理机租用场景下,你拥有整台机器的控制权，当CPU飙到100%，首先需要判断问题出在哪一层，业内专家指出，绝大多数物理机CPU 100%案例由用户层软件引发，比如Web服务被攻击、数据库慢查询、脚本死循环等，只有少数情况涉及硬件故障，比如CPU过热降频、磁盘I/O等待导致进程占用CPU，或者服务商母机配置异常。
找谁处理取决于原因：
- 如果是硬件故障,如CPU温度异常、内存ECC报错、主板故障，必须联系服务商更换。
- 如果是操作系统或软件问题,例如进程异常、配置错误、安全漏洞，需要你自己解决，或向服务商请求技术支持（部分服务商提供付费协助）。
- 如果是网络层面问题,如被DDoS攻击，服务商通常会提供流量清洗或临时封禁，但你需要自行调整防护策略。
明确责任边界后,第一步不是盲目联系服务商，而是先快速定位问题。
物理机CPU 100%常见原因清单
在动手排查前,先对照这份清单，提高定位效率：
- 应用层Bug：死循环、内存泄漏、线程爆炸。
- 资源耗尽：磁盘I/O瓶颈导致进程D状态，CPU等待I/O。
- 恶意攻击：挖矿木马、DDoS放大、暴力破解。
- 配置陷阱：Nginx worker数过多、MySQL连接池过大、PHP-FPM进程数超限。
- 硬件问题：CPU散热不良导致降频、内存错误、电源不稳。
利用top命令定位CPU消耗源
登录到物理机,执行top -c，按P键按CPU使用率排序，你会看到最消耗CPU的进程PID和完整命令行，如果某个进程占用超过90%，锁定它。
针对不同环境进一步分析：
- Java应用：
jstack PID | grep -A 10 "RUNNABLE"，检查线程栈是否有死循环或锁等待。 - PHP进程：检查
/var/log/php-fpm/慢日志，调整pm.max_children。 - MySQL：
SHOW PROCESSLIST，查看是否有大量Sending data状态，开启慢查询日志。 - Python/Node：使用
py-spy或node --inspect进行性能采样。
如果进程是系统进程如kworker、ksoftirqd，可能涉及硬件中断或驱动问题，需要联系服务商配合检查硬件健康。
使用strace跟踪系统调用
当top无法解释为什么CPU高时，对可疑进程执行strace -p PID -c，观察系统调用耗时，如果syscall时间极高，比如大量read、write或ioctl，说明进程在内核态频繁操作，可能指向磁盘I/O或网络驱动问题，后续可以结合iostat和iotop确认。
检查系统日志捕捉异常进程
dmesg -T查看内核日志，journalctl -xe --no-pager查看系统日志，重点关注：
Out of memory：内存不足，进程被OOM Killer杀死，导致残余进程死循环。soft lockup：CPU被长时间占用，无法调度其他任务。thermal throttling：CPU温度过高，自动降频，性能下降。segfault：应用崩溃，可能产生僵尸进程。
检查网络连接判断是否被攻击
netstat -anp | grep :80 | wc -l统计连接数，如果远超预期，可能存在DDoS。ss -tn state time-wait如果大量TIME_WAIT，说明连接池耗尽，进一步用tcpdump抓包分析来源IP。参考2
物理机租用技术支持沟通技巧：快速获取有效帮助
当确定需要服务商介入时,如何沟通能加速响应？以下信息务必提前准备好：
- 物理机IP、机房、账号（如果已开放运维权限）。
- 问题发生时间、持续时间。
- CPU 100%的截图或
top输出。 - 已执行的排查步骤,比如
dmesg关键信息、strace结果。 - 如果是硬件嫌疑,提供温度、错误计数、IPMI日志。
工单撰写示例
主题：物理机CPU持续100%，疑似硬件异常
服务器IP:xxx，自10:00起CPU 100%，top显示进程列表无异常占用，但系统负载高。dmesg显示thermal throttling，CPU温度达到85°C，已执行strace未见明显应用异常，请协助检查CPU散热和传感器状态，机房温度正常，未超30°C，已开放IPMI远程权限，账号:xxx。
服务商的技术支持收到工单后,通常会先重启或进入救援模式，检查硬件健康状态，如果你已开放远程桌面，他们可以帮你查看底层日志，但要注意，物理机租用服务商一般不处理应用层问题，所以不要指望他们帮你改代码，如果服务商确认硬件无问题，你会被要求继续从应用层排查。参考2
物理机CPU 100%长期预防：监控与资源规划
搭建基础监控告警
安装Zabbix或Prometheus+node_exporter，监控CPU使用率、负载、温度、磁盘I/O、网络流量，设置告警阈值，例如持续5分钟CPU超过90%就发送邮件或调用webhook，这样可以在问题初发时第一时间介入，而不是等到用户投诉。
以Prometheus为例,配置node_exporter后，使用rate(node_cpu_seconds_total{mode="user"}[5m])计算CPU使用率，再结合Alertmanager配置告警规则。
合理规划资源配置
如果你租用的物理机配置较低,但运行了高负载应用，CPU 100%是常态，这时需要评估是否需要升级配置，比如增加CPU核数、内存，或使用分布式架构分摊负载，据统计，不少运维人员低估了业务增长带来的资源需求，导致CPU长期满载，建议每季度进行一次资源利用率回顾，提前扩容。
优化应用性能
- 使用缓存（Redis、Memcached）减少数据库查询。
- 对Web服务进行限流和降级,部署负载均衡。
- 开启慢查询日志,优化SQL，重建索引。
- 定期更新软件版本,修复已知性能问题。
- 针对高并发场景,使用异步处理替代同步阻塞。
物理机CPU占用100%常见问题解答
Q：物理机CPU 100%但服务商说不是硬件问题，怎么办？
A：服务商通常只看硬件层面，比如CPU温度、错误率、是否宕机，如果硬件无异常，则问题在你，你需要深入排查应用、进程或配置，可以尝试停止非必要服务，逐一测试负载，如果怀疑服务商限制物理资源，可要求提供lscpu、cat /proc/cpuinfo等硬件信息，并对比购买配置，若仍无法定位，可考虑备份数据后重装操作系统，再部署应用，以排除环境问题。
Q：物理机租用CPU飙高会被服务商停机吗？
A：一般不会自动停机，服务商监控到CPU持续100%会发出告警，但不会主动断网，除非触发了滥用条款（如挖矿、恶意攻击），如果CPU 100%导致系统不稳定，可能触发自动重启策略，但需在服务协议中确认，建议保持服务商控制面板的联系方式畅通，并开启重启通知，以防意外。
Q：物理机CPU 100%和云服务器CPU 100%处理有什么不同？
A：云服务器通常有更多平台工具，如控制台一键排查、性能监控、自动伸缩，物理机则更接近裸金属，你需要自己负责操作系统和应用的完整运维，责任边界更清晰，但排查门槛也更高，物理机租用适合对性能要求稳定、需深度定制环境的场景，云服务器在遇到CPU 100%时，可以快速扩容或迁移实例，而物理机需要自行处理硬件或应用问题。
无论哪种情况，遇到物理机CPU 100%时，保持冷静，按流程排查：先自查，再找服务商，日常做好监控和资源规划，能大幅降低突发问题的影响。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e7%89%a9%e7%90%86%e6%9c%ba%e7%a7%9f%e7%94%a8cpu%e5%8d%a0%e7%94%a8100%e6%89%be%e8%b0%81%e5%a4%84%e7%90%86%ef%bc%8c%e6%80%8e%e4%b9%88%e5%8a%9e%ef%bc%9f/
