Also, here's a snapshot of the "top" command, while streaming the file,
for what it's worth. :) -NPJ
-----
top - 10:54:56 up 1 day, 21 min, 1 user, load average: 0.32, 0.16, 0.05
Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.6% user, 26.1% system, 0.0% nice, 71.3% idle
Mem: 905404k total, 569872k used, 335532k free, 32500k buffers
Swap: 2731008k total, 0k used, 2731008k free, 409376k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3459 nathan 14 0 1092 1092 848 R 26.5 0.1 0:38.85 top
1260 root 9 0 335m 335m 283m S 0.5 37.9 0:08.87 java
1095 root 9 0 335m 335m 283m S 0.2 37.9 0:00.05 java
1115 root 9 0 335m 335m 283m S 0.2 37.9 0:00.43 java
1119 root 9 0 335m 335m 283m S 0.2 37.9 0:00.06 java
1126 root 9 0 335m 335m 283m S 0.2 37.9 0:00.43 java
3460 root 9 0 335m 335m 283m S 0.2 37.9 0:00.77 java
3461 root 9 0 335m 335m 283m S 0.2 37.9 0:00.33 java
1 root 8 0 500 500 448 S 0.0 0.1 0:02.15 init
----
On Tue, 27 Feb 2007, Nathan P. Johansen wrote:
> 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
