CPU负载狂飙，但使用率却低？别再盲目重启了！这3个关键指标一查就知

服务器或者虚拟机的CPU负载也就是Load Average持续飙升之际，系统响应会变得特别缓慢，甚至服务会发生中断。这一般而言意味着有进程在队列当中等待执行，然而高负载并不总是因CPU自身繁忙造成的，也有可能是由I/O、内存或者异常进程引发的。我们要进行系统性地定位瓶颈，而不是盲目地重启或者升级配置。

如何判断机器负载是否真的过高

针对“load average”三个值，可借助“top”或者“uptime”命令来查看，这三个值分别是过去1分钟、5分钟以及15分钟的平均负载情况。负载值与CPU逻辑核心数之间的关系是关键判断标准。有一条简易的经验法则，若15分钟平均负载一直持续超过CPU核心总数，那就表明资源已然饱和。举例来说，对于一台有着4核CPU的机器，要是负载长时间超过4，那就明确处于高负载状态了。另外，要结合top命令里CPU使用率那一行来展开分析，要是“wa”（也就是I/O等待）这个值一直高于20%，就算“id”（空闲）率处于很高的状态，那也说明瓶颈有可能出现在磁盘I/O上。

CPU负载高但使用率低是怎么回事

这是一种平常且极易被忽略的情形，你或许会于top里瞧见CPU空闲率（id）颇高，而负载（load average）却始终处于高位不下，这一般指向两类问题，第一类是。I/O瓶颈大量的进程正处于等待磁盘进行读写的情形，它们处于那种被称作“不可中断睡眠”的状态，也就是D状态。在这个时候呢，可以运用iostat -x 1这样的命令去做进一步的诊断。要是“%util”这个设备利用率持续地接近于100%，并且“await”等待的时间很长，那么就能够确认了。第二类的情况是。僵尸进程或短时进程由于僵尸进程的不断积累，负载会被推高。更为隐蔽的，是大量短时进程频繁地启动以及退出，在此时，top命令可能来不及进行捕获，这种情况下，可以使用像execsnoop这样的专用工具来进行追踪。

发现导致高负载的具体进程后怎么办

定位到具体进程后，需要分类处理。对于正常业务进程假设存在一种情形，若此情形是因计算密集型任务引发导致的，那么这种情况下就能够去斟酌钻研将代码或者算法予以优化；要是该情形是由于业务增长所造成致使的，那么在这种状况下就有必要去谋划规划对实例规格予以升级。对于。异常进程诸如那不为所知的挖矿病毒，呈现出这般状况，top命令会被篡改，ps命令也会被篡改，而且还会连接异常的域名。在这个时候呢，就应当从备份进行恢复或者对系统予以重置，并且要做好安全方面的加固处理。针对。因I/O或内存不足引发的系统进程问题比如说，kswapd0这个进程呢，由于内存不够充足，所以频繁地开展换页的操作，进而致使CPU的占用率变高，又或者是物理内存被消耗殆尽，以至于系统频繁地运用交换分区（swap）。解决办法涵盖了调整应用程序的内存配置，对内存进行升级，又或者是调整系统的参数（像是降低vm.swappiness的值，以此来削减使用swap的趋向）。

如何从系统和架构层面预防负载过高

要临时进行处理来治标，得长期予以预防方可治本，建议去建立性能基线监控，然后给CPU负载、使用率、内存以及磁盘I/O设置告警阈值。在系统配置这方面，可以依据服务器角色对内核参数加以优化，比如说促使网络连接队列长度得以增加。在架构层面来讲，对于Web应用而言，能够考虑为数据库引入缓存（像Redis），给静态资源运用CDN，或者借助负载均衡达成横向扩展，这些均可从根本之处分散压力，进而提升系统承载能力。

是不是在你将高负载问题予以排查之际，碰到过的最为棘手或者最为出乎预料的情形是啥？欢迎于评论区把你的经历以及最终的解决方案给分享出来。要是这篇文章对你存有帮助，那就去点赞或者分享给有可能有需求的同事。