Great, thanks! We're still chasing down the processor load problem we have. It seems that the java process continues to grow it's percentage of CPU use until it gets to 80-90% when Red5 stops responding in a timely manner.
It does not appear to be related to how long the server has been running, instead it appears to be related to how many connections have been processed. For example, during a high demand period, it ramps up to 90% CPU within an hour or two. However, over this weekend - a very low demand period - it has only gotten to 25% and it's been up for over 3 days. Here's the results of 'top': top - 12:40:22 up 3 days, 8:37, 2 users, load average: 0.90, 0.69, 0.53 Tasks: 70 total, 2 running, 68 sleeping, 0 stopped, 0 zombie Cpu(s): 28.5% us, 0.3% sy, 0.0% ni, 71.2% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 1477380k total, 469604k used, 1007776k free, 46736k buffers Swap: 2031608k total, 0k used, 2031608k free, 220756k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2133 root 25 0 1428m 103m 19m S 28.6 7.2 548:58.75 java As you can see, memory isn't a problem with over a GIG free (JVM is set to 1024M in the red5 start up script). Where would I start looking in the code to find something that's perhaps not killing idle processes? Is there any benchmark on how much processor time it takes to establish and maintain a connection to Red5 RTMP? I'm not very familiar with jetty when it comes to setup or where to look for problems - we're exclusively a Tomcat shop. Unfortunately, I can't use Tomcat yet because of the RTMPT problem with the WAR file, or I'd test on that platform to eliminate or identify the servlet engine as the problem. Any help or direction as to where to start looking is welcome. Thanks for all your work on this project - it kicks butt. Bill Steven Gong wrote: > On 11/26/06, Interalab Sales <[EMAIL PROTECTED]> wrote: >> >> I've been running for a few days with NoCacheImp and 'none' as the >> buffer type in red5-common.xml. Results have been better. >> >> What cache and buffer settings should be used with this new >> FLVReader.java? > > > The cache settings are not relevant to FLVReader. Now the buffer > management > is better and you may try 'direct' or 'heap' to see if it's better. > > I am reviewing the code BTW and hope it can be checked into the trunk > later. > > Bill >> >> [EMAIL PROTECTED] wrote: >> > Just wanted to let you know that I updated the ticket today with a new >> version of FLVReader.java that implements a memory buffer and is much >> cleaner. After running it for a few days my memory usage on VOD >> content has >> dramatically dropped, I just need to test out some different buffer >> sizes >> and see what kind of performance I can get. >> > >> > >> > >> > Thanks >> > >> > >> > >> > --Dan-- >> > >> > >> > >> > On Nov 21, 2006, at 6:54 PM, Daniel Daley wrote: >> > >> > >> > >> > Created as APPSERVER-8 although I must warn you the code is horid heh. >> > >> > >> > >> > Thanks, >> > >> > >> > >> > --Dan-- >> > >> > >> > >> > On Nov 21, 2006, at 6:31 PM, Steven Gong wrote: >> > >> > >> > >> > Dan, >> > >> > Please submit a ticket on JIRA and attach your version of FLVReader on >> it. I will take a look at it later. Thanks. :-) >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Red5 mailing list >> > [email protected] >> > http://osflash.org/mailman/listinfo/red5_osflash.org >> > >> >> _______________________________________________ >> Red5 mailing list >> [email protected] >> http://osflash.org/mailman/listinfo/red5_osflash.org >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
