Red5作为多媒体的开源框架,实现了RTMP协议,完成了视频,音频和多媒体数据的传输和解析,很多产品都在用它。我们也在用他们的服务,但是遇到了内存泄漏的问题,这个内存泄漏是怎么发现的呢:
现象:服务器跑了两天左右,出现了两种情况:
1.内存溢出
2.内存没有溢出,但是无法提供任何服务,服务器无法接收任何请求
分析:
1.扩大跑虚拟机的内存,结果服务器长了点时间,照样内存溢出
2.Dump出Heap快照,并用Eclispse Memory Analyzer进行分析,发现RTMPMinaConnection对象大量存在ConcurrentHashMap对象里面,为什么会出现大量的连接?即使是大量的客户端请求,内存没有释放?
3.分成三个问题考虑:
1)为什么会出现大量的连接?连接从哪里来的
2 )大量的连接为什么会没有释放?
3)为什么连接达到一定的数量,即使服务器在内存充裕的情况下,仍然无法提供任何服务?
根据大量的连接首先,发现red5服务器,我们用Haproxy代理了rtmp请求,而HA即使没有请求的情况下,仍然尝试连接,以探测代理的服务器是否已经,而red5的keepalive时间过了,会尝试关闭连接,之后关闭,通过查看源代码发现,连接虽然关闭了,但是没有从 concurrentHashupMap 里面删除,而真是这种哈的不间断的通过创建心跳连接来探测 red5 是否有一个活动的状态,而 red5 关闭连接之后,并没有从concurrentHashMap里面删除,从而造成了最终的内存溢出,同时由于没有删除不活动的连接达到了red5设定的最大允许的不活动连接的数量,默认为60000个连接,从而造成我们刚才看到的即使现象-内存充裕的情况下,仍然提供不了任何服务的情况。
查找这个错误的过程是痛苦的,甚至没有一点头绪,还好通过大量的测试和源代码分析,发现了这个问题。我们现在已经升级到red5 0.9.1的版本了,目前情况良好,同时为了保证服务器的稳定性,我们也查阅了相关的源代码,可以确定0.9.1版本中已经修复了这个问题。相信red5服务器在我们的产品上线后会处于一个非常稳定的状态。
这个问题,一些工具的使用是关键的:
首先,要会分析堆快照,而eclipse内存分析器确实是很强大的工具。帮助我们提供大量有用的信息。
其次,开源软件是不可靠的,只有我们对他们的代码有深入的分析才会得出了好的结果。还好,源代码开放也为我们提供了查找问题来龙去脉的根据。而我们也可以对开源软件进行优化,在以后的内容里,我也记录了我们优化red5服务器的整个过程,相信还有很多地方,我们仍然可以优化它。
网上找的~~