java应用线上CPU过高问题排查】的更多相关文章

1.top 命令,查看占用CPU最高的PID.ps aux|grep PID 进一步确定tomcat进程出现问题.2.ps -mp pid -o THREAD,tid,time显示线程列表3.printf "%x\n" tid 线程ID转换为16进制格式.4.jstack pid | grep tid -A 30 打印线程的堆栈信息5.pstack 查看某个进程的当前线程栈运行情况…
GitHub 20k Star 的Java工程师成神之路,不来了解一下吗! GitHub 20k Star 的Java工程师成神之路,真的不来了解一下吗! GitHub 20k Star 的Java工程师成神之路,真的真的不来了解一下吗! 前段时间我们新上了一个新的应用,因为流量一直不大,集群QPS大概只有5左右,写接口的rt在30ms左右. 因为最近接入了新的业务,业务方给出的数据是日常QPS可以达到2000,大促峰值QPS可能会达到1万. 所以,为了评估水位,我们进行了一次压测.压测在预发布…
源:http://daiwa.ninja/index.php/2015/07/18/storm-cpu-overload/ 2015-07-18AUTHORDAIWA STORM在线业务实践-集群空闲CPU飙高问题排查有2条评论 STORM在线业务实践-集群空闲CPU飙高问题排查 最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并…
本文转载自线上CPU飙升100%问题排查 引子 对于互联网公司,线上CPU飙升的问题很常见(例如某个活动开始,流量突然飙升时),按照本文的步骤排查,基本1分钟即可搞定!特此整理排查方法一篇,供大家参考讨论提高. 问题复现 线上系统突然运行缓慢,CPU飙升,甚至到100%,以及Full GC次数过多,接着就是各种报警:例如接口超时报警等.此时急需快速线上排查问题. 问题排查 不管什么问题,既然是CPU飙升,肯定是查一下耗CPU的线程,然后看看GC. 核心排查步骤 1.执行"top"命令:…
一.内存过高 1.内存过高一般有两种情况:内存溢出和内存泄漏 (1)内存溢出:程序分配的内存超出物理机的内存大小,导致无法继续分配内存,出现OOM报错 (2)内存泄漏:不再使用的对象一直占据着内存不释放,导致这块内存浪费掉,久而久之,内存泄漏的对象堆积起来,也会导致物理机的内存被耗尽,出现OOM报错 2.内存过高的检测办法:通常我们的Java服务器部署在Linux机器上面,可以通过jvm自带的命令进行一些检测 (1)查看对象的数目和占用内存大小 ①参数为Java程序的进程号,将结果导出到指定目录…
top基本使用: top命令参考本篇文章 查看内存和CPU的top命令,别看输出一大堆,理解了其实很简单 top 命令运行图: 第一行:基本信息 第二行:任务信息 第三行:CPU使用情况 第四行:物理内存使用情况 buff/cache: buffers 和 cache 都是内存中存放的数据,不同的是,buffers 存放的是准备写入磁盘的数据,而 cache 存放的是从磁盘中读取的数据 在Linux系统中,有一个守护进程(daemon)会定期把buffers中的数据写入的磁盘,也可以使用 syn…
之前排除服务器内存暴增的问题,在此看到一篇类似的文章,做个类似的记录. 1.top基本使用 top 命令运行图: 第一行:基本信息 第二行:任务信息 第三行:CPU使用情况 第四行:物理内存使用情况 buff/cache: buffers 和 cache 都是内存中存放的数据,不同的是,buffers 存放的是准备写入磁盘的数据,而 cache 存放的是从磁盘中读取的数据 在Linux系统中,有一个守护进程(daemon)会定期把buffers中的数据写入的磁盘,也可以使用 sync 命令手动把…
一.内存过高 1.内存过高一般有两种情况:内存溢出和内存泄漏 (1)内存溢出:程序分配的内存超出物理机的内存大小,导致无法继续分配内存,出现OOM报错 (2)内存泄漏:不再使用的对象一直占据着内存不释放,导致这块内存浪费掉,久而久之,内存泄漏的对象堆积起来,也会导致物理机的内存被耗尽,出现OOM报错 2.内存过高的检测办法:通常我们的Java服务器部署在Linux机器上面,可以通过jvm自带的命令进行一些检测 (1)查看对象的数目和占用内存大小 ①参数为Java程序的进程号,将结果导出到指定目录…
最近将公司的在线业务迁移到Storm集群上,上线后遇到低峰期CPU耗费严重的情况.在解决问题的过程中深入了解了storm的内部实现原理,并且解决了一个storm0.9-0.10版本一直存在的严重bug,目前代码已经合并到了storm新版本中,在这篇文章里会介绍这个问题出现的场景.分析思路.解决的方式和一些个人的收获. 背景 首先简单介绍一下Storm,熟悉的同学可以直接跳过这段. Storm是Twitter开源的一个大数据处理框架,专注于流式数据的处理.Storm通过创建拓扑结构(Topolog…
原文地址:https://blog.csdn.net/chenjunan888/article/details/80447800 在服务器报cpu过高时,可使用以下命令,快速导出堆栈信息,以方便查看具体的问题. 1. 使用top命令定位异常进程.可以看见12836的CPU和内存占用率都非常高 此时可以再执行ps -ef | grep java,查看所有的java进程,在结果中找到进程号为12836的进程,即可查看是哪个应用占用的该进程. 2. 使用top -H -p 进程号查看异常线程 3. 使…
一.引子 对于互联网公司,线上CPU飙升的问题很常见(例如某个活动开始,流量突然飙升时),按照本文的步骤排查,基本1分钟即可搞定!特此整理排查方法一篇,供大家参考讨论提高. 二.问题复现 线上系统突然运行缓慢,CPU飙升,甚至到100%,以及Full GC次数过多,接着就是各种报警:例如接口超时报警等.此时急需快速线上排查问题. 三.问题排查 不管什么问题,既然是CPU飙升,肯定是查一下耗CPU的线程,然后看看GC. 3.1 核心排查步骤 1.执行“top”命令:查看所有进程占系统CPU的排序.…
今天测试团队反馈说,服务A的响应很慢,我在想,测试环境也会慢?于是我自己用postman请求了一下接口,真的很慢,竟然要2s左右,正常就50ms左右的. 于是去测试服务器看了一下,发现服务器负载很高,并且该服务A占了很高的cpu.先用top命令,看了load average,发现都到了1.5左右(双核cpu)了,并且有一个java进程(20798)占用cpu一直很高,如下图: 于是,用命令jps -l看了一下java的20798,刚好就是服务A. 究竟服务A在跑什么,毕竟是测试环境.于是使用to…
现状 生产系统CPU占用过高,并且进行了报警 排查方法 执行top命令,查看是那个进程导致的,可以确定是pid为22168的java应用导致的 执行top -Hp命令,查看这个进程的那个线程导致cpu过高,如下图,可以看到是22749线程导致的 top -Hp 22168 由于jstack里面的线程号为16进制,需要转换线程号为16进制,如下图得到16进制值为58dd printf "%x\n" 22749 执行jstack生成线程快照保存至1.txt文件中,22168为进程id js…
一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环. (友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen) 以我们最近出现的一个实际故障为例,介绍怎么定位和解决这类问题. 根据top命令,发现PID为28555的Java进程占用CPU高达200%,出现故障. 通过ps aux | grep PID命令,可以进一步确定是tomcat进程出现了问题.但是,怎么定位到具体线程或者代码呢? 首先显示线…
上午收到报警,某台机器上的CPU负载过高,通过逐步的排查,解决了问题,下面记录一下整个排查的过程. 首先,登录上对应的机器,通过top命令找到占用CPU过高的进程ID,也就是PID,为29126, 然后通过ps命令和grep命令找到PID为29126对应的服务,具体命令如下: 结果如下: 找到对应的服务之后,可以直接查看服务打印的日志,没有发现任何异常,所以只能通过jdk提供的JVM工具来排查问题. 先通过jdk自带的工具jstack保存一下JVM进程对应的栈信息,具体的命令是: jstack…
经反馈,新部署的服务器上filebeat占用的cpu过高,且内存只增不减. 而据我了解filebeat非常轻量级,正常情况下占用的资源几乎都能忽略不计,所以怀疑是filebeat本身出了问题. 第一时间查看filebeat日志(默认路径/var/log/filebeat/filebeat),发现有大量内容输出:   --20T08:: INFO kafka/log.go: producer/broker/ starting up --20T08:: INFO kafka/log.go: prod…
环境 centos7 1核2GB Java8 模拟cpu占用高 新建一个名为jvm-learn的springboot项目 模拟代码如下 import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.web.bind.annotation.GetMapping; imp…
环境 centos7 1核2GB Java8 模拟cpu占用高 新建一个名为jvm-learn的springboot项目 模拟代码如下 import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.web.bind.annotation.GetMapping; imp…
CPU 飚高 一般是死循环或者死锁问题导致. 1. 通过 top  命令找到 CPU 消耗最高的进程,并记住进程 ID {pid}.top -M -n 2 -d 3 >{pid}/top.txt 查看top 2. 再次通过 top -Hp  {pid} 找到 CPU 消耗最高的线程 ID,并记住线程 ID(十进制). 3.通过 JDK 提供的 jstack 工具 dump 线程堆栈信息到指定文件中.jstack {pid} >{pid}/jstack_1.txt 一次堆栈快照 备用 jstac…
1.top -c 加 大写P 查找高进程ID 2.top -Hp 加 大写 P 查找高线程ID 3.printf '%x\n' 线程ID 转成16进制 4.jstack 进程ID | grep 16进制线程ID 通过以上四个步骤就可以找到代码中的哪行是高消耗代码.…
限于iOS AppStore的审核机制,一些新的功能的添加或者bug的修复,想做些节日专属的活动等,几乎都是不太可能的.从已有的经验来看,也是有了一些比较常用的解决方案.本文先是会简单说明对比大部分方案,然后会注重阐述基于JSPatch的在线更新机制的设计和实现.对于任何一家有一定用户基础的iOS应用来说,在线更新技术所产生的直接和间接价值都将远远超过100W.理解,并掌握它;实在没有时间,就记住它,因为这篇文章不仅仅是讨论. 实例地址:https://github.com/ios122/ios…
一.发现问题 在一次系统上线后,我们发现某几个节点在长时间运行后会出现CPU持续飙升的问题,导致的结果就是Kubernetes集群的这个节点会把所在的Pod进行驱逐(调度):如果调度到同样问题的节点上,也会出现Pod一直起不来的问题.我们尝试了杀死Pod后手动调度的办法(label),当然也可以排除调度节点.但是在一段时间后还会复现,我们通过监控系统也排查了这段时间的流量情况,但应该和CPU持续占用没有关联,这时我们意识到这可能是程序的问题. 二.排查问题 定位Pod 这里使用kubectl t…
一.线程 查进程中占用cpu高的线程 ps -mp xxxxx -o THREAD,tid,time | sort -rn 将线程的id从10位转到16位,可以在下面jstack中找到对应线程 输出线程详细信息(-l 多输出一些锁的信息) jstack -l xxxxx | grep xxx -A 30 > 1.txt 查找处于RUNNABLE的和业务相关的线程 dstat 性能检测工具 cpu:hiq.siq分别为硬中断和软中断次数 system:int.csw分别为系统的中断次数(inter…
npm shrinkwrap 我们使用node开发时,经常需要依赖一些模块来完成功能需求,而我们所依赖的模块也必然会依赖其他模块,就这样一级一级的依赖,而且这些依赖模块并不为我们所控制.一个产品或项目的开发周期,少则几个周,多则几个月几年.开发人员往往在一开始时下载了依赖包发现能够正常工作后,便一直在依赖包的当前版本上工作,然而在线上服务器布属时往往是根据依赖配置文件,重新下载依赖包.可这个时候依赖链中的包的开发者很可能已经将某个模块升级了,而且并不能保证这些新的依赖包没有bug.一旦依赖链上的…
1.top命令对cpu进行排序shift+p 2.pwdx pid查找业务进程路径 3.top -Hp pid查看相关负载线程pid 4.printf “0x%x\n” 线程pid     // 将线程 PID转换为 16进制,为后面查找 jstack 日志做准备 5.jstack  进程 PID | vim +/十六进制线程PID -        // 例如:jstack 1040|vim +/0x431 - 更快的方法使用show-busy-java-threads.sh github地址…
现状描述: 办公网环境下由2台VSS模式下WS-C4503-E 作为核心交换机,下接若干台WS-C2960X-48LPS-L作为接入.行政同事在进行工位改造的时候为方便将原工位网线下联若干台hub. 故障现象: 7月4号(周六)下午6点zabbix监控告警核心交换机的CPU使用率很高,在凌晨1点以后员工都下班时恢复到正常的水平 正常时的CPU监控如下 故障时的CPU监控如下 故障分析: 故障发生下周六的下午,没有人对网络设备做过配置调整,初步判断是由于业务同事错误的将hub区域的网络接成了环路.…
1.通过top 查看具体是哪个进程占用内存较多 Tasks: 65 total, 1 running, 64 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.0 us, 1.0 sy, 0.0 ni, 96.3 id, 0.3 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 1016168 total, 63544 free, 824060 used, 128564 buff/cache KiB Swap: 2047996 total,…
首先通过uptime查看系统负载,然后使用mpstat结合pidstat来初步判断到底是cpu计算量大还是进程争抢过大或者是io过多,接着使用vmstat分析切换次数,以及切换类型,来进一步判断到底是io过多导致问题还是进程争抢激烈导致问题.…
JVM 线上故障排查基本操作 CPU 飚高 线上 CPU 飚高问题大家应该都遇到过,那么如何定位问题呢? 思路:首先找到 CPU 飚高的那个 Java 进程,因为你的服务器会有多个 JVM 进程.然后找到那个进程中的 “问题线程”,最后根据线程堆栈信息找到问题代码.最后对代码进行排查. 如何操作呢? 通过 top 命令找到 CPU 消耗最高的进程,并记住进程 ID. 再次通过 top -Hp [进程 ID] 找到 CPU 消耗最高的线程 ID,并记住线程 ID. 通过 JDK 提供的 jstac…
CPU过高 这类问题可以使用 top 命令观察一些,CPU 是不是都被 Java 程序占用了.比如下面这个截图: 服务器的 CPU 大多都被 Java 占用了.这正是我们之前生产上 CPU 过高的一个截图. 服务其CPU 还能超过 100%原因 在 Linux 上,多核 CPU 就会超过 100%.top 命令显示的是你的程序占用的 cpu 的总数,也就是说如果你是 4 核 cpu 那么 cpu 最高占用率可达 400%,top 里显示的是把所有使用率加起来. CPU 过高,这说明程序在进行计算…