Memory leak

[sesm]

We are running Red5 1.0.1 on Windows. In our setup it normally consumes about 300M of heap, but from time to time memory usage starts to grow and Red5 crashes with OutOfMemory exception.
We used a tool called Plumbr to analyze memory usage. Below are a couple of typical reports that we get from the tool in case of OOM:
https://portal.plumbr.eu/shared#/incident/188474?token=Hi5zH2LjgtLAqYdn5QezvzxSuEc
https://portal.plumbr.eu/shared#/incident/188457?token=ToJm7QFliYVZCU5ezNw_0NPuRnw
Please let me know, if you need any additional information.

[sesm]

Looking at BaseRTMPTConnection class: it uses LinkedBlockingQueue for outgoing messages and attemps to handle queue overflow gracefully by discarding messages. The problem is that LinkedBlockingQueue is created with default capacity, which is Integer.MAX_VALUE (2'147'483'647). I suppose this is too big and needs to be changed to a value that makes sense for Red5 default heap size of 768M.

[mondain]

Sergey, thanks for the report and the plumbr details. I'll look at the latest code and see if the default size is still be used.

[mondain]

For reference the class is now located in red5-server-common https://github.com/Red5/red5-server-common/blob/master/src/main/java/org/red5/server/net/rtmpt/BaseRTMPTConnection.java

[mondain]

Fixed at commit Red5/red5-server-common@498780c

[sesm]

Thanks a lot for quick response! Will this fix be included in then next Red5 release? Is there an approximate date for the next release?

[mondain]

Yes, it'll be in the next release 1.0.4; which we are trying to get out before 2015.

[sesm]

Great! Thanks again!

[sesm]

We've configured red5 to leave memory dumps after OOM, here are the dumps that we got:

1 - https://drive.google.com/file/d/0B1vFExHovKwobllpNEt3Zk5RNTg/view?usp=sharing
2 - https://drive.google.com/file/d/0B1vFExHovKwoMmdaaEREYzJSVk0/view?usp=sharing
3 - https://drive.google.com/file/d/0B1vFExHovKwocTRwU015aVA5ZU0/view?usp=sharing
4 - https://drive.google.com/file/d/0B1vFExHovKwoZm1ubjlGb2pESW8/view?usp=sharing
5 - https://drive.google.com/file/d/0B1vFExHovKwobmNHSUp4TEs4V28/view?usp=sharing

After analyzing the dumps with jvisualvm the following interesting facts we found:
a) In each dump the number of RTMPTConnections was larger then we expected, according to our test setup we expected 6 connection in each dump, but the number of connections was:
dump 1 - 243,
dump 2 - 12,
dump 3 - 24,
dump 4 - 18,
dump 5 - 24.
b) In each dump the number of RTMPTConnections with small (< 200) amount of pending outgoing messages was about 6:
dump 1 - 9,
dump 2 - 7,
dump 3 - 7,
dump 4 - 7,
dump 5 - 7.
(the following OQL query in jvisualvm was used:
'select c from org.red5.server.net.rtmpt.RTMPTConnection c where c.pendingOutMessages.count.value < 200' )

a) and b) together support a hypothesis, that in our case memory leak happens due to unclosed RTMPT connections.

This raises 3 questions:

1. Where should we continue investigation to figure out, what is causing unclosed connections?
2. Does it makes sense for red5 to leave memory dumps on OOM by default? Would you accept a patch for it?
3. Does it makes sense for red5 to expose monitoring of RTMPT connections via JMX (similarily to monitoring of streams that we have now)? Would you accept a patch for it?

Thanks in advance!

[mondain]

Did you use the patched / latest server build?

On Wed Dec 24 2014 at 12:00:55 PM Sergey Smyshlyaev <
notifications@github.com> wrote:

We've configured red5 to leave memory dumps after OOM, here are the dumps
that we got:

1 -
https://drive.google.com/file/d/0B1vFExHovKwobllpNEt3Zk5RNTg/view?usp=sharing
2 -
https://drive.google.com/file/d/0B1vFExHovKwoMmdaaEREYzJSVk0/view?usp=sharing
3 -
https://drive.google.com/file/d/0B1vFExHovKwocTRwU015aVA5ZU0/view?usp=sharing
4 -
https://drive.google.com/file/d/0B1vFExHovKwoZm1ubjlGb2pESW8/view?usp=sharing
5 -
https://drive.google.com/file/d/0B1vFExHovKwobmNHSUp4TEs4V28/view?usp=sharing

After analyzing the dumps with jvisualvm the following interesting facts
we found:
a) In each dump the number of RTMPTConnections was larger then we
expected, according to our test setup we expected 6 connection in each
dump, but the number of connections was:
dump 1 - 243,
dump 2 - 12,
dump 3 - 24,
dump 4 - 18,
dump 5 - 24.
b) In each dump the number of RTMPTConnections with small (< 200) amount
of pending outgoing messages was about 6:
dump 1 - 9,
dump 2 - 7,
dump 3 - 7,
dump 4 - 7,
dump 5 - 7.
(the following OQL query in jvisualvm was used:
'select c from org.red5.server.net.rtmpt.RTMPTConnection c where
c.pendingOutMessages.count.value < 200' )

a) and b) together support a hypothesis, that in our case memory leak
happens due to unclosed RTMPT connections.

This raises 3 questions:

1. Where should we continue investigation to figure out, what is causing
   unclosed connections?

2. Does it makes sense for red5 to leave memory dumps on OOM by default?
   Would you accept a patch for it?

3. Does it makes sense for red5 to expose monitoring of RTMPT connections
   via JMX (similarily to monitoring of streams that we have now)? Would you
   accept a patch for it?

Thanks in advance!

—
Reply to this email directly or view it on GitHub
#40 (comment).

[mondain]

As for creating dumps automatically, I'd have to say no as it would cause confusion to the majority of users. I would however be glad to post a wiki page about it, if you want to write one up.

[sesm]

Regarding server version, we are using 1.0.1. Was there any specific fix on RTMPT connections handling after 1.0.1? Anyway, I will try to reproduce the problem on a more recent version. What version would you recommend: 1.0.3 or 1.0.4-SNAPSHOT?

Regarding memory dumps wiki page, I'll write one when I have time.

What about monitoring RTMPT connections via JMX? I think it would be a valuable feature.