Thanks Dan. I'm glad to know that it should be reading the file "in chunks". Here's a sample output from the "vmstat" command -
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 0 327404 31628 409320 0 0 0 0 101 255 0 0 100 0 This is just after a fresh restart of the entire machine - and loading in a single ~350MB FLV, and playing it for a while, then disconnecting. When the file is first requested, the value of "free" memory drops by about 300,000, the value of the "cache" memory rises about 300,000 and the "buff" flits around a bit. I'll need to go read the man page to see what all of this is really trying to tell me. :) After I've loaded three of these large FLV files, the "free" column goes down to nearly zero, the cache maxes out at some number around 800,000, and the "swpd" (swapped, I assume) grows by several thousand before Red5 becomes unstable and stops working. This snapshot is from the server a moment ago - while the file was loaded into memory yesterday morning, so it's been over 24 hours. I'll be interested to try out the 0.6rc2 version on Debian - perhaps Simon will be kind enough to put that package together for us? :) How is everyone else monitoring memory usage, and what trends do you see? Nate On Tue, 27 Feb 2007, Daniel Daley wrote: > In the current trunk version (which should be in 0.6r2 as well) the > file is loaded by chunks into a small buffer as each section is > needed. Currently however, red5 does scan the entire file before it > begins playing causing it to request a lot of page faults to the OS. > Most OSes will respond with an address to a new memory location > rather than using the old one when memory is requested that fast. > However, the memory is still released though back to the OS after > each chunk is read. Most unix system (and perhaps windows I'm not > sure) will keep the memory in an inactive buffer even after the > memory is released by the application and has become available again. > In this case programs such as top will not list the memory as "free" > but instead as "inact". Could this be what you are seeing? > > --Dan-- > > > On Feb 27, 2007, at 8:48 AM, Nathan P. Johansen wrote: > > > Hi Everyone, > > > > I'm curious - I have FLV files that are about 350 MB in size, the > > playing > > time is about 90 minutes. When I connect to Red5 and start > > streaming the > > file, there is about a 30 second delay, and watching the memory on my > > system (Debian - using the "vmstat 5" command) it's obvious that the > > entire file is being read into memory. Once it's there, playback, > > seeking, and so forth works fine - it's fast and responsive. > > However when > > I disconnect, the file remains in memory. > > > > My question: is it necessary for the entire file to be loaded into > > memory? > > Why does it not instead try to read the data as it is needed from > > disk? > > With about 2 GB of RAM, looking at more than three such similar files > > quickly sucks up all the available memory and causes the thing to die. > > > > I'm still using the 0.5 version - however on my Windows machine > > testing > > the 0.6rc2 version, it appears that the same thing is happening. > > > > Nathan > > > > > > > > _______________________________________________ > > 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
