btrace定位生产故障

现象

某些请求通过数据访问层很慢并导致处理线程阻塞,从监控中未能检查到异常。

编写btrace脚本

@BTrace
public class DBProxyTrace {

    @OnMethod(clazz = "xxx.xxx.QueryHandler", method = "query",
            location = @Location(Kind.RETURN))
    public static void trace2(String sql, @Duration long duration) {
        if (duration/1000000 > 10 * 1000) {
            com.sun.btrace.BTraceUtils.println(duration/1000000 + "ms");
            com.sun.btrace.BTraceUtils.println("this task executes more than 10s. the sql is : "
                    + sql);
            com.sun.btrace.BTraceUtils.println("jstack is : ");
            com.sun.btrace.BTraceUtils.jstack();
        }
    }
}

判断执行大于10秒的sql和堆栈信息。

编译脚本DBProxyTrace.java,确认脚本没有问题。

./bin/btracec  -cp build/ java/DBProxyTrace.java

执行脚本DBProxyTrace.class

./bin/btrace -cp build/ 17342  DBProxyTrace.class

信息

10468ms
this task executes more than 10s. the sql is : rollback
jstack is :
xxx.QueryHandler.query(QueryHandler.java:106)
xxx.net.AbstractConnection.onReadData(AbstractConnection.java:245)
xxx.net.NIOReactor$RW.run(NIOReactor.java:77)
java.lang.Thread.run(Thread.java:745)

定位

阻塞在事务回滚。

使用jstack进一步定位。

打印JVM堆栈

"$_NIOREACTOR-7-RW" prio=10 tid=0x00007f069856f000 nid=0xde1 waiting for monitor entry [0x00007f0677011000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:1167)
    - waiting to lock <0x000000068086fbc0> (a oracle.jdbc.driver.T4CConnection)

结论

阻塞在了oracle驱动rollback动作,这里其实是因为oracle驱动为了保证串行请求响应而在底层加了锁,而这个通道被慢语句塞住了,所以rollback塞了。

时间: 2024-10-23 23:55:27

btrace定位生产故障的相关文章

Java问题定位工具

JDK本身提供了很多方便的JVM性能调优监控工具,除了集成式的VisualVM和jConsole外,还有jps.jstack.jmap.jhat.jstat.hprof等小巧的工具 现实企业级Java开发中,有时候我们会碰到下面这些问题: OutOfMemoryError,内存不足 内存泄露 线程死锁 锁争用(Lock Contention) Java进程消耗CPU过高 ...... 这些问题在日常开发中可能被很多人忽视(比如有的人遇到上面的问题只是重启服务器或者调大内存,而不会深究问题根源),

线上服务 CPU 100%?一键定位 so easy!

转自:  https://my.oschina.net/leejun2005/blog/1524687 摘要: 本文主要针对 Java 服务而言 0.背景 经常做后端服务开发的同学,或多或少都遇到过 CPU 负载特别高的问题.尤其是在周末或大半夜,突然群里有人反馈线上机器负载特别高,不熟悉定位流程和思路的同学可能登上服务器一通手忙脚乱,定位过程百转千回. 对此,也有不少同学曾经整理过相关流程或方法论,类似把大象放进冰箱要几步,传统的方案一般是4步: top oder by with P:1040

万分之一错误率问题的分析及定位

本文主要描述网关上线的一次异常排查,分析排查问题的思路及过程. 通过本文,可以较好的了解网络,netty及http协议. 1问题背景 1 网关上线后有二万分之一的请求报500的错误. 2 升级了几个网关的业务域,但是只有一个业务域报错,其他业务域正常. 2基础知识 2.1 netty的worker模型 Netty的线程模型主要为Boss线程组和worker线程组. Boss线程负责接收连接,在tcp连接创建好后,会通过一定策略将连接(channel)绑定到worker线程上面. Worker线程

BTrace 使用,待实验 验证

主要参考以下几篇博客: http://agapple.iteye.com/blog/1005918 https://github.com/btraceio/btrace/releases/tag/v1.3.9 https://github.com/btraceio/btrace/issues 介绍javaAgent用法的文章(相当于在 JVM层加了一个AOP,获取方法的相关执行信息): http://blog.csdn.net/catoop/article/details/51034739 ht

Btrace入门到熟练小工完全指南

BTrace是神器,每一个需要每天解决线上问题,但完全不用BTrace的Java工程师,都是可疑的. BTrace的最大好处,是可以通过自己编写的脚本,获取应用的一切调用信息.而不需要不断地修改代码,加入System.out.println(), 然后重启,然后重启,然后重启应用!!! 同时,特别严格的约束,保证自己的消耗特别小,只要定义脚本时不作大死,直接在生产环境打开也没影响. 在网上搜索BTrace出来的文章都有点旧了,而且不够详细,于是决定,重新写一份. 码这么多的字好辛苦,请保留原文链

BTrace工具简介

What is Btrace? Java进程诊断分析工具 安全的工具 无侵入性 不修改应用任何应用数据 限制跟踪行为,没能有循环 依赖组件 使用OjbectWeb ASM组件来完成字节码层面上的跟踪分析 开源组件 项目主页:http://btrace.dev.java.net GPLv2 + CLASSPATH Exception VisualVM 插件和开发时插件 BTrace应用较为广泛的原因应该是其安全性和无侵入性,已经热交互技术,使得我们无需启动Agent的情况下动态跟踪分析,其安全性不

用“逐步排除”的方法定位Java服务线上“系统性”故障(转)

一.摘要 由于硬件问题.系统资源紧缺或者程序本身的BUG,Java服务在线上不可避免地会出现一些“系统性”故障,比如:服务性能明显下降.部分(或所 有)接口超时或卡死等.其中部分故障隐藏颇深,对运维和开发造成长期困扰.笔者根据自己的学习和实践,总结出一套行之有效的“逐步排除”的方法,来快速定 位Java服务线上“系统性”故障. 二.导言 Java语言是广泛使用的语言,它具有跨平台的特性和易学易用的特点,很多服务端应用都采用Java语言开发.由于软件系统本身以及运行环境的复杂 性,Java的应用不

使用BTRACE定位系统中慢的问题

在访问页面请求的时候,如果系统执行效率低,我们怎样才能定位到这些页面请求呢?   java 有一个十分有效的动态跟踪工具-btrace 网址:https://kenai.com/projects/btrace/downloads   比如希望定位我们的控制器代码哪些方法慢:   1.我们可以编写如下类:   package demo; import com.sun.btrace.annotations.BTrace; import com.sun.btrace.annotations.Kind;

Btrace使用教程

下载 下载链接:https://github.com/btraceio/btrace/releases/tag/v1.3.9 安装及环境配置 1.下载一个压缩包 2.解压 3.配置环境变量 sudo vi /etc/profile 添加 export BTRACE\_HOME=/home/josonliu/btrace export PATH=$PATH:$BTRACE\_HOME/bin PS:BTRACE\_HOME必须是你解压的路径 4.使配置生效 source /etc/profile