[Asterisk-Dev] res_monitor improvement

[Steven]

On Sun, 2005-08-14 at 21:52 -0400, Jerris, Michael MI wrote:
>  > [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Brian West
> > 
> > If you use monmux the audio before writing it out to disk 
> > you'll cut your disk I/O in half.  Then you can also lower 
> > that by choosing gsm or something other than raw or wav.
> > 
> > /b
> > 
> 
> In comparison, file written to temp (2 separate files so twice the
> amount of writes) then at the end of the call, both files are read,
> (double read here) and mixed, at which point you have a cpu spike as it
> does all the mixing as quick as it can, instead of streamed as it goes,
> limited by the speed the audio comes in, then one final write.  With
> muxmon, you have to audio streams that come in, they are muxed on the
> fly, with the cpu usage limited by the speed of incoming audio, and a
> single file is written as it goes.  In summary you have 1/2 the realtime
> disk access as it goes (which is run through slinfactory which will not
> block as it goes) and overall 20% of the disk access, in addition you
> avoid thte cpu spike and disk access spike at the end of the call.  I
> will have real world results from a large environment doing a huge
> amount of recording soon, but initial testing looks very promising.  

Maybe you would be interested in the smaller change of reducing the
mixing rewritting threads priority. I made a patch earlier to reduce the
priority of the spawned agi thread.

http://bugs.digium.com/view.php?id=4930

It looks like it might be a good idea to reduce priority when
ast_safe_system is used in asterisk.c just after the fork and before we
execl the command.

This would at the minimum reduce the need for the nice command in the
mixing section of res_monitor. 

It also pointed out something that might be of interest, the fact that
the ast_safe_system closes all file descriptors below 4096, but in agi,
we only close those below 1024. Looks like we may need to audit where we
fork processes and make a consistent way of sanitizing the environment
and put it all in one place.

-- 
Steven Critchfield
critch at basesys.com
KI4KTY