java进程CPU使用率高排查

近期java应用，CPU使用率一直很高，经常达到100%，通过以下步骤完美解决，分享一下。

方法一：

1.jps 获取Java进程的PID。
2.jstack pid >> java.txt 导出CPU占用高进程的线程栈。
3.top -H -p PID 查看对应进程的哪个线程占用CPU过高。
4.echo “obase=16; PID” | bc 将线程的PID转换为16进制,大写转换为小写。
5.在第二步导出的Java.txt中查找转换成为16进制的线程PID。找到对应的线程栈。
6.分析负载高的线程栈都是什么业务操作。优化程序并处理问题。

方法二：

1.使用top 定位到占用CPU高的进程PID
top
通过ps aux | grep PID命令
2.获取线程信息，并找到占用CPU高的线程
ps -mp pid -o THREAD,tid,time | sort -rn
3.将需要的线程ID转换为16进制格式
printf "%x\n" tid
4.打印线程的堆栈信息
jstack pid |grep tid -A 30

pstack是一个shell脚本，用于打印正在运行的进程的栈跟踪信息，它实际上是gstack的一个链接，而gstack本身是基于gdb封装的shell脚本.。此命令可显示每个进程的栈跟踪。pstack 命令必须由相应进程的属主或 root 运行。可以使用 pstack 来确定进程挂起的位置。此命令允许使用的唯一选项是要检查的进程的 PID。

与jstack功相比, 它能对潜在的死锁予以提示, 而pstack只提供了线索, 需要gdb进一步的确定。

pstack是gdb的一部分，如果系统没有pstack命令，使用yum搜索安装gdb即可。

这个命令在排查进程问题时非常有用，比如我们发现一个服务一直处于work状态（如假死状态，好似死循环），使用这个命令就能轻松定位问题所在；可以在一段时间内，多执行几次pstack，若发现代码栈总是停在同一个位置，那个位置就需要重点关注，很可能就是出问题的地方；

ps -eLo pid,lwp,pcpu |grep pid

利用一个最简单的命令就能够定位到哪段程序可能存在性能问题：获取进程ID，通过pstack命令查看里边的各个线程id以及对应的线程现在正在做什么事情，分析多组数据就可以获得哪些线程里有慢操作影响了服务器的性能，从而得到解决方案.

image.png

由此可以判断出来在LWP 30222这个线程产生了性能问题，执行时间长达31.4毫秒的时间，再观察无非就是下面的几个语句出现的问题，只需要简单排查就知道了问题瓶颈。

image.png

本地线程ID

"NativeThread ID"所指的本地线程是指该java虚拟机所对应的虚拟机中的本地线程，java代码是依附于java虚拟机的本地线程执行的，当启动一个线程时，是创建一个native本地线程，本地线程才是真实的线程实体，为了更加深入理解本地线程和java线程的关系，可以通过以下方式将java虚拟机的本地线程打印出来：
1、试用ps -ef|grep java 获得java进程id
2、试用pstack<java pid> 获得java虚拟机本地线程的堆栈
从操作系统打印出来的虚拟机的本地线程看，本地线程数量和java线程数量是相同的，说明二者是一一对应的关系。
那么本地线程号如何与java线程堆栈文件对应起来呢，每一个线程都有tid,nid的属性。----dump文件中每个线程的nid值。

参考 Linux下JVM中可生成的最大Thread数量 http://www.linuxidc.com/Linux/2011-12/48616.htm

影响Java线程数量的因素：

Java虚拟机本身：-Xms，-Xmx，-Xss；

系统限制：
/proc/sys/kernel/pid_max，
/proc/sys/kernel/thread-max，
max_user_process（ulimit -u），
/proc/sys/vm/max_map_count。

转载自：https://www.cnblogs.com/kongzhongqijing/articles/7685699.html

 

相关资源：

Redis数据的导出和导入 - Dcsdn 

GitOps 初探 - Dcsdn 

redis哨兵配置文件 - Dcsdn