Agreed, but the OP seemed to be looking for a "command-line" solution, not a "C" one.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Edwards Sent: Friday, February 27, 2009 2:20 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] call file concurrency > -----Original Message----- > From: [email protected] > [mailto:[email protected]] 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 [email protected] Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
