-
Notifications
You must be signed in to change notification settings - Fork 26.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
超大cache文件DubboSaveRegistryCache-thread-1线程多次加载致使内存溢出 #685
Comments
这样的问题出现的概率非常低,但是一旦出现比较致命 |
你们集群和服务数量的规模是多少,你上面的cache文件远高于你们实际的服务规模吗?你的注册中心文件样本能提供一部分吗?dump的堆栈也提供一下。谢谢 |
目前集群服务器数量只有100台左右,其中消费者和提供者大概是3:4的比率,正常情况下cache文件内容如下,这是其中一个服务提供者服务端的cache文件; |
泄露堆栈为 DubboSaveRegistryCache-thread-1 |
泄露的具体对象为,注意着只是泄露的java.lang.Thread @ 0x779569808 DubboSaveRegistryCache-thread-1 关联的一部分对象,大概200多M
|
我们也遇到这个问题了,分析dump出来的内存,是ZookeeperRegistry对象的properties属性过大(每个对象两百兆左右,一共14个对象达到了近3个g),key中全部或者部分包含非常多的\u0000字符,查看本地的cache文件,也是很多\u0000,与内存的情况一致,偶发性的,请问是什么原因啊? |
@zhangzacks @maodie007 按理说,ZookeeperRegistry 只会有一个。。。你们是有多个注册中心么? |
@qinliujie 只有一个注册中心 |
@qinliujie 另外补充一点,我们的系统是存在Jboss热部署的,实际上dubbo在Jboss的热部署的时候也存在问题,比如一些线程池或者静态引用在Jboss热部署的时候并不能正常释放,导致部署的包无法正常卸载。这个问题不一定和这个Issue有关系,但是我还是尽可能的将环境描述清楚,谢谢你们对问题的关注! |
大致了解了 @maodie007 你那里能提供一下出错时文件的部分内容么。。我现在觉得比较奇怪,这个不应该引入 \u0000 才对啊 |
时隔比较久,现在只能找到当初的截图片断了,共享到了这里 |
你们有通过ops向zk中写配置信息吗?有没有可能\u0000是从外部引入的 |
为什么会有那么多ZookeeperRegistry对象,会不会和热部署有关系。能不能在服务正常启动后,多次热部署后分别dump一份数据,确定下ZookeeperRegistry对象数量? |
这种BUG出现的概率很低,而我们的热部署非常频繁,所以直接将热部署和这个任务相关可能性不大,我们之前也DUMP过在没有出现故障的时候是不会有这个BUG的 没有反写zk配置信息的行为。 |
@qinliujie zk集群只有一个,但是不同系统的服务在zk上的分组不一样,所以跨系统调用的时候配置了多个dubbo:registry |
|
@chickenlj |
dubbo:registry的group是什么意思?只有服务有group的概念,不过分group并不需要配置14个dubbo:registry,占用过多的内存 |
@chickenlj 我好像明白你的意思了,你说的服务分组是指dubbo:service的group属性是吧?好吧,是我描述不清楚,我们是通过指定dubbo:registry的group属性值来分组的,这应该是叫注册中心分组更准确吧,意思是一个系统一个zk分组,然后需要实现不同zk分组下的服务互相调用.不过这并不是问题I的根源,单就一个ZookeeperRegistry对象来看就达到了200M,显然这是有问题的. |
使用tomcat热部署,也是同样出现这个问题 SEVERE: The web application [/zd-model-platform] appears to have started a thread named [DubboServerHandler-139.199.175.58:31250-thread-2] but has failed to stop it. This is very likely to create a memory leak. |
@JavaxinYao 看你这个日志是今天的,我建议你将其他的一些信息可以更多的发在这里,比如现在有问题的cache文件内容 |
我觉得可能是tomcat reload 类重新加载内存不释放 就比较容易导致内存溢出 |
@JavaxinYao 热部署是会存在问题,我在之前的回复上说到过,但是你的OOM不一定和这个ISSUE是一致的,你需要DUMP才能知晓,我前面说过dubbo本来就存在在热部署的情况下无法正常关闭一些资源,导致多次部署将会致使内存溢出的可能,这一块我们自己对dubbo也进行过调整 |
cache文件和ZookeeperRegistry对象过大的问题有头绪吗?我们这里很长时间没出现过了,这个问题隐藏的有点深. |
这个问题我也遇到过,可能不是因为服务数量过多导致的。dubbo启动后会默认把zookeeper上的服务URL信息按ZK的IP地址为标识分多个文件缓存到本地的${user.home}目录下,如果当前服务器节点上部署有多个dubbo 应用,当ZK上有服务变更信息时会推给所有的消费者服务,如果有多个消费这个服务的应用都部署在这个一个节点上,会导致ZK缓存文件特别大。建议通过 dubbo.registry.file 配置给每个应用指定一个ZK缓存目录 |
@663534597 非常感谢你的分享,你的这个说法正好印证了可能和热部署应用未正常卸载导致同一个服务在一个服务节点上注册多次 |
@663534597 不知道我们遇到的情况是否一样,我这里是cache文件出现大量的\u0000字符,cache文件达到几百兆,对应到内存里,ZookeeperRegistry对象的properties属性的很多key里包含大量的\u0000,就这些key(String类型)每一个就有几兆,甚至十几兆大,\u0000是不可识别的字符,到底是怎么出现的,设么情况下会出现,不得而知. |
目前我们把Registry Cache部分的逻辑简单优化了一下, |
@chickenlj 你的这个修改可能针对于这个问题还没有到关键点,因为故障的场景不是重复加载了文件,而是一个文件的加载就导致了故障,因为这个文件太大了,可能的思路应该是Registry Cache的文件内容的生成做一个考虑,比如内容必须有某个格式,若出现异常写应该直接报错,这样可以把故障挡在前面,若找不到根本解决原因,但是可以做一个预防 |
@chickenlj 我们出现过有多个注册中心的情况 |
Without more discussion about this issue, I'll close it. Feel free to reopen if necessary. |
👍非常好的问题,涨经验啦。“使用姿势”很重要,功能好坏在于怎么使用。 同机房调用场景下,使用一个注册中心即可,建议优先使用服务分组或服务版本做隔离;跨机房调用场景下,可能需要多个注册中心。 |
* Optimize(AbstractRegistry) registry cache, one registry file per 'registry & application', avoid reload (apache#685). * Fixed apache#692 optimize zookeeper operation in service export/reference process: check already exists before create
在dubbo的服务注册缓存文件cache目录下的文件已经达到了900M
System.getProperty ("user.home") + "/.dubbo/dubbo-registry-" + url.getHost () + ".cache"
对比其他正常服务器,正常文件大小只有1-2M,打开这个900M的文件其中很多内容为 \u0000,
由于dubbo默认每隔10分钟会读取这个文件,由于文件太大,导致每次读取造成频繁的GC最终致使JVM在这个时间段内CPU负载非常高而无法处理业务请求。
通过DUMP内存,发现内存泄露都是线程
java.lang.Thread @ 0x779569808 DubboSaveRegistryCache-thread-1
其中同样类似的线程还有2个,每个线程占用200-300M
另外还有大对象 com.alibaba.dubbo.registry.zookeeper.ZookeeperRegistry 3个无法回收,200M左右一个
总计1.5G大小内存无法释放!
为何会有如此大的缓存文件?为何同样的文件会被不同的线程多次加载?
The text was updated successfully, but these errors were encountered: