Closed kongwu- closed 4 years ago
我们在去哪儿生产环境已经大规模部署超过半年了,目前看来是没有什么影响的。 影响就两个方面,一个是agent会作为一个java程序在应用同机器上运行,会占用一定的内存,这个现在默认堆内存是80M,你自己也可以调整,如果内存非常紧张的话也会有点影响;一个就是执行命令的影响,这个得看具体的应用和命令,比如dump内存这些肯定影响大,不过这些命令使用者自身应该是比较清楚的。 我们加的一些东西,比如cpu监控,在线debug,动态监控这些都影响很小,如果你使用过程中发现什么问题也可以给我们提一下。后面我们也会考虑在各个命令文档里标注会做哪些操作好让使用者做评估
我们在去哪儿生产环境已经大规模部署超过半年了,目前看来是没有什么影响的。 影响就两个方面,一个是agent会作为一个java程序在应用同机器上运行,会占用一定的内存,这个现在默认堆内存是80M,你自己也可以调整,如果内存非常紧张的话也会有点影响;一个就是执行命令的影响,这个得看具体的应用和命令,比如dump内存这些肯定影响大,不过这些命令使用者自身应该是比较清楚的。 我们加的一些东西,比如cpu监控,在线debug,动态监控这些都影响很小,如果你使用过程中发现什么问题也可以给我们提一下。后面我们也会考虑在各个命令文档里标注会做哪些操作好让使用者做评估
你好,现在是每个java程序都对应一个agent吧。如果一台机器上有多个java程序,是不是也要相应启动多个agent呢?
当前仅支持单机单应用,所以如果一台机器上有多个Java程序就只有其中某一个能使用bistoury
看了下debug的字节码增强代码
会在断点位置调用GlobalDebugContext.hasBreakpointSet
来判断是否要执行断点逻辑, 该方法具体实现如下
public static boolean hasBreakpointSet(final Location location) {
synchronized (breakpoints) {
return breakpoints.containsKey(location);
}
}
这里用synchronized,即使断点被移除了,所有请求跑到这里都会同步一下,对生成是否会造成影响?
看了下debug的字节码增强代码 会在断点位置调用
GlobalDebugContext.hasBreakpointSet
来判断是否要执行断点逻辑, 该方法具体实现如下public static boolean hasBreakpointSet(final Location location) { synchronized (breakpoints) { return breakpoints.containsKey(location); } }
这里用synchronized,即使断点被移除了,所有请求跑到这里都会同步一下,对生成是否会造成影响?
这个影响是非常小的。 首先同步代码块里只执行了一个contains判断,这个判断非常快;而在同步代码块执行的代码非常快的时候,同步的性能影响是非常小的。怎么说呢,像ArrayBlockingQueue的每个offer和poll操作都有同步,它的吞吐量依然非常大。
看了下debug的字节码增强代码 会在断点位置调用
GlobalDebugContext.hasBreakpointSet
来判断是否要执行断点逻辑, 该方法具体实现如下public static boolean hasBreakpointSet(final Location location) { synchronized (breakpoints) { return breakpoints.containsKey(location); } }
这里用synchronized,即使断点被移除了,所有请求跑到这里都会同步一下,对生成是否会造成影响?
这个影响是非常小的。 首先同步代码块里只执行了一个contains判断,这个判断非常快;而在同步代码块执行的代码非常快的时候,同步的性能影响是非常小的。怎么说呢,像ArrayBlockingQueue的每个offer和poll操作都有同步,它的吞吐量依然非常大。
ok,多谢解答 最近调研在线debug方案,发现了这么个好东西,感谢😄
请问bistoury对性能影响有多大呢,生产环境一直启动会有影响吗。
感觉加了GUI之后更像监控工具了,而不是调试工具,如果当作监控工具来用,一直开启会不会对性能影响较大,毕竟加了一个agent。。