前言
很多时候我们需要知道更多的程序的运行细节,但又不可能在开发的时候就把程序中所有的运行细节都打印到日志上,通常这个时候能采取的就是修改代码,重新部署,然后再观察,但这种方法对于online应用来说不是很好,另外一方面如果碰到不好改的代码,例如引用的其他的外部的包什么的,就很麻烦了,BTrace就是一个可以在不改代码、不重启应用的情况下,动态的查看程序运行细节的工具,下面这篇文章就介绍了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塞了。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流。
本文档介绍 DM 的错误系统及常见故障的处理方法。 DM 错误系统 在 DM 的错误系统中,对于一条特定的错误,通常主要包含以下信息: code:错误码。 同一种错误都使用相同的错误码。错误码不随 DM 版本改变。 在 DM 迭代过程中,部分错误可能会被移除,但错误码不会。新增的错误会使用新的错误码,不会复用已有的错误码。 class:发生错误的类别。 用于标记出现错误的系统子模块。 下表展示所有
主要内容:一、业务场景介绍,二、问题凸现,三、定位问题,四、解决问题这篇文章给大家聊一次线上生产系统事故的解决经历,其背后代表的是线上生产系统的JVM FullGC可能引发的严重故障。 一、业务场景介绍 先简单说说线上生产系统的一个背景,因为仅仅是文章作为案例来讲,所以弱化大量的业务背景。 简单来说,这是一套分布式系统,系统A需要将一个非常核心以及关键的数据通过网络请求,传输给另外一个系统B。 所以这里其实就考虑到了一个问题,如果系统A刚刚将核心数据传递给了系统B
本文向大家介绍检测MySQL的表的故障的方法,包括了检测MySQL的表的故障的方法的使用技巧和注意事项,需要的朋友参考一下 表的故障检测和修正的一般过程如下: 检查出错的表。如果该表检查通过,则完成任务,否则必须修复出错的数据库表。 在开始修复之前对表文件进行拷贝,以保证数据的安全。 开始修复数据库表。 如果修复失败,从数据库的备份或更新日志中恢复数据。 在使用myisamchk或isamchk检
以下这段代码在编译期间会产生分段错误: (gdb)运行 启动程序: /home/anna/Desktop/a.out 程序接收信号SIGSEGV,分段故障。 0xb7e97845在strtok()从 /lib/i386-linux-gnu/libc.so.6 更改第5行后,不会引发任何错误。 为什么会发生这种情况?
有人知道这个错误是怎么回事吗??
我正在使用故障保护(https://github.com/jhalterman/failsafe)作为我的重试逻辑框架,我想更多地了解故障保护的“运行”方法是如何工作的。 假设我有: 那么当运行时,是否会阻止MyMONt款额的执行?换句话说,是否会在所有重试完成之前执行?