Memory Analyzer

RocketMQ与Dubbo相爱相杀引起的FullGC

有些话、适合烂在心里 提交于 2020-12-07 06:46:28
在日常后端开发中,部分业务都是接收MQ消息,在消费消息的过程中,会调用外部的Dubbo接口,根据接口返回数据,做一些业务逻辑处理.如下图 上面会涉及两类线程,一类是MQ线程,一类是Dubbo线程. Dubbo接口调用超时也是经常会发生的事情,这篇文章中,我们模拟的情况是,让Dubbo接口调用超时,图中红线所示.然后一直向MQ消费者发送消息,我们观察线程和堆栈的变化. 仓库代码 https: //github.com/infuq/MQ-Dubbo-FullGC 如果需要运行上述代码,还需要部署Zookeeper和RocketMQ环境. 工程结构如下图 Dubbo提供者的接口超时时间设置的是5s.如下图 而在提供者的实现方法中,让线程睡眠20秒,从而达到调用者调用接口超时目的.如下图 接下来按顺序启动它们 首先启动Dubbo提供者(DubboProvider类). 接着启动MQConsumer, 同时需要给它配置VM启动参数 -Xms90M -Xmx90M -XX :+PrintGCDetails 最后启动MQProducer, 它会一直发送消息. 所有的都启动完成之后, 借助JDK自带的jvisualvm.exe工具观察MQConsumer的堆栈信息. 观察MQConsumer的堆栈信息,会发现老年代会一直增长,当老年代快增长到顶端时,手动dump堆栈信息,用于接下来分析堆的情况.

android monkey压力测试(二)

假如想象 提交于 2020-11-15 18:17:10
一、什么是Monkey 顾名思义,Monkey就是猴子, Monkey测试,就像一只猴子, 在电脑面前,乱敲键盘在测试。 猴子什么都不懂, 只知道乱敲 通过Monkey程序模拟用户触摸屏幕、滑动Trackball、 按键等操作来对设备上的程序进行压力测试,检测程序多久的时间会发生异常。 二、Monkey简介 monkey官方文档 (需要翻墙) monkey源码 monkey程序由Android系统自带,使用java语言写成,在Android文件系统中存放路径:/system/framework/monkey.jar; monkey.jar程序由一个名为“monkey”等shell脚本来启动执行,shell脚本在Android文件系统中的存放路径:/system/bin/monkey; 因为monkey测试是一种为了测试软件的稳定性、健壮性(是否会发生闪退、崩溃和无响应问题)的快速有效方法 基本语法 $adb shell monkey [option] <event-count> 如果不指定options,即类似于使用adb shell monkey 1000,那么将会对整个系统中安装的package发送事件流,换种说法就是对整个Android系统进行monkey压力测试 这是一个对指定应用(Android自带的系统设置应用)进行monkey测试的栗子,发送的事件流数量为1000:

JVM 内存了解

点点圈 提交于 2020-10-29 08:39:40
说说JVM的内存布局? Java虚拟机主要包含几个区域: 堆:堆Java虚拟机中最大的一块内存,是线程共享的内存区域,基本上所有的对象实例数组都是在堆上分配空间。堆区细分为Yound区年轻代和Old区老年代,其中年轻代又分为Eden、S0、S1 3个部分,他们默认的比例是8:1:1的大小。 栈:栈是线程私有的内存区域,每个方法执行的时候都会在栈创建一个栈帧,方法的调用过程就对应着栈的入栈和出栈的过程。每个栈帧的结构又包含局部变量表、操作数栈、动态连接、方法返回地址。 局部变量表用于存储方法参数和局部变量。当第一个方法被调用的时候,他的参数会被传递至从0开始的连续的局部变量表中。 操作数栈用于一些字节码指令从局部变量表中传递至操作数栈,也用来准备方法调用的参数以及接收方法返回结果。 动态连接用于将符号引用表示的方法转换为实际方法的直接引用。 元数据:在Java1.7之前,包含方法区的概念,常量池就存在于方法区(永久代)中,而方法区本身是一个逻辑上的概念,在1.7之后则是把常量池移到了堆内,1.8之后移出了永久代的概念(方法区的概念仍然保留),实现方式则是现在的元数据。它包含类的元信息和运行时常量池。 Class文件就是类和接口的定义信息。 运行时常量池就是类和接口的常量池运行时的表现形式。 本地方法栈:主要用于执行本地native方法的区域 程序计数器:也是线程私有的区域

开会时CPU 飙升100%同事们都手忙脚乱记一次应急处理过程

独自空忆成欢 提交于 2020-10-06 03:14:22
告警 正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。 赶紧从会上下来,SSH登录服务器,使用 top 命令查看,几个Java进程CPU占用达到180%,190%,这几个Java进程对应同一个业务服务的几个Pod(或容器)。 定位 使用 docker stats 命令查看本节点容器资源使用情况,对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看,定位到占用CPU高的进程ID,使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器, 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机,便于查看。获取到jstack信息后,赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133,则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置,该位置即为占用CPU高线程的执行栈信息

好程序员Java培训分享Java性能常见命令有哪些

与世无争的帅哥 提交于 2020-08-17 17:20:58
  好程序员Java培训分享Java性能常见命令有哪些,性能优化一向是后端服务优化的重点,但是线上性能故障问题不是经常出现,或者受限于业务产品,根本就没办法出现性能问题,包括笔者自己遇到的性能问题也不多,所以为了提前储备知识,当出现问题的时候不会手忙脚乱。   既然是定位问题,肯定是需要借助工具,我们先了解下需要哪些工具可以帮忙定位问题。   top命令   top命令是我们最常用的Linux命令之一,它可以实时的显示当前正在执行的进程的CPU使用率,内存使用率等系统信息。top -Hp pid 可以查看线程的系统资源使用情况。   vmstat命令   vmstat是一个指定周期和采集次数的虚拟内存检测工具,可以统计内存,CPU,swap的使用情况,它还有一个重要的常用功能,用来观察进程的上下文切换。字段说明如下:   r: 运行队列中进程数量(当数量大于CPU核数表示有阻塞的线程)   b: 等待IO的进程数量   swpd: 使用虚拟内存大小   free: 空闲物理内存大小   buff: 用作缓冲的内存大小(内存和硬盘的缓冲区)   cache: 用作缓存的内存大小(CPU和内存之间的缓冲区)   si: 每秒从交换区写到内存的大小,由磁盘调入内存   so: 每秒写入交换区的内存大小,由内存调入磁盘   bi: 每秒读取的块数   bo: 每秒写入的块数   in:

记一次线上服务CPU 100%的处理过程

那年仲夏 提交于 2020-08-15 23:50:05
告警 正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。 赶紧从会上下来,SSH登录服务器,使用 top 命令查看,几个Java进程CPU占用达到180%,190%,这几个Java进程对应同一个业务服务的几个Pod(或容器)。 定位 使用 docker stats 命令查看本节点容器资源使用情况,对占用CPU很高的容器使用 docker exec -it <容器ID> bash 进入。 在容器内部执行 top 命令查看,定位到占用CPU高的进程ID,使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器, 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机,便于查看。获取到jstack信息后,赶紧重启服务让服务恢复可用。 将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133,则得到十六进制85。在jstack.txt文件中定位到 nid=0x85 的位置,该位置即为占用CPU高线程的执行栈信息

记录OOM GC问题

时光总嘲笑我的痴心妄想 提交于 2020-08-15 21:52:57
首先排查TOP 查看哪个进程占用CPU比例高 执行 jstack java 4372(进程号) >> cpu.txt ,将进程线程使用情况输出到文件内 执行top -H -p 4372 查看线程 4377 将其转成 16 进制 为 1119,到刚才 jstack导出来的cpu.txt中搜索1119线程 然后执行 jmap -dump:format=b,file=heapdump.bin 4372 将其dump下来, 最后用 MemoryAnalyzer 工具打开,分析具体排查问题 来源: oschina 链接: https://my.oschina.net/u/3370769/blog/4293720

记一次线上服务CPU 100%的处理过程

痴心易碎 提交于 2020-08-15 03:49:13
告警 正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。 赶紧从会上下来,SSH登录服务器,使用 top 命令查看,几个Java进程CPU占用达到180%,190%,这几个Java进程对应同一个业务服务的几个Pod(或容器)。 定位 使用 docker stats 命令查看本节点容器资源使用情况,对占用CPU很高的容器使用 docker exec -it <容器ID> bash 进入。 在容器内部执行 top 命令查看,定位到占用CPU高的进程ID,使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器, 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机,便于查看。获取到jstack信息后,赶紧重启服务让服务恢复可用。 将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133,则得到十六进制85。在jstack.txt文件中定位到 nid=0x85 的位置,该位置即为占用CPU高线程的执行栈信息

开会时CPU 飙升100%同事们都手忙脚乱记一次应急处理过程

青春壹個敷衍的年華 提交于 2020-08-12 05:16:30
告警 正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。 赶紧从会上下来,SSH登录服务器,使用 top 命令查看,几个Java进程CPU占用达到180%,190%,这几个Java进程对应同一个业务服务的几个Pod(或容器)。 定位 使用 docker stats 命令查看本节点容器资源使用情况,对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看,定位到占用CPU高的进程ID,使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器, 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机,便于查看。获取到jstack信息后,赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133,则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置,该位置即为占用CPU高线程的执行栈信息

开会时CPU 飙升100%同事们都手忙脚乱记一次应急处理过程

放肆的年华 提交于 2020-08-12 00:40:26
告警 正在开会,突然钉钉告警声响个不停,同时市场人员反馈客户在投诉系统登不进了,报504错误。查看钉钉上的告警信息,几台业务服务器节点全部报CPU超过告警阈值,达100%。 赶紧从会上下来,SSH登录服务器,使用 top 命令查看,几个Java进程CPU占用达到180%,190%,这几个Java进程对应同一个业务服务的几个Pod(或容器)。 定位 使用 docker stats 命令查看本节点容器资源使用情况,对占用CPU很高的容器使用 docker exec -it <容器ID>bash 进入。 在容器内部执行 top 命令查看,定位到占用CPU高的进程ID,使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器, 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机,便于查看。获取到jstack信息后,赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133,则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置,该位置即为占用CPU高线程的执行栈信息