BTrace 是什么 BTrace 是检查和解决线上的问题的杀器,BTrace 可以通过编写脚本的方式,获取程序执行过程中的一切信息,并且,注意了,不用重启服务,是的,不用重启服务。 目前 BTrace 的最新版本为 1.3.9,代码托管在 [github] 上。 可以看到刚刚执行的 java 进程为 10860 4. 按ctrl + c ,会给出退出提示,再按 1 退出 使用场景 BTrace 是一个事后工具,所谓事后工具就是在服务已经上线了,但是发现存在以下问题的时候,可以用 BTrace。 精准定位 直接定位到一个类下的一个方法,上面测试用的例子就是 2.
Arthas 是一款命令行交互模式的 Java 诊断工具,由于是 Java 编写,所以可以直接下载相应 的 jar 包运行。 -h 运行 Arthas 是一个 java 程序,所以直接用 java -jar 运行。 运行时或者运行之后要选择要监测的 Java 进程。 (可以概览程序的 线程、内存、GC、运行环境信息) thread 查看当前 JVM 的线程堆栈信息 watch 方法执行数据观测 trace 方法内部调用路径,并输出方法路径上的每个节点上耗时 stack 的继承树,urls,类加载信息 heapdump 类似 jmap 命令的 heap dump 功能 任何一个命令后接-help可以看到这个命令的更多用法 例如 thread -b 可以列出死锁线程
代金券、腾讯视频VIP、QQ音乐VIP、QB、公仔等奖励等你来拿!
https://blog.csdn.net/wh211212/article/details/84866727 java线上服务问题排查 1、业务日志相关 如果应用系统出现异常,一般都会在业务日志中体现 整体上分为Error、Exception两个大类,Exception大类又分为UncheckedException(继承于RuntimeException)和CheckedException(继承于Exception 进程的具体状态, 包括进程ID,进程启动的路径及启动参数等等,与unix上的ps类似,只不过jps是用来显示java进程,可以把jps理解为ps的一个子集。 HTML服务器,让用户可以在浏览器上查看分析结果 jstack Stack Trace for java,显示虚拟机的线程快照。 关于MAT使用不详述了,google上一堆(http://inter12.iteye.com/blog/1407492)。
二、找出某个java应用打开的句柄数及线程数 ll /proc/{pid}/fd | wc -l 查看打开的句柄数 ll /proc/{pid}/task | wc -l 查看线程数 三、jmap 查看堆内存的各项配置 java7与java8的内存变化,大致如上图。 我们就把最忙的这个线程BUSY THREAD给找出来了(注:这个技巧再次说明了,给线程取个好名字相当重要!) 也可以查看哪些线程最忙 ? 以上图为例:红剪头的地方,S0区的已用量降到0,而S1区的已用量上涨,即说明发生了Young GC,对象从S0区被迁移到了S1区。
前言 针对各种常见的线上问题,梳理下排查思路。 测试环境搭建 既然要模拟排查线上问题,就不能使用本地环境。 至少是个 Linux 操作系统,最好还是个纯粹的 Java 环境。 在线定位(Arthas 工具) Arthas 是阿里开源的 Java 诊断工具。Arthas 还提供了在线工具学习工具,帮助快速上手。 一般对于线上问题,都是采用这样的步骤: 先将机器和集群隔离开来 马上调用 jmap -dump 命令将 Java 堆的现场情况保存下来 对问题机器中的进程进行重启,恢复上线 将保存下来的 dump 文件导到本地进行分析 但使用 Java VisualVM 会占用较多资源,所以一般线上环境中不会使用,实在要在线定位问题的话,生产上通常选择前面说到的 Arthas + 原生命令(主要是 jmap 命令)的方式进行。 虽然在生产上使用有性能问题,但在上线前的测试环境压测,使用 Java VisualVM 进行监控还是十分方便: 监控 CPU 、堆、类加载情况和线程数量: 查看线程调度情况:
作者:霞落满天 第一部分 是我以前公司的一则正式案例: 第二部分 是我另一个博客上写的主要是最近发现大家问的比较多就写了此文 第一部分 线上真实故障案例 下面是一个老系统,代码写的有点问题导致出现这样一个 2、 建议查看一下dump文件中的线程消耗CPU情况, a、可能是有线程在不停的循环造成的CPU过高; b、 gc线程不停回收造成? 线上问题当时的CPU占用情况如图所示: ? ========================= 第二部分 JVM常见排障步骤 0.jps 这个输出java进程pid #jps 查看java的线程 #top -Hp 25448 ? 3.如果说该接口中有某个位置是比较耗时的,由于我们的访问的频率非常高,那么大多数的线程最终都将阻塞于该阻塞点,这样通过多个线程具有相同的堆栈日志,我们基本上就可以定位到该接口中比较耗时的代码的位置。 这些都可以排除掉,而剩下的线程基本上就可以确认是我们要找的有问题的线程。通过其堆栈信息,我们就可以得出具体是在哪个位置的代码导致该线程处于等待状态了。 5.deadlock死锁这种情况基本上很容易发现
通过Arthas我们可以在线排查问题,无需重启;动态跟踪Java代码;实时监控JVM状态。 2、Arthas有哪些特性 实时查看系统的运行状况 查看函数调用的参数,返回值和异常 代码在线热更新 秒解类冲突问题,定位类加载路径 快速定位应用的热点,生成火焰图 在线诊断,点开网页诊断线上应用 3、 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现! 是否有一个全局视角来查看系统的运行状况? 4、安装 下载arthas-boot.jar,然后用java -jar的方式启动 curl -O https://arthas.aliyun.com/arthas-boot.jar java -jar language=cn 里面除了可以在线实操Arthas还可以查看相关用户案例,有助于大家进一步上手Arthas 参考文档 https://arthas.aliyun.com/zh-cn/
作者 | fredalxin 线上故障主要会包括 CPU、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。 Java 栈,基本上还是线程池代码写的有问题,比如说忘记 shutdown,所以说应该首先从代码层面来寻找问题,使用 jstack 或者 jmap。 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 这个意思是堆的内存占用已经达到-Xmx 设置的最大值,应该是最常见的 往往是由于某个地方阻塞住了,没有正常关闭连接,从而渐渐地消耗完所有的线程。 想要定位这类问题,最好是通过 jstack 来分析线程堆栈来排查问题,具体可参考上述章节。这里仅举一个例子。 开发同学说应用上线后 CLOSE_WAIT 就一直增多,直到挂掉为止,jstack 后找到比较可疑的堆栈是大部分线程都卡在了countdownlatch.await方法,找开发同学了解后得知使用了多线程但是确没有
Java常见线上问题 所有的Java线上问题从系统表现来看无非归咎于这几种:CPU,内存,磁盘,网络。比如CPU突然飙升赞满,内存溢出,网络异常,磁盘爆满等问题。 二. 定位到高占用CPU进程后再使用 top -Hp pid 命令定位到具体是哪个线程。 将上一步获取到的线程id转换成16进制 printf '%x\n' pid 得到 nid。 之后我们需要使用 jstack pid |grep 'nid' -C5 –color 来查看上述进程中线程的堆栈信息。 找到对应线程的堆栈信息后看看具体是业务线程还是其他线程,比如gc线程。 总结 遇到线上问题千万不要慌乱,先将程序恢复正常后再慢慢排查问题。 分别查看日志,查看CPU情况,查看java线程,jstack,查看java堆,jmap,最后通过MAT分析堆文件,寻找无法被回收的对象,来找到代码层面的问题。
摘要: Fundebug竭诚为你的Java程序保驾护航。 ? 理论上讲,BUG是无法避免的,实时监控可以帮助开发者第一时间发现BUG,及时修复BUG,将BUG的影响降到最低。 为什么监控Java 有些童鞋可能会问,后端语言有报错日志,为什么还需要监控? 不错,后端代码报错,我们会打印报错日志。但一般情况下我们不知道报错了,这需要等到用户反馈后,我们再去服务器上查看日志。 这个时候有一款监控Java程序的插件,就可以为我们省去以上烦恼。 接入Fundebug 1.下载Fundebug的Java插件fundebug.0.1.0.min.jar 2.在代码中引入Fundebug并配置apikey: import com.fundebug.Fundebug 具体步骤请查看Fundebug文档 版权声明 转载时请注明作者 Fundebug以及本文地址: https://blog.fundebug.com/2018/07/03/installation-java
如何减少上线文切换 减少上下文切换的方法有 1、无锁并发编程。 Java的Atomic包使用CAS(compare and swap)算法来更新数据,而不需要加锁。 3、使用最少线程。 减少上下文切换的例子 下面我们看一个通过减少线上大量WAITING的线程,来减少上下文切换次数的例子: 使用jstack命令dump线程信息,看看pid为3117的进程里的线程都在做什么 sudo -u admin /opt/java/bin/jstack 31177 > /home/java/dump17 统计所有线程分别处于什么状态,发现300多个线程处于WAITING(onobjectmonitor 这种切换称为“上下文切换”(“context switch”)。CPU会在一个上下文中执行一个线程,然后切换到另外一个上下文中执行另外一个线程。上下文切换并不廉价,是比较耗时的
前言 在使用 Arthas 之前,当遇到 Java 线上问题时,如 CPU 飙升、负载突高、内存溢出等问题,你需要查命令,查网络,然后 jps、jstack、jmap、jhat、jstat、hprof 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 有什么办法可以监控到 JVM 的实时运行状态? 命令 介绍 dashboard 当前系统的实时数据面板 thread 查看当前 JVM 的线程堆栈信息 watch 方法执行数据观测 trace 方法内部调用路径,并输出方法路径上的每个节点上耗时 stack 使用命令 thread 12 查看 CPU 消耗较高的 12 号线程信息,可以看到 CPU 使用较高的方法和行数(这里的行数可能和上面代码里的行数有区别,因为上面的代码在我写文章时候重新排过版了)。 上面是先通过观察总体的线程信息,然后查看具体的线程运行情况。
一个多线程的java应用,不管使用了什么样的同步机制,最终都要用JVM执行同步处理,而JVM本身也是linux上的一个进程,那么java应用的线程同步机制,可以说是对操作系统层面的同步机制的上层封装。 lock,在WAIT期间,线程不再参与任务调度,因此存在上下文切换而导致的开销。 OS的其他同步操作 除了上述的lock算法实现线程同步,另外操作还提供lock-free的方式实现同步。 Java应用中的一些同步机制 Java应用层中一些常用的同步机制,一般是对底层lock或lock-free同步机制得一些封装。 AQS AQS是Java中的一套线程同步框架,依赖于FIFO的等待队列来实现同步或lock机制,对于大多数依赖于一个atomicint来表示状态的同步场景都可以使用AQS框架。
一、什么是 Arthas Arthas 是 Alibaba开源的一款 Java 诊断工具,能够查看 Java 应用的线程状态、JVM 信息等,支持在线对业务问题诊断,比如查看方法调用的出入参、执行过程 、抛出的异常、输出方法执行耗时等,大大提升了线上问题的排查效率。 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现! 是否有一个全局视角来查看系统的运行状况? [arthas@1]$ 从上面查看所有的 threads 来看 1572 消耗CPU 17%(此百分比是按单 CPU 计算的)。所以需要查看这个线程在做什么。 3.39 0.00% 七、总结 在本文我主要介绍了 Arthas 是什么、为什么使用 Arthas,以及通过实际操作演示 Arthas 常用命令是如何使用的的,操作实例都是比较典型的排查线上问题的方式
swap 上存储的内容时,再将 swap 上的数据加载到内存中,这就是常说的换出和换入。 cs:表示每秒产生的上下文切换次数,这个值要越小越好,太大了,要考虑调低线程或者进程的数目。 Shift + H显示java线程;Shift + M按照内存使用排序;Shift + P按照CPU使用时间(使用率)排序;Shift + T按照CPU累积使用时间排序;多核CPU,进入top视图1,可以看到各各 %idle的值持续低于 10,则系统的 CPU 处理能力相对较低,表明系统中最需要解决的资源是 CPU; 定位线上最耗CPU的线程 准备工作 启动一个程序。 -l: [root@localhost ~]# ps -ef | grep java| wc -l2 查看线程是否存在死锁 查看线程是否存在死锁,jstack -l pid: [root@localhost
---- Pre 当你的应用没有一套完善的监控告警系统,线上故障了 ,总是很被动,但是还得要定位问题 ,奈何手里无利器 ,没办法只能硬上了,虽然原始,好在有效~ 所以原生的命令你需要特别熟悉,故障的时间很宝贵 jmap Java 内存映射工具 + jhat 虚拟机堆转储快照分析工具 jmap Java 内存映射工具 + MAT (推荐) jmap Java 内存映射工具 概述 ? tid ,shift+p 按照CPU消耗大小【H 线程模式 】 print "%\n" tid 【将获取到的线程号转换成16进制】, 用于导出的线程堆栈中根据该关键字查到对应的线程信息 (或者 printf a java.lang.Object) Locked ownable synchronizers: - None ...... ....... .......... ---- 线上分析工具 遇到问题无法在线上 debug,难道只能通过加日志再重新发布吗? 线上遇到某个用户的数据处理有问题,但线上同样无法 debug,线下无法重现!
前言 当你兴冲冲地开始运行自己的Java项目时,你是否遇到过如下问题: 程序在稳定运行了,可是实现的功能点了没反应。 为了修复Bug而上线的新版本,上线后发现Bug依然在,却想不通哪里有问题? 以前,你碰到这些问题,解决的办法大多是,修改代码,重新上线。但是在大公司里,上线的流程是非常繁琐的,如果为了多加一行日志而重新发布版本,无疑是非常折腾人的。 现在,我们有了更为优雅的线上调试方法,来自阿里巴巴开源的Arthas 下图是Arthas文档中对于为什么要使用它的描述,我进行了精简: ? :看看线上Debug还有没有别的工具可以使用 原理浅谈:莫在浮沙筑高阁! 总结 Arthas是一个线上Debug神器,小白也可以轻松上手。
为了修复Bug而上线的新版本,上线后发现Bug依然在,却想不通哪里有问题? 以前,你碰到这些问题,解决的办法大多是,修改代码,重新上线。但是在大公司里,上线的流程是非常繁琐的,如果为了多加一行日志而重新发布版本,无疑是非常折腾人的。 现在,我们有了更为优雅的线上调试方法,来自阿里巴巴开源的Arthas 下图是Arthas文档中对于为什么要使用它的描述,我进行了精简: ? :看看线上Debug还有没有别的工具可以使用 原理浅谈:莫在浮沙筑高阁! 总结 Arthas是一个线上Debug神器,小白也可以轻松上手。
Serverless HTTP 基于腾讯云 API 网关平台,为互联网业务提供 0 配置、高可用、弹性扩展的对外 RESTful API 能力,支持 swagger/ openAPI 等协议。便于客户快速上线业务逻辑,通过规范的 API 支持内外系统的集成和连接。
扫码关注云+社区
领取腾讯云代金券