Java的工具集相当强大,学习成本也很低,处理线上问题时,jstack这个工具就比微软的windbg,好学好用很多,3步找出占用CPU很高的源所在.而windbg反人类的各种命令,实在不敢恭维. 故意设置了一个CPU占用很高的场景: 排查问题,步骤: 1. ps -mp [替换为进程ID PID] -o THREAD,tid,time 发现线程6322.6323占用CPU很高,时间也很长. 2. printf “%x” [线程ID TID] 把TID转换为16进制. 3. jstack [进程I

分几步骤: 1.通过top,查出占用CPU过高的java进程 ,比如: pid :6666 2.通过ps -mp 6666 -o THREAD,tid,time| sort -n -k1 -r 查看此进程占用线程的情况,比如查到占用CPU异常高的线程的线程Id :8888 以上两步,可以直接通过top -H搞定 3.将需要的线程ID转换为16进制格式: printf “%x\n” 8888 [root@xxx.eureka.com]# printf “%x\n” 8888“22b8n” 4.最后

这个问题可以说是 Java 面试的高频面试题了,有很多面试官都喜欢问这个问题,问题可能是下面这样的. 线上一台服务器 CPU 使用率100% 了,如果你碰到这样的情况,如何排查并找到问题原因? 1.场景模拟 当我们真碰到这个问题的时候应该怎么排查呢? 先用一段程序创建几个线程,将其中一个线程设置成高 CPU 使用率的. public static void main(String[] args) { for (int i = 0; i < 10; i++) { Thread thread = n

一.CPU过高分析 1)使用TOP命令查看CPU.内存使用状态可以发现CPU占用主要分为两部分,一部分为系统内核空间占用CPU百分比,一部分为用户空间占用CPU百分比.其中CPU状态中标示id的为空闲CPU百分比.当空闲CPU百分比越低,说明CPU占用率越高. 2)目前针对Linux下java进程占用CPU高的分析手段主要为使用linux命令查出高CPU使用的进程,前分析其是由于进程原因还是系统原因,在分析出为进程消耗过高CPU后列出占用CPU高和占用时间最长的线程并使用jdk自带的jstack

我是风筝,公众号「古时的风筝」,一个兼具深度与广度的程序员鼓励师,一个本打算写诗却写起了代码的田园码农! 文章会收录在 JavaNewBee 中,更有 Java 后端知识图谱,从小白到大牛要走的路都在里面. 这个问题可以说是 Java 面试的高频面试题了,有很多面试官都喜欢问这个问题,问题可能是下面这样的. 线上一台服务器 CPU 使用率100% 了,如果你碰到这样的情况,如何排查并找到问题原因? 这就是一个套路题,所谓套路题就是有标准的套路解法的,掌握了套路,不仅能解决面试官,还能解决问题.不

1.首先通过top命令查看占用cpu过高的pid #top top - 18:07:25 up 48 days,  1:07,  3 users,  load average: 11.94, 11.90, 9.46Tasks: 271 total,   1 running, 270 sleeping,   0 stopped,   0 zombie%Cpu(s): 74.2 us,  0.8 sy,  0.0 ni, 24.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.

我的一个java程序偶尔会出现cpu占用很高的情况 一直不知道什么原因 今天终于抽时间解决了 系统是win2003 jvisualvm 和 jconsole貌似都只能看到总共占用的cpu 看不到每个线程分别占用的cpu呢 所以在windows平台上要找出到底是哪个线程占用的cpu还不那么容易,linux用top就简单多了 最后的解决方法: 1.找到java进程对应的pid. 找pid的方法是:打开任务管理器,然后点击 "查看" 菜单,然后点击 "选择列",把pid勾

背景 天天搞java,这些监控也都知道,用过,但也没往细里追究.因为也没碰见这种问题,这次还是静下来走一遍流程吧.与网上基本一致,不过我区分了下linux和windows的不一样.我感觉基本是程序写成死循环了或者大对象分配多了才有这种问题吧. 步骤 1.找到java进程对应的pid.通过任务管理器.linux---top 2.然后把java进程导出快照.直接运行命令.stack -l 31372 > c:/31372.stack 3.在windows下只能查看进程的cpu占用率,要查看线程的cp

  1.情景展示 java虚拟机占用这么高的CPU,肯定不正常! 2.原因分析 第一个是tomcat,正在运行java项目: 第二个是eclipse,因为eclipse的运行依赖于java. 现在的问题是:tomcat的CPU使用率达到了90%,单独运行tomcat是不可能占用这么多CPU的,所以,问题就出现在: java项目的CPU占有问题. 既然知道项目有问题,那就需要排查项目中具体哪个java类中的哪行代码出了问题. 将第一个应用程序也就是tomcat关闭后,CPU立马会降下来,这进一步证

一.使用top命令查看占用高资源的java项目的进程ID(pid): top 二.查看该进程中的线程所占用资源的情况:top -Hp pid 三.查看该线程对应的16进制:printf %x 11129 打印并保存该进程中堆栈的使用信息日志:jstack -l 11095 >> jstack.log  四.查看该进程中使用高资源的线程的具体信息日志:vim jstack.log 查找上一步的16进制的线程id:/2b79 定位到问题代码: 以上是测试所用(自己写的死循环) 实际排查时却并没有发

最近在测试一个用java语言实现的数据采集接口时发现,接口一旦运行起来,CPU利用率瞬间飙升到85%-95%,一旦停止就恢复到40%以下,这让我不得不面对以前从未关注过的程序性能问题. 在硬着头皮查找资料定位错误修正bug的过程中参考了下面两篇文章: windows下揪出java程序占用cpu很高的线程 并找到问题代码 死循环线程代码:http://blog.csdn.net/hexin373/article/details/8846919 java程序cpu占用过高问题分析:http://ww

问题描述: 生产环境下的某台tomcat7服务器,在刚发布时的时候一切都很正常,在运行一段时间后就出现CPU占用很高的问题,基本上是负载一天比一天高. 问题分析: 1,程序属于CPU密集型,和开发沟通过,排除此类情况. 2,程序代码有问题,出现死循环,可能性极大. 问题解决: 1,开发那边无法排查代码某个模块有问题,从日志上也无法分析得出. 2,记得原来通过strace跟踪的方法解决了一台PHP服务器CPU占用高的问题,但是通过这种方法无效,经过google搜索,发现可以通过下面的方法进行解决,

很多人错误的认为运行Java程序时使用-Xmx和-Xms参数指定的就是程序将会占用的内存,但是这实际上只是Java堆对象将会占用的内存.堆只是影响Java程序占用内存数量的一个因素.要更好的理解你的Java程序将会占用多大的内存需要先了解有哪些因素会影响到内存的占用.这些因素包括: 对象(Objects) 类(Classes) 线程(Theads) 本地数据结构(Native data structures) 本地代码(Native code) 每个因素对内存占用的影响又会随着应用程序.运行环境

很多人认为Xmx和-Xms参数指定的就是Java程序将会占用的内存,但是这实际上只是Java堆对象将会占用的内存.堆只是影响Java程序占用内存数量的一个因素. 除了堆,影响Java程序所占用内存的因素还包括:栈.永生代.JVM本身.NIO中的DirectBuffer等. 假设Xmx为1024m,MaxPermSize为256m,Xss为512k,有100个线程.考虑到socket缓冲区.JNI等,一般大约是jvm内存的5%左右. 则Java程序占用的最大内存可能为:1024m + 256m +

Linux上java程序的jar包启动通用脚本如下: #! /bin/sh export LANG="zh_CN.GBK" SERVICE_NAME=` .sh` SCRIPT_NAME=`` EXEC_JAR_NAME=$SVC_PGW_BIN_PATH/job-pbc-bat/job-pbc-bat-test-.jar JAVA_CMD="java -Djsvc-pgw-name="${SERVICE_NAME}" -Xmx1024m -Xms512m

很多人错误的认为运行Java程序时使用-Xmx和-Xms参数指定的就是程序将会占用的内存,但是这实际上只是Java堆对象将会占用的内存.堆只是影响Java程序占用内存数量的一个因素.要更好的理解你的Java程序将会占用多大的内存需要先了解有哪些因素会影响到内存的占用.这些因素包括: 对象(Objects) 类(Classes) 线程(Theads) 本地数据结构(Native data structures) 本地代码(Native code) 每个因素对内存占用的影响又会随着应用程序.运行环境

1.查看cpu占有率 top -P 2.查看进程cpu占用率 ps -mp 3749 -o THREAD,tid,time|sort -rn|head -n 20 查看占用cpu高,且占用时间长的线程 $.线程ID转换为16进制格式 printf "%x\n" tid 3.查看java堆栈信息 su - nobody -c "/usr/java/jdk1.6.0_21/bin/jstack 3749|grep 34d8 -A 30"  34d8替换成上面转换的16进

1. top 看看哪个进程是罪魁祸首 2.将这个进程的jstack dump 到一个文件里面,以备使用. jstack -l 25886 > /tmp/jstack.log # 如果报错,则加 -F 命令强制执行. jstack -F 25886 > /tmp/jstack.log 使用 sftp 弄到本地. 3.查看这个进程里面哪些子进程, 按 P 键排序占用 CPU 的子进程 top -H -p 25886 (top得到的进程号) # 这里得到的子进程id 为 26017,把该值转化为十六

在一次生产环境中,服务器负载报警,SSH登录上看到CPU占用很高. 1.执行top命令,看到进程号为9737的进程持续占用CPU 2.怀疑是否是进程配置的内存不够了,引发了fullGC导致CPU占用高,执行jmap -heap 9737,看到老年代使用率百分之零,不可能引发fullGC 3.所以应该是程序中的某个线程占用CPU高导致的,使用jstack 9737 > ps.txt导出进程的线程信息,执行top  shift+h找到占用cpu最高的线程,果然就是9737进程下的线程! 4.将线程号

1 前言 欢迎访问南瓜慢说 www.pkslow.com获取更多精彩文章! 我们习惯于在本地开发的时候debug,能快速定位与解决问题,那部署在服务器上是不是就没有办法了呢?只能通过查看日志来定位? 不是的,在远端的服务器上,我们一样可以debug. 2 IDEA的debug 我们先来看一下在IntelliJ IDEA直接debug是怎样的. 先准备一个简单的Java程序: package com.pkslow.basic; import java.util.Map; public class