故障排查——负载Load过高（2）

原创 已于 2023-11-24 17:44:45 修改 · 492 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java

于 2020-03-07 16:11:36 首次发布
本文介绍了一种简单的方法来排查CPU高负载的问题，包括查看高占用率的进程和线程，使用top命令及其参数进行深入分析，以及如何通过jstack定位具体的线程。

目录

传送门

排查步骤

查看CPU占用高进程

查看cpu占用高线程

转换线程ID

定位cpu占用线程

TOP命令补充

传送门

在前面介绍了一下load的相关概念及常用的几个命令，传送门：

故障排查——负载Load过高（1）

现在就学习一下简单的排查步骤，这个不是真实的生产案例，只此记录学习

排查步骤

查看CPU占用高进程

还是以top为例

看到占用最高的是Java进行，PID是117766

查看cpu占用高线程

命令：

top -H -p 117766

查看cup占用最多的线程

可以看到118030这个占用CPU比较高

转换线程ID

得到线程ID

定位cpu占用线程

命令：

jstack 117766|grep 1cd0e -A 50 --col

上面是一个JVM的调度线程。至此分析步骤完毕。

注意的是线上机器一般不允许jstack：可能是dump之后，拿到其它机器去分析

TOP命令补充

top命令交互

top命令控制台，我们可以按h或者?进入交互界面

比如改变颜色的Z

按0-7选择验收，然后按a或执行，最后按回车确认

常用参数

前面用的了命令

top -H -p 117766

p:通过指定监控进程ID来仅仅监控某个进程的状态：top –p 117766

 

只显示进程为117766的运行状况。
 

-H： 设置线程模式
 

显示某个进程所有活跃的线程消耗情况，设置线程模式下：第二行的tasks指的是线程个数
 


                

        

    


  



    



                



	

		

			

				
					
如何排查hpet导致的CPU高负载——《OceanBase诊断系列》之十

				
			

			

				

					OceanBase分布式数据库的博客
				

				

					05-24
					
					1284
					
				

			

		

		

			
				
刚刚新安装的OceanBase集群，没有任何数据，CPU占用非常高，这正常吗？我总结了自己的诊断经验，希望能为其他用户提供一些参考和启示。

			
		

	



                

            
              



	

		

			

				
					
？？？实现高可用的故障转移策略的工具——Keepalived（含数据库的主从复制、MHA高可用简单配置）

				
			

			

				

					sq2048935747@163.com的博客
				

				

					09-10
					
					1467
					
				

			

		

		

			
				
高可用（High Availability, HA）是指系统或服务设计的能力，以确保在面临故障或其他问题时仍然能继续提供服务。其主要目标是最大限度地减少系统的停机时间和确保服务的持续可用性。冗余设计：通过引入冗余组件（如备用服务器、网络路径或存储设备），以便在一个组件失败时，其他组件可以接管其功能，确保系统继续运作。故障转移：设置自动化的故障转移机制，使系统在发现某个组件失败后，能迅速将负载转移到备用组件，从而减少停机时间。负载均衡。

			
		

	



              


  
              

                


	

		

			

				
					
故障排查——负载Load过高（1）

				
			

			

				

					weigeshikebi的博客
				

				

					03-04
					
					4793
					
				

			

		

		

			
				
Linux-top,

vmstat

load


			
		

	





	

		

			

				
					
由 CPU Load 过高告警引发的对 线程数和 CPU 的思考

				
			

			

				

					只有变秃 才能变强
				

				

					12-28
					
					3833
					
				

			

		

		

			
				
线程池 数设置你真的会吗？
可能很多人都看到过一个线程数设置的理论：

CPU 密集型的程序 - 核心数 + 1
I/O 密集型的程序 - 核心数 * 2

这个理论看起来很合理，但实际操作起来，总是不仅如此人意。
下面，我们就来看一下 线程数， CPU 的关心
先说一个基本的理论，大家应该都知道：

一个CPU核心，单位时间内只能执行一个线程的指令
那么理论上，我一个线程只需要不停的执行指令，就可以跑满一个核心的利用率。

下面我们用一段程序来测试下 CPU 和线程数 之间的关系。
CPU 利用率测试
测

			
		

	



		

			
		



	

		

			

				
					
Load过高问题排查

				
			

			

				

					04stone37
				

				

					01-20
					
					1318
					
				

			

		

		

			
				
情况1：CPU高、Load高
通过top命令查找占用CPU最高的进程PID；
通过top -Hp PID查找占用CPU最高的线程TID;
对于java程序，使用jstack打印线程堆栈信息；
通过printf %x tid打印出最消耗CPU线程的十六进制；
在堆栈信息中查看该线程的堆栈信息；
情况2：CPU低、Load高
通过top命令查看CPU等待IO时间，即%wa；
通过iostat -d -x

			
		

	





	

		

			

				
					
java569_Java Web应用Load飙高排查思路

				
			

			

				

					weixin_36267615的博客
				

				

					02-22
					
					364
					
				

			

		

		

			
				
1、使用uptime查看当前load，发现load飙高。➜ ~ uptime13:29 up 23:41, 3 users, load averages: 10 10 102、使用top命令，查看占用CPU较高的进程ID。➜  ~ topPID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND1893 admin     ...

			
		

	





	

		

			

				
					
线上问题排查（1）——java服务器load飚高排查思路

				
			

			

				

					公众号：微观技术
				

				

					03-28
					
					4624
					
				

			

		

		

			
				
Load 是指对计算机干活多少的度量（WikiPedia：the system load is a measure of the amount of work that a computer system is doing），简单的说是进程队列的长度。Load Average 就是一段时间 (1 分钟、5分钟、15分钟) 内平均 Load 

通过uptime命令可以查看当前的load，通常值

			
		

	





	

		

			

				
					
从GPIO中断到I2C通信失败——ESP32摄像头通信链路故障的10步精准排查手册

				
			

			

				

					
				

			

		

		

			
				
其核心通信链路由**GPIO中断**用于帧同步（VSYNC）与行同步（HSYNC）信号捕获，**I2C总线**负责传感器寄存器配置，**并行数据总线**实现像素数据高速读取。  ```c // 示例：ESP32初始化摄像头GPIO映射 #define CAM_...

			
		

	





	

		

			

				
					
ESP32+BMP280故障排查手册：6类常见I2C传感器通信问题速查表

				
			

			

				

					
				

			

		

		

			
				
[ESP32+BMP280故障排查手册：6类常见I2C传感器通信问题速查表](https://www.atomic14.com/assets/article_images/esp_audio/mems_wiring.png) # 1. ESP32与BMP280传感器通信概述  在物联网环境监测系统中，ESP32与...

			
		

	





	

		

			

				
					
K8s 之Prometheus 故障排查（Troubleshooting of Prometheus in K8s）

					
最新发布

				
			

			

				

					Linux运维老纪的博客
				

				

					02-13
					
					1473
					
				

			

		

		

			
				
本文主要探讨 Prometheus 在观测 Kubernetes 方面的独特优势和最佳实践，包括如何在 Kubernetes 不同层次和维度上实现全面的可观测性，如何排查最常见的 Kubernetes 故障，以及维护集群稳定高效运行的最佳实践。

			
		

	





	

		

			

				
					
java进程  cpu load过高分析过程

				
			

			

				

					yaowj2的专栏
				

				

					09-17
					
					7839
					
				

			

		

		

			
				
1\  jps -v列出所有的java进程 , top找出cpu占用过高的对应的java 进程pid
2\ 
使用top -H -p PID 命令查看对应进程里的哪个线程占用CPU过高,取该线程pid
3\ 将线程的pid
 转成16进制
4\jstack
 [进程pid]|grep -A 100 [线程pid的16进制]  dump出jvm该线程的后100行,或者整个输出到文件
j

			
		

	





	

		

			

				
					
高负载下Nginx,Node.JS和网络的优化

				
			

			

				

					Keep Thinking And Learning
				

				

					02-09
					
					2505
					
				

			

		

		

			
				
Nginx和Node.JS通常一起使用，在高吞吐量的Web应用程序中是一对完美的组合。它们都基于事件驱动原则设计，并且能够越过困扰传统Web服务器如Apache的C10K限制扩展到更高的水平。即插即用的配置可以使你的应用工作的足够好，但是当你需要在商业硬件上支撑每秒上千的请求时，你必需作一些针对性的优化最大程度的提高服务器的性能。

    这篇文章假设你使用Nginx的HttpProxyModule模块将负载均衡一个或更多的upstream Node.JS服务器，主要涉及Ubuntu 10.04下调整sy

			
		

	





	

		

			

				
					
load高排查

				
			

			

				

					柠是柠檬的檬的博客
				

				

					08-12
					
					1176
					
				

			

		

		

			
				
load高排查

			
		

	





	

		

			

				
					
Load飙高问题排查过程

				
			

			

				

					小徐的博客
				

				

					01-25
					
					1383
					
				

			

		

		

			
				
🎉欢迎来到专栏：Load飙高问题排查过程好学而不勤非真好学者📜 欢迎大家关注！❤️。

			
		

	





	

		

			

				
					
Linux的Load过高问题排查以及解决方案

				
			

			

				

					weixin_41996755的博客
				

				

					03-28
					
					2208
					
				

			

		

		

			
				
Linux的Load过高问题排查以及解决方案

			
		

	





	

		

			

				
					
JAVA进程高load问题排查思路

				
			

			

				

					耘田
				

				

					10-27
					
					936
					
				

			

		

		

			
				
JAVA进程高load问题排查思路
jps jstack

			
		

	





	

		

			

				
					
线程池踩坑记 --load飙高的原因

				
			

			

				

					zqz_zqz的博客
				

				

					02-27
					
					5163
					
				

			

		

		

			
				
去年处理过一个美图的问题，最近又碰到类似问题了，发现跟美图那个案例原因是一样的，在这里拿出来给大家分享一下。

应该是去年6月底，我们私有化发布了新版本，然后就拿去给美图客户安装部署了，美图的美拍应用访问量较大，新版本部署后问题不断，后来我接手去处理，在这之已出过不少问题，客户也不怎么配合了；

问题现象：美图客户的运维说，听云应用kafka积压消息，backend不工作了，重启后不久服务器loa...

			
		

	





	

		

			

				
					
一次load飙高排查过程

				
			

			

				

					weixin_30408739的博客
				

				

					02-19
					
					289
					
				

			

		

		

			
				
一、外在表现

有时java应用的load很高，影响系统稳定性，这时候就要进行问题排查，找出影响系统稳定性的因素。如果是进程级的应用，如Nginx、Apache等都还比较容易排查，但如果是JVM中的某个线程导致的，估计有人就要开始抓瞎了。



二、排查过程



1.ps -ef | grep java | grep -v grep

找出Java进程ID,...

			
		

	





	

		

			

				
					
CPU load过高产生的原因及排查

					
热门推荐

				
			

			

				

					不能说的秘密的博客
				

				

					09-24
					
					6万+
					
				

			

		

		

			
				
之前面试被问到，造成CPU load过高的原因有哪些？如何快速排查其原因？ 
开一贴，总结该相关知识

			
		

	





	

		

			

				
					

				
			

			

				

					
				

			

		

		

			
				

			
		

	



              




          




        



    





    



      

      

        
      

      





	

		评论	
	

  

	
    

      

      

      

        
        

          
          

            

              成就一亿技术人!
            

            

              拼手气红包6.0元
            

          

        

        

          

            还能输入1000个字符
          

          

             
          

          

            

              红包
              添加红包
            

            

              表情包
              插入表情
              

                

              

            

            

              表情包
              代码片
              

                
              

            

            

              
              
              
              
              
              
              
            

          

        

      

    

		

			

			

			

					 条评论被折叠 查看
			

			

				
			

		

	

	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值