dubbo-go
dubbo-go copied to clipboard
apache
common.MergeURL占用内存一直上升
初步怀疑像先merge了一个 url，然后在把 url 更新到event里，下次从event里面在拿出来在 merge，有更详细的复现步骤么 @fubug
try
func MergeURL(serviceURL *URL, referenceURL *URL) *URL {
// After Clone, it is a new URL that there is no thread safe issue.
mergedURL := serviceURL.Clone()
// iterator the referenceURL if serviceURL not have the key ,merge in
// referenceURL usually will not changed. so change RangeParams to GetParams to avoid the string value copy.// Group get group
for key, value := range referenceURL.GetParams() {
if _, ok := mergedURL.GetNonDefaultParam(key); !ok {
if len(value) > 0 {
mergedURL.params[key] = value
}
}
}
// loadBalance,cluster,retries strategy config
methodConfigMergeFcn := mergeNormalParam(mergedURL.params, referenceURL, []string{constant.LoadbalanceKey, constant.ClusterKey, constant.RetriesKey, constant.TimeoutKey})
// remote timestamp
if v, ok := serviceURL.GetNonDefaultParam(constant.TimestampKey); !ok {
mergedURL.params[constant.RemoteTimestampKey] = []string{v}
mergedURL.params[constant.TimestampKey] = []string{referenceURL.GetParam(constant.TimestampKey, "")}
}
// finally execute methodConfigMergeFcn
for _, method := range referenceURL.Methods {
for _, fcn := range methodConfigMergeFcn {
fcn("methods." + method)
}
}
// In this way, we will raise some performance.
return mergedURL
}
如果可以的话，发一下内存的增长的截图。如果有条件的发下 内存 diff profile的log
curl -s http://127.0.0.1:8080/debug/pprof/heap > 1231.heap
过 一段时间 (5m, 10m, 30m, 1h)
curl -s http://127.0.0.1:8080/debug/pprof/heap > 1241.heap
go tool pprof --http :9090 --base 1231.heap 1241.heap
截图失真比较严重，辛苦下载下来看下吧https://github.com/fubug/go/blob/main/start%20inuse_space.html
这个问题还没有修复吗？？调用链，config.Load->refConfig.Refer->common.MergeURL，没有调用很多次，咋来的内存溢出
这个问题还没有修复吗？？调用链，config.Load->refConfig.Refer->common.MergeURL，没有调用很多次，咋来的内存溢出
平常状态下比较难复现，你也是 go 调用 java 么？
这是我的配置文件
dubbo:
registries:
demoZK: # 定义服务注册发现中心
protocol: zookeeper
address: x.x.x.x:2181
demoZK2: # 定义服务注册发现中心
protocol: zookeeper
address: x.x.x.x:2182
demoZK3: # 定义服务注册发现中心
protocol: zookeeper
address: x.x.x.x:2183
consumer:
references:
AbcService: # 存根类名
registry: demoZK,demoZK2,demoZK3
protocol: dubbo # dubbo 协议，默认 hessian2 序列化方式
interface: com.xx.xx.xx.AbcService # 接口需要与 go/java 客户端对应
这是我的配置文件
dubbo: registries: demoZK: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2181 demoZK2: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2182 demoZK3: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2183 consumer: references: AbcService: # 存根类名 registry: demoZK,demoZK2,demoZK3 protocol: dubbo # dubbo 协议，默认 hessian2 序列化方式 interface: com.xx.xx.xx.AbcService # 接口需要与 go/java 客户端对应
行，我今天测一下
这是我的配置文件
dubbo: registries: demoZK: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2181 demoZK2: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2182 demoZK3: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2183 consumer: references: AbcService: # 存根类名 registry: demoZK,demoZK2,demoZK3 protocol: dubbo # dubbo 协议，默认 hessian2 序列化方式 interface: com.xx.xx.xx.AbcService # 接口需要与 go/java 客户端对应行，我今天测一下
有没有结果
这是我的配置文件
dubbo: registries: demoZK: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2181 demoZK2: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2182 demoZK3: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2183 consumer: references: AbcService: # 存根类名 registry: demoZK,demoZK2,demoZK3 protocol: dubbo # dubbo 协议，默认 hessian2 序列化方式 interface: com.xx.xx.xx.AbcService # 接口需要与 go/java 客户端对应行，我今天测一下
有没有结果 我这启动了一个 java 的 provider， 3 个 zk 做注册中心， go client 用 100w 次 loop 请求，内存变化不是很大。你这边有最小复现流程么？
go.mod
dubbo.apache.org/dubbo-go/v3 v3.0.2
github.com/apache/dubbo-go-hessian2 v1.11.1 // indirect
这是我的配置文件
dubbo: registries: demoZK: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2181 demoZK2: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2182 demoZK3: # 定义服务注册发现中心 protocol: zookeeper address: x.x.x.x:2183 consumer: references: AbcService: # 存根类名 registry: demoZK,demoZK2,demoZK3 protocol: dubbo # dubbo 协议，默认 hessian2 序列化方式 interface: com.xx.xx.xx.AbcService # 接口需要与 go/java 客户端对应行，我今天测一下
有没有结果 我这启动了一个 java 的 provider， 3 个 zk 做注册中心， go client 用 100w 次 loop 请求，内存变化不是很大。你这边有最小复现流程么？
go 1.16, web gin, dubbo-go v3，zk 3.4.8 逻辑：gin api路由直接转dubbo-go client 调用java dubbo 压测：请求gin api，qps=500+，8个小时，内存涨了120MB
嗯嗯，你这边方便帮忙看看 zk 里面
这种日志多么
这个日志是dubbo-go zk打印的吗？
嗯，zk 里面打印的。
抽空给看下
嗯嗯，我这边大概知道了，这两天会提个 PR 在测一下