survior

> @starcwang，可以的，主要是前端需要做一些改造，大家如果有余力的话，可以帮忙提PR。后续我们也会看一下这块。 我看前几天发布了1.1.0版本，portal这块有很多改进，是不是已经解决了这个效率问题了呢？

@rayzhang0603 方便了解下新浪现在是用的哪种方式做的链路追踪么。

@rayzhang0603 motan支持除jdk动态代理之外的实现么？是否有配置,还是需要自己根据spi去实现呢？

> 你提到的问题场景中，motan使用的哪个版本？是否使用了`compressMotan`协议？ 我们使用的是motan1.1.1, 没有显示声明compressMotan，使用的默认值，这个默认值怎么设置呢？配置清单里貌似没有。

> 比如说dubbo是支持多种方式，jdk动态代理，javassist都支持。 > > 这个需求点触发场景： > 我们在调研skywalking探针，发现referer启动后耗费大量native memory，参见：[apache/incubator-skywalking#1666](https://github.com/apache/incubator-skywalking/issues/1666) 这个问题的触发点是： 我们在k8s管理的docker容器实例里启动app, docker容器内存上线是1.5G，开xms=500M, xmx=1024M。 在不使用skywalking-agent情况下可以启动并且正常运行，但如果加上skywalking-agent后启动容器实例直接被K8S kill，超过了容器物理内存上限。但是如果物理内存开大，比如2.5G，还是同样的jvm参数，即使开启skywalking-agent，也正常，只是top res会高。 当然我们给docker容器的内存上限加大点内存就可以了。但是我想知道这是由哪个点引起的，现在有多个疑点但是不确认是哪个。 只是通过gperftools分析的时候发现gzip相关的native调用有大幅提升，大概升了70~100%左右的样子。

> 我们以前碰到过这样的问题，是使用`new GZIPInputStream(InputStream in)`时，如果InputStream中的data不是gzip时，会先创建Inflater，然后在抛出异常，这时创建的Inflater会在finalizer中回收，回收的时间是不确定的，会造成堆外内存占用过大的问题。 > > 你可以看看是不是也是类似的场景 对对，是这个，这个咋解决啊。

> 在不使用skywalking-agent情况下可以启动并且正常运行，但如果加上skywalking-agent后启动容器实例直接被K8S kill，超过了容器物理内存上限。但是如果物理内存开大，比如2.5G，还是同样的jvm参数，即使开启skywalking-agent，也正常，只是top res会高。 也就是说，当和skywalking-agent配合使用时，出现的kill现象的原因： 很有可能是skywalking或者引用的相关包存在大量使用gzipinputstrem的情况，没有做gzip格式校验，而触发底层native call. skywalking的code里没有直接使用gzip，不确定mvn import有没有；引用的相关包里肯定有，因为gperftools有打印。 非常感谢~