CPU slowly being consumed

[Dan]

(thought i posted this morning, but perhaps it didn't make it -
apologies if duplicate)

Group:

I'm getting an odd issue whereby the processor is slowly being
consumed by RTMPd. It seems to be related to the MPEG-TS ingest. I
have several machines running this, and am watching the proc creep up
on each of them.

On machines that only ingest RTMP feeds, it doesn't appear to be an
issue (although I just noticed this issue, so perhaps it is), but
those with MPEG-TS (udp), it certainly is.

It takes a day or two, but sure enough, it will consume nearly 100%
(perhaps only of one core) of the processor. What's odd, is that it's
stable - it seems to stay wherever it is percentage-wise, then just
creep up slowly - no bouncing around.

I'm using an older build as well as one I just pulled from SVN today -
and the issues are identical.

As always, any help / pointers are appreciated!

--dan

[C++ RTMP Server]

Interesting...

I will need more details. I'll PM you

> You received this message because you are subscribed to "C++ RTMP Server" mailing list.
> To post to this group, send email to c-rtmp...@googlegroups.com
> To unsubscribe from this group, send email to
> c-rtmp-serve...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/c-rtmp-server?hl=en

------
C++ RTMP Server
Web: http://www.rtmpd.com

[Dan]

Just a little more detail here.

I've been graphing the CPU % on two machines that are receiving only
UDP push.

The machines (over the past few days) have increasing CPU, as noted
above. Here's the graphs:
http://d.pr/i/xBRX

I can direct the UDP stream somewhere else if anyone would like to
receive it - whatever works.

Thanks again for your help here.

--dan

>  smime.p7s
> 6KViewDownload

[C++ RTMP Server]

Hi,

Very nice graph and definitely worth investigating.
I will prepare a machine for 24/7 ingesting. I will let you know when is ready via PM. In the mean time, if anyone else is willing to take this task, feel free to do so.
Hint: problem might be with the IOBuffer doing excessive "optimizing". Log messages inside IOBuffer::EnsureSize, IOBuffer::MoveData and IOBuffer::Recycle are particularly interesting. The log message should dump IOBuffer::_size variable which is the allocated memory. The person debugging should also create a server-wide global variable (static) with the maximum _size ever achieved for ALL IOBuffer instances. If we detect that _size creeps up, that is our problem :)

Best regards,
Andrei

[Dan]

Just an update from here - 

It appears that the issue may be related to keyframe frequency.  If I set IDR rate to, say, 5 seconds or so, the creep is _much_ slower - maybe approaching un-noticable over the course of a day or so, but after that, it starts creeping above 3-5%.  However, if I set the keyframes to every 2 seconds, the creep is faster - maybe 5-8% a day.  

Thanks again for any help here.

--dan

>>> c-rtmp-server+unsubscribe@googlegroups.com

>>> For more options, visit this group at
>>> http://groups.google.com/group/c-rtmp-server?hl=en
>>
>> ------
>> C++ RTMP Server
>> Web:http://www.rtmpd.com
>>
>>  smime.p7s
>> 6KViewDownload
>
> You received this message because you are subscribed to "C++ RTMP Server" mailing list.
> To post to this group, send email to c-rtmp...@googlegroups.com
> To unsubscribe from this group, send email to

> c-rtmp-server+unsubscribe@googlegroups.com