[asterisk-users] call file concurrency

[Steve Edwards]

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Steve Edwards
> Sent: Friday, February 27, 2009 11:39 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] call file concurrency
>
>> Is there a convenient way to limit the number of call files (outgoing
>> directory) that are processed concurrently?
>
> On Fri, 27 Feb 2009, Danny Nicholas top posted:
>
>> Some variant of the ulimit command would accomplish this but YMMV and
>> "Caveat Emptor".

On Fri, 27 Feb 2009, Steve Edwards wrote:

> Which one?
>
> 	-fs::sedwards:~$ ulimit -a
> 	core file size          (blocks, -c) 0
> 	data seg size           (kbytes, -d) unlimited
> 	file size               (blocks, -f) unlimited
> 	pending signals                 (-i) 1024
> 	max locked memory       (kbytes, -l) 32
> 	max memory size         (kbytes, -m) unlimited
> 	open files                      (-n) 1024
> 	pipe size            (512 bytes, -p) 8
> 	POSIX message queues     (bytes, -q) 819200
> 	stack size              (kbytes, -s) 10240
> 	cpu time               (seconds, -t) unlimited
> 	max user processes              (-u) 16114
> 	virtual memory          (kbytes, -v) unlimited
> 	file locks                      (-x) unlimited
>
> Limiting the number of open files or file locks would not have the
> intended effect.

On Fri, 27 Feb 2009, Danny Nicholas top posted:

> Here is a link to a better, but possibly dangerous answer.
>
> http://www.netadmintools.com/art295.html
>
> Since a typical linux box probably allows about 250K files to be 
> simultaneously open, and you need about 2K for system and * overhead, by 
> cutting the max number of files down to about 3K, you would limit the 
> number of calls to about 1K, assuming that each open call is one file 
> handle.

I think proposing to control the number of concurrently processed call 
files by inducing file descriptor exhaustion is about 32 days premature.

Calls would fail at random and you may or may not be able to log in or 
even execute a command line depending on if you were currently exhausted 
at any particular instant.

I think the OP is looking for some knob to turn in pbx_spool.c

Thanks in advance,
------------------------------------------------------------------------
Steve Edwards      sedwards at sedwards.com      Voice: +1-760-468-3867 PST
Newline                                             Fax: +1-760-731-3000